On 24/05/2019 18:44, Jakub Kicinski wrote: > On Fri, 24 May 2019 18:27:39 +0100, Edward Cree wrote: >> On 24/05/2019 18:03, Jakub Kicinski wrote: >>> 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.. The problem is not where the list goes, it's where the list_head for each item on the list goes. I don't want the driver to have to do anything to make this happen, so the core would have to allocate something to hold a list_head each time a driver successfully offloads an action.
>> 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.. OTOH I'm now finding that it's really quite hard to get "all tc blocks in existence" as a thing, so it's not as simple as it seemed, sadly. > It doesn't give you an upstream user for a cookie, though :S I don't think any of these approaches do; an upstream user necessarily involves an upstream driver that collects per-action stats, rather than the per-rule that they all do today. RTM_GETACTION offload won't change that, because those drivers won't be able to support it either for the same reason. -Ed
