On 24/05/2019 18:03, Jakub Kicinski wrote: > On Fri, 24 May 2019 14:57:24 +0100, 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? > Simplest would be to keep a list of offloaders per action, but maybe > something more clever would appear as one rummages through the code. Problem with that is where to put the list heads; you'd need something that was allocated per action x block, for those blocks on which at least one offloader handled the rule (in_hw_count > 0). Then you'd also have to update that when a driver bound/unbound from a block (fl_reoffload() time). Best I can think of is keeping the cls_flower.rule allocated in fl_hw_replace_filter() around instead of immediately freeing it, and having a list_head in each flow_action_entry. But that really looks like an overcomplicated mess. TBH I'm starting to wonder if just calling all tc blocks in existence is really all that bad. Is there a plausible use case with huge numbers of bound blocks?
-Ed
