Thread (6 messages) flat view 6 messages, 4 authors, 2016-02-19

Re: [PATCH net-next] store complete hash type information in socket buffer...

From: Tom Herbert <hidden>
Date: 2016-02-19 02:22:17

On Wed, Feb 17, 2016 at 1:30 PM, Eric Dumazet [off-list ref] wrote:
On mer., 2016-02-17 at 15:44 -0500, David Miller wrote:
quoted
From: Paul Durrant <redacted>
Date: Mon, 15 Feb 2016 08:32:08 +0000
quoted
...rather than a boolean merely indicating a canonical L4 hash.

skb_set_hash() takes a hash type (from enum pkt_hash_types) as an
argument but information is lost since only a single bit in the skb
stores whether that hash type is PKT_HASH_TYPE_L4 or not. By using
two bits it's possible to store the complete hash type information.

Signed-off-by: Paul Durrant <redacted>
Tom and/or Eric, please have a look at this.
I guess my question is simply 'why do we need this' ?

Consuming a bit in our precious sk_buff is not something we want for
some obscure feature.
Right. I think the reason Paul wants this is be able to pass the hash
to a Windows guest. As I pointed out though, we'd also need an
indication that the hash is Toeplitz to be really correct with Windows
interface. The Linux driver interface does allow indicating L2, L3, or
L4 hash with the assumption that differentiation might be useful some
day, but so far it only appears that distinguishing L4 from others has
any value. It would be interesting to know if Windows actually does
anything useful in differentiating L2 and L3 hashes.

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