On 2019-05-24 11:09 a.m., Edward Cree wrote:
Oh, a push rather than pull model?
Right. I thought the switchdev (or what used to be called switchdev) did a push of some of the tables periodically.
That could work, but I worry about the overhead in the case of very large numbers of rules (the OVS people talk about 1 million plus) each pushing a stats update to the kernel every few seconds. I'd much rather only fetch stats when the kernel asks for them. (Although admittedly drivers already have to periodically fetch at least the stats of encap actions so that they know whether to keepalive the ARP entries.)
So that is part of the challenge. We had this discussion in Prague in the tc workshop. Andy (on Cc) presented and a discussion ensued (recorded on the video, about minute 24). If you are going to poll the hardware from the kernel then, if possible, you should put a time filter for "last changed" and only get things that have changed in the last delta. If you are using a model where the hardware pushes then ability to set a time filter for "last changed" would be needed. Note, Ive had to deal with this problem with tc actions from kernel-user point of view. See commit e62e484df049 - the idea is to not retrieve the 1M+ stats but rather only things that have changed since last attempt.
Also, getting from the cookie back to the action wouldn't be trivial; if there were only TC it would (just cast cookie back to a struct tc_action *) but soon some of these will be NF actions instead. So something slightly smarter will be required.
Well - this is that issue i was raising earlier as a concern. I think netfilter should have called into the tc api instead of directly. cheers, jamal
