[PATCH 0/4]: Revamp TX hashing.

[PATCH 0/4]: Revamp TX hashing.

[David Miller]

The simple_tx_hash() function we currently have in
net/core/dev.c is very rudimental and doesn't handle
routing and firewall scenerios very well.

The next 4 patches attempt to cure that.  The end result
is:

1) The RX queue selection of the input device seeds the
   TX queue selection for that SKB.

2) Locally generated packets seed the TX queue using
   skb->sk->sk_hash

Then we kill off the by-hand hashing code since in all cases
that matter it is no longer necessary.

Protocols that fail to store a proper sk->sk_hash value will
need to be fixed up to do so.  I encourage anyone so motivated
to do that audit :-)

Re: [PATCH 0/4]: Revamp TX hashing.

[Herbert Xu]

David Miller <davem@davemloft.net> wrote:
> 
> The simple_tx_hash() function we currently have in
> net/core/dev.c is very rudimental and doesn't handle
> routing and firewall scenerios very well.

This is really cool! Thanks Dave!

> The next 4 patches attempt to cure that.  The end result
> is:
> 
> 1) The RX queue selection of the input device seeds the
>   TX queue selection for that SKB.
> 
> 2) Locally generated packets seed the TX queue using
>   skb->sk->sk_hash

One thing that I've been thinking about is that it would be
really useful if we guaranteed that every inbound packet carried
a hash with it.  This could be used to help subsequent processing
such as routing, netfilter, etc. since they all need to make
decisions based on flows.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/4]: Revamp TX hashing.

[David Miller]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 28 Jan 2009 20:02:03 +1100

> One thing that I've been thinking about is that it would be
> really useful if we guaranteed that every inbound packet carried
> a hash with it.  This could be used to help subsequent processing
> such as routing, netfilter, etc. since they all need to make
> decisions based on flows.

Ok, all the complicated cases will have to occur in decapsulators :-)

For example, IP tunnels would need to compute the hash as would most
forms of IPSEC since often we can't even see the inner flow until
after decryption even for transport cases.