netdev - Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS

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: <20180307.102415.1350852471214942248.davem@davemloft.net>
Date:   Wed, 07 Mar 2018 10:24:15 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     ecree@...arflare.com
Cc:     linux-net-drivers@...arflare.com, netdev@...r.kernel.org,
        linville@...driver.com
Subject: Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS

From: Edward Cree <ecree@...arflare.com>
Date: Fri, 2 Mar 2018 16:01:47 +0000

> On 01/03/18 18:36, David Miller wrote:
>> We really should have the ethtool interfaces under deep freeze until we
>> convert it to netlink or similar.
>> Second, this is a real hackish way to extend ethtool with new
>> semantics.  A structure changes layout based upon a flag bit setting
>> in an earlier member?  Yikes...
> Yeah, while I'm reasonably confident it's ABI-compatible (presence of that
>  flag in the past should always have led to drivers complaining they didn't
>  recognise it), and it is somewhat similar to the existing FLOW_EXT flag,
>  it is indeed rather ugly.  This is the only way I could see to do it
>  without adding a whole new command number, which I felt might also be
>  contentious (see: deep freeze) but is probably a better approach.
> 
>> Lastly, there has been feedback asking how practical and useful this
>> facility actually is, and you must address that.
> According to our marketing folks, there is end-user demand for this feature
>  or something like it.  I didn't see any arguments why this isn't useful,
>  just that other things might be useful too.  (Also, sorry it took me so
>  long to address their feedback, but I had to do a bit of background
>  reading before I could understand what Jakub was suggesting.)

Ok.

Since nobody is really working on the ethtool --> devlink/netlink conversion,
it really isn't reasonable for me to block useful changes like your's.

So please resubmit this series and I will apply it.

Thanks.