On Fri, 24 May 2019 18:27:39 +0100, Edward Cree wrote: > 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).
I was thinking of having the list per action, but I haven't looked at the code TBH. Driver would then request to be added to each action's list.. > 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? Once per RTM_GETACTION? The simplicity of that has it's allure.. It doesn't give you an upstream user for a cookie, though :S
