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: <bf4c9a41-ea81-4d87-2731-372e93f8d53d@solarflare.com>
Date:   Fri, 24 May 2019 14:09:05 +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 23/05/2019 18:25, Jakub Kicinski wrote:
> Whether it's on you to fix this is debatable :) Since you're diving
> into actions and adding support for shared ones, I'd say it's time to
> rectify the situation.
>
> Let's look at it this way - if you fix the RTM_GETACTION you will
> necessarily add the cookie and all the other stuff you need in your
> upcoming driver :)
Yes, but then I don't have an upstream user for RTM_GETACTION offload!
I'd need to teach an existing driver to look up counters by action
 cookie, which would probably mean a hashtable, a bunch of locking and
 lifetime rules... not something I'm comfortable doing in someone else's
 driver that I don't know the innards of and probably don't have
 hardware to test on.

I'll put together an RFC patch, anyway, and maybe some other driver
 maintainer (hint, hint!) will follow up with a user ;-)
Should it be a new entry in enum tc_setup_type (TC_SETUP_ACTION), or in
 enum tc_fl_command (TC_CLSFLOWER_GETACTION)?  I'd imagine the former as
 we want this to (a) be generic beyond just flower and perhaps also (b)
 support creating and deleting actions as well (not just dumping them).

-Ed