From: Tom Herbert
Date: Wed, 29 Jul 2015 13:49:03 -0700
> The intent of this function was to produce a consistent hash for both
> directions of a flow. However, since we added more inputs to the flow
> hashing (IPv6 flow labels for instance) in a lot of cases we won't get
> the same hash computed
On Wed, Jul 29, 2015 at 3:15 PM, Eric Dumazet wrote:
> On Wed, 2015-07-29 at 14:47 -0700, Tom Herbert wrote:
>
>> Hi Eric,
>>
>> So the scenario you're thinking is conntrack in the forwarding path,
>> RPS enabled (RSS not relevant), no hash from device, no IPv6 flow
>> labels or any other asymmetr
On Wed, 2015-07-29 at 14:47 -0700, Tom Herbert wrote:
> Hi Eric,
>
> So the scenario you're thinking is conntrack in the forwarding path,
> RPS enabled (RSS not relevant), no hash from device, no IPv6 flow
> labels or any other asymmetric inputs into the flow hash? I can look
> at that, but it do
On Wed, Jul 29, 2015 at 2:19 PM, Eric Dumazet wrote:
> On Wed, 2015-07-29 at 13:49 -0700, Tom Herbert wrote:
>> The intent of this function was to produce a consistent hash for both
>> directions of a flow. However, since we added more inputs to the flow
>> hashing (IPv6 flow labels for instance)
On Wed, 2015-07-29 at 13:49 -0700, Tom Herbert wrote:
> The intent of this function was to produce a consistent hash for both
> directions of a flow. However, since we added more inputs to the flow
> hashing (IPv6 flow labels for instance) in a lot of cases we won't get
> the same hash computed for
The intent of this function was to produce a consistent hash for both
directions of a flow. However, since we added more inputs to the flow
hashing (IPv6 flow labels for instance) in a lot of cases we won't get
the same hash computed for each direction anyway. Also, there is no
defined correlation
