Re: [PATCH v5] rfs: Receive Flow Steering

[Franco Fichtner <franco@lastsummer.de>]

Changli Gao wrote:
> On Sun, Apr 18, 2010 at 1:38 AM, Tom Herbert <therbert@google.com> wrote:
>   
>> That's cool!, but I still like the idea that this hash is treated as
>> an opaque value getting the hash from the device to avoid the jhash
>> or cache misses on the packet can also be a win...  Maybe connection
>> tracking/firewall could use the skb->rxhash which provides the
>> consistency and also eliminates the need to do more jhashes.
>>
>>     
>
> consistent rxhash only adds the risk of the hash collision, and I
> don't think it is a big problem. For connection tracking/firewall use,
> I am afraid that we have to recompute this value after defrag.  So we
> have to export the hash function we used in RPS.
>
> As NIC's hash function can be changed dynamically, the rxhash isn't
> consistent, so the rxhash can't be used by connection tracking, socket
> lookup and others come later.
>
>   
I have to agree with Eric and Changli here.

It's especially true if you're passively tracking via one NIC, where all 
traffic is just forwarded.
In this scenario, you need to compute consistent hashes. rxhashes by NIC 
will be different for
"incoming" and "outgoing" traffic...

Where rxhash by NIC can be used (note: didn't say _useful_) are 
scenarios with different net
ports for incoming and outgoing traffic (in active but also passive 
traffic scenarios). Here,
rxhashes could be used on a per-port basis, but associating two 
seemingly separate rxhashes
with one another to match CPUs is a really annoying task. This would 
involve computing the
corresponding "txhash" and looking it up, which is what we'd be doing 
with the jhash anyway.

For proper flow tracking Eric's suggestion is the way to go. And if 
there are worries about
collisions, why not add IPPROTO_* to the mix.


Franco