netdev - Re: [RFC PATCH net-next 1/3] net: ethtool: add symmetric Toeplitz RSS hash function

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: <20230825174925.45ea6ee5@kernel.org>
Date: Fri, 25 Aug 2023 17:49:25 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Ahmed Zaki <ahmed.zaki@...el.com>
Cc: <netdev@...r.kernel.org>, <jesse.brandeburg@...el.com>,
 <anthony.l.nguyen@...el.com>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>
Subject: Re: [RFC PATCH net-next 1/3] net: ethtool: add symmetric Toeplitz
 RSS hash function

On Fri, 25 Aug 2023 14:46:42 -0600 Ahmed Zaki wrote:
> > I'm just trying to help, if you want a single knob you'd need to add
> > new fields to the API and the RXFH API is not netlink-ified.
> >
> > Using hashing algo for configuring fields feels like a dirty hack.  
> 
> Ok. Another way to add a single knob is to a flag in "struct 
> ethtool_rxfh" (there are still some reserved bytes) and then:

Sorry we do have ETHTOOL_MSG_RSS_GET. It just doesn't cover the flow
config now. But you can add the new field there without a problem.

> ethtool -X eth0 --symmetric hfunc toeplitz
> 
> This will also allow drivers/NICs to implement this as they wish (XOR, 
> sorted, ..etc). Better ?

We should specify the fields, I reckon, something like:

ethtool -X eth0 --symmetric sdfn hfunc toeplitz

So that the driver can make sure the user expects symmetry on fields
the device supports.

> >> I agree that we will need to take care of some cases like if the user
> >> removes only "source IP" or "destination port" from the hash fields,
> >> without that field's counterpart (we can prevent this, or show a
> >> warning, ..etc). I was planning to address that in a follow-up
> >> series; ie. handling the "ethtool -U rx-flow-hash". Do you want that
> >> to be included in the same series as well?  
> > Yes, the validation needs to be part of the same series. But the
> > semantics of selecting only src or dst need to be established, too.
> > You said you feed dst ^ src into the hashing twice - why?  
> 
> To maintain the same input length (same as the regular Toeplitz input) 
> to the hash H/W block

But that's a choice, right? We're configuring the input we could as
well choose to make it shorter? v4 and v6 use the same key with
different input lengths, right?