netdev - Re: [PATCH net-next 3/4] ethtool: Support for configurable RSS hash key.

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]

Date:	Thu, 23 Jan 2014 15:09:16 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Venkata Duvvuru <VenkatKumar.Duvvuru@...lex.Com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/4] ethtool: Support for configurable RSS hash
 key.

On Thu, 2014-01-23 at 13:47 +0000, Venkata Duvvuru wrote:
> > -----Original Message-----
> > From: Ben Hutchings [mailto:ben@...adent.org.uk]
> > Sent: Thursday, January 23, 2014 11:09 AM
> > To: Venkata Duvvuru
> > Cc: netdev@...r.kernel.org
> > Subject: Re: [PATCH net-next 3/4] ethtool: Support for configurable RSS hash
> > key.
> > 
> > On Wed, 2014-01-22 at 12:12 +0000, Venkata Duvvuru wrote:
> > [...]
> > > > No, what I mean is:
> > > >
> > > > 1. An RX flow steering filter can specify use of RSS, in which case
> > > > the value looked up in the indirection is added to the queue number
> > > > specified in the filter.  This is not yet controllable through RX
> > > > NFC though there is room for extension there.
> > > >
> > > > 2. Multi-function controllers need multiple RSS contexts (key +
> > > > indirection
> > > > table) to support independent use of RSS on each function.
> > > > But it may also be possible to allocate multiple contexts to a single
> > function.
> > > > This could be useful in conjunction with 1.  But there would need to
> > > > be a way to allocate and configure extra contexts first.
> > > The proposed changes will be incremental so I think this can be done
> > > in a separate patch. Thoughts?
> > 
> > The ethtool ABI (to userland) has to remain backward-compatible, and it is
> > preferable if we don't add lots of different structures for this.
> > 
> > So please define the new command structure to include both the key and
> > indirection table, and some reserved space (documented as 'userland must
> > set to 0') for future extensions.
> 
> I think it’s better to keep key and indirection table settings as
> different ethtool commands. We can probably add rss contexts (reserved
> space) to both the command structures.
> If we mix key and indirection table into one command structure then it
> will hamper the compatibility.
[...]

Right, there is no compatible way to extend struct ethtool_rxfh_indir.
I should have thought ahead when defining it!  But the new structure
doesn't need to have that problem.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)