ECMP hash keys?

[Nikolay Denev]

On Wed, Jan 15, 2014 at 3:22 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> On 15 January 2014 01:18, Alexander V. Chernikov <melifaro at freebsd.org> wrote:
>> On 14.01.2014 23:15, Nikolay Denev wrote:
>>>
>>> Hi,
>>>
>>> Currently it's implemented using Modulo-N Hash (RFC2991), see
>>> radix_mpath.c:rtalloc_mpath_fib()
>>
>> Yup. I'm going to change this to use flowid.
>>
>>>
>>> And as hash the xor of source and destination IP is supplied, look for
>>> rtalloc_mpath_fib() in ip_output.c :
>>>
>>>     ...
>>>     #ifdef RADIX_MPATH
>>>                          rtalloc_mpath_fib(ro,
>>>                              ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr),
>>>                              inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m));
>>>     #else
>>>     ...
>>>
>>> I've tried to hack this to use m_pkthdr.flowid if it exists, but in my
>>> case my network cards were not setting this (vr(4) on soekris) so I
>>
>> You can try http://static.ipfw.ru/patches/netisr_ip_flowid.diff to get
>> flowid values generated by netisr.
>
> Hm, this is interesting. I wonder if we should (finally) add in the
> toeplitz hash here and then make sure we are hashing the frame based
> on the right header contents and direction (so transmit and receive
> path frames hash to the same value.)
>
> What do you think?
>
>
> -a

Hi Adrian,

Probably a stupid question, but I'm trying to understand more about this,
so basically the benefit of using essentially an additive hash function would be
that both directions of the same flow/connection would end up for
processing on the same core?

--Nikolay