[PATCH v2 0/4] rps: Look into tunnels to get hash

In this version fixed calls to sock_rps_save_rxhash in IPv6 with correct
arguments and addressed comments from Eric Dumazet.

The patches in this series are to look into encapsulated packets
to compute the rx hash for RPS.  Before these patches, all packets
received on the same tunnel would wind up on the same RPS CPU-- this
can lead to very poor loading, and make RFS ineffective on these
packets.

This patch supports getting the rxhash out of a GRE encapsulated packet.

A couple of caveats:

- rxhash should be disabled in device to be able to use this.  I believe
probably all NICs would just provide rxhash on the outer packet
2-tuple.
- The l4_rxhash flag was added so that the hash is preserved across the
tunnel and can set in flow tables by the transport.  It would be nice
it driverswould set this to so to provide more useful information to the
stack (like whether the rxhash hash should be used in the flow table).
Unfortutunately, I don't think all drivers will be able to distinguish
the type of hash (2-tuple, 4-tuple, ...) without looking into the
packet.

From: Tom Herbert <redacted>
Date: Sun, 14 Aug 2011 22:44:33 -0700 (PDT)

In this version fixed calls to sock_rps_save_rxhash in IPv6 with correct
arguments and addressed comments from Eric Dumazet.

The patches in this series are to look into encapsulated packets
to compute the rx hash for RPS.  Before these patches, all packets
received on the same tunnel would wind up on the same RPS CPU-- this
can lead to very poor loading, and make RFS ineffective on these
packets.

This patch supports getting the rxhash out of a GRE encapsulated packet.

I'm sure we'll have some follow-on tweaks to this, but the basic
infrastructure looks fine to me.

Applied, thanks!