Thread (15 messages) flat view 15 messages, 3 authors, 2014-04-03

Re: [PATCH v5 net-next 0/2] patchset: Support for configurable RSS hash key

From: Ben Hutchings <hidden>
Date: 2014-03-21 14:33:23

On Wed, 2014-03-19 at 15:59 -0400, David Miller wrote:
From: Venkat Duvvuru <redacted>
Date: Mon, 17 Mar 2014 18:01:33 +0530
quoted
NIC drivers that support RSS use either a hard-coded value or a random value for
the RSS hash key. Irrespective of the type of the key used, the user would want
to change the hash key if he/she is not satisfied with the effectiveness of the
default hash-key in spreading the incoming flows evenly across the RSS queues.

This patch set adds support for configuring the RSS hash-key via the ethtool
interface using -X option.
I apologize, but I really dislike this.  For several reasons.

First, why aren't we adding _just_ a RSS hash changing interface?

We already have an interface for changing the indirection table,
there is absolutely not need to add a second interface that supports
both indirection table _plus_ hash modifications.
That's what I asked for, because I see the hash key and indirection
table as being a single logical object (RSS context).
And combining these two is what leads to this hard to audit, ugly,
data structure layout.

There's the indirection table at some offset, then the key at some
other offset.  This makes it impossible to impose type checking
of any kind on both objects.
[...]

Which is why I previously suggested making the ethtool core find the two
arrays and pass those into the driver operations.  We do that for other
ethtool operations that use even a single variable-length array.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help