netdev - Re: [RFC PATCH 1/1] net/ipv4: Enable flow-based ECMP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55B97CAC.3010004@alliedtelesis.co.nz>
Date:	Thu, 30 Jul 2015 01:23:57 +0000
From:	Richard Laing <Richard.Laing@...iedtelesis.co.nz>
To:	Tom Herbert <tom@...bertland.com>,
	Michal Kubecek <mkubecek@...e.cz>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>
Subject: Re: [RFC PATCH 1/1] net/ipv4: Enable flow-based ECMP



On 07/30/2015 04:12 AM, Tom Herbert wrote:
> On Tue, Jul 28, 2015 at 11:11 PM, Michal Kubecek <mkubecek@...e.cz> wrote:
>> On Tue, Jul 28, 2015 at 09:20:02PM +0000, Richard Laing wrote:
>>>>> diff --git a/include/net/flow.h b/include/net/flow.h
>>>>> index 8109a15..d1d933d 100644
>>>>> --- a/include/net/flow.h
>>>>> +++ b/include/net/flow.h
>>>>> @@ -79,6 +79,10 @@ struct flowi4 {
>>>>>     #define fl4_ipsec_spi        uli.spi
>>>>>     #define fl4_mh_type        uli.mht.type
>>>>>     #define fl4_gre_key        uli.gre_key
>>>>> +
>>>>> +#ifdef CONFIG_IP_FLOW_BASED_MULTIPATH
>>>> Why bother making this a CONFIG, round robin is a miserable algorithm
>>>> anyway and nearly all the other packet steering mechanisms already use
>>>> a hash.
>>> Fair enough, I will look at making it a sysctl option. I guess the
>>> default can be the current behaviour.
>> Hm... that's an interesting question. In general, it's better to use
>> current behaviour as a default so that people are not surprised on
>> upgrade. On the other hand, it used to be per-flow  - or rather per
>> destination - earlier (until the routing cache removal, I believe) and
>> per-flow distribution is IMHO preferrable in majority of use cases. In
>> theory, there was a route attribute "equalize" to switch to per-packet
>> distribution, but it was never actually implemented, AFAIK (it was
>> recognized by ip and passed to kernel but ignored there).
>>
>> Anyway, config option is definitely inconvenient as most users install
>> distribution kernels and do not configure their kernels themselves. Even
>> boot parameter would be better - but sysctl sounds much better. Having
>> both sysctl and per-route attribute would be perfect, of course.
>>
> IPv6 routing already uses a hash without any capability of setting
> this to be round robin, probably every network device on the planet
> performs ECMP using a hash since it is stateless algorithm, and as I
> pointed most of our other packet steering mechanisms use a hash. So
> the IPv4 path seems to be the odd man out here. Keeping round robin
> seems around awfully conservative to me, and implies that we need to
> implement it in IPv6 to maintain feature parity.
>
> Tom

Thanks Tom, I would certainly agree that flow based is preferable to the current behaviour and would be happy to make it the default. I will update my patch with the feedback and send an update, no ETA right now!

Cheers
Richard

--
Richard Laing
Software Team Leader
Allied Telesis Labs| 27 Nazareth Ave | Christchurch 8024 | New Zealand
Phone: +64 3 339 9248
Web: www.alliedtelesis.com