netdev - Re: [PATCH v3 net-next 0/3] flow_offload: Re-add per-action statistics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <445ff0d5-970b-630f-48ec-fbb142971f28@solarflare.com>
Date:   Tue, 28 May 2019 17:27:52 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
        "Pablo Neira Ayuso" <pablo@...filter.org>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        "Andy Gospodarek" <andy@...yhouse.net>,
        Michael Chan <michael.chan@...adcom.com>,
        Vishal Kulkarni <vishal@...lsio.com>
Subject: Re: [PATCH v3 net-next 0/3] flow_offload: Re-add per-action
 statistics

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