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: <267b6dc6-b621-3278-58cf-562452d9450f@solarflare.com>
Date:   Thu, 23 May 2019 17:21:49 +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 22/05/2019 23:20, Jakub Kicinski wrote:
> On Wed, 22 May 2019 22:37:16 +0100, Edward Cree wrote:
>> * removed RFC tags
> Why?  There is still no upstream user for this
Well, patch #2 updates drivers to the changed API, which is kinda an
 "upstream user" if you squint... admittedly patch #1 is a bit dubious
 in that regard; I was kinda hoping someone on one of the existing
 drivers would either drop in a patch or at least point me at the info
 needed to write one for their HW, but no luck :-(
My defence re patch #1 is that I'm not really adding a 'new feature'
 to the kernel, just restoring something that used to be there.  It's
 a grey area and I'm waiting for the maintainer(s) to say yea or nay
 (Jiri noped v1 but that had a much bigger unused interface (the
 TC_CLSFLOWER_STATS_BYINDEX callback) so I'm still hoping).
> (my previous objections of this being only partially correct aside).
I didn't realise you still had outstanding objections, sorry.
Regarding RTM_GETACTION dumping, it should be possible to add an offload
 callback based on this, which would just pass the action cookie to the
 driver.  Then the driver just has to look the cookie up in its stats
 tables to find the counter.  That would deal with the 'stale stats'
 issue.
But right now, that really _would_ be an API without a user; still, I
 might be able to do that as an RFC patch to prove it's possible, would
 that help this series to go in as-is?

-Ed