On 07/30/2015 04:12 AM, Tom Herbert wrote:
> On Tue, Jul 28, 2015 at 11:11 PM, Michal Kubecek <mkube...@suse.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
