On 24/05/2019 15:44, Jamal Hadi Salim wrote: > On 2019-05-24 9:57 a.m., Edward Cree wrote: >> Argh, there's a problem: an action doesn't have a (directly) associated >> block, and all the TC offload machinery nowadays is built around blocks. >> Since this action might have been used in _any_ block (and afaik there's >> no way, from the action, to find which) we'd have to make callbacks on >> _every_ block in the system, which sounds like it'd perform even worse >> than the rule-dumping approach. >> Any ideas? > > If you have the hardware just send the stats periodically to the kernel > and manage to map each stat to an action type/index (which i think your > cookie seemed able to do) wouldnt this solve the problem? Oh, a push rather than pull model? 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.) 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.
-Ed
