Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

On Tue, 14 Mar 2017 14:10:22 -0700
Roopa Prabhu [off-list ref] wrote:

On Tue, Mar 14, 2017 at 1:25 PM, Stephen Hemminger
[off-list ref] wrote:

quoted

On Tue, 14 Mar 2017 11:48:37 -0700 (PDT)
David Miller [off-list ref] wrote:
 

quoted

From: Nikolay Aleksandrov <redacted>
Date: Tue, 14 Mar 2017 17:58:46 +0200
 

quoted

On 14/03/17 17:55, Stephen Hemminger wrote:  

quoted

On Tue, 14 Mar 2017 17:36:15 +0200
Nikolay Aleksandrov [off-list ref] wrote:
 

quoted

This patch adds support for ECMP hash policy choice via a new sysctl
called fib_multipath_hash_policy and also adds support for L4 hashes.
The current values for fib_multipath_hash_policy are:
 0 - layer 3 (default)
 1 - layer 4
If there's an skb hash already set and it matches the chosen policy then it
will be used instead of being calculated (currently only for L4).
In L3 mode we always calculate the hash due to the ICMP error special
case, the flow dissector's field consistentification should handle the
address order thus we can remove the address reversals.

Signed-off-by: Nikolay Aleksandrov <redacted>  

It is good to see ECMP come back from the grave.
Linux used to support it long ago but was abandoned after it was unstable
and removed from iproute2 in 2012.

The old API was through route attributes which makes more sense than
doing it with sysctl. It makes more sense to use netlink instead.
Therefore please go back and do something like the old API rather than doing it through
sysctl.
 

That's what my initial version did, but this was discussed during NetConf in Seville
and it was decided that it's best to make a global sysctl, thus the change.  

Correct, we discussed this, and we all agreed to only have a sysctl for now.  

Why? If you are going to have private discussions please post the rationale
in public.  

Stephen, is there any reason to have a per ecmp route multipath algo
selection ?.
All platforms have a global multipath selection algo. I also don't see
routing daemons ready or willing to specify a per ecmp route multipath
selection algo attribute.

There is no compelling reason to make the attribute per route. But the
issue is more that configuration through sysctl's is problematic. It doesn't
fit into the standard API paradigm. Sysctl's are like routing patches not
part of the real CLI. Trying to trap sysctl's for things like switchedev
offload is particularly problematic. I can see the case for either way,
and don't have a fixed opinion.

The bigger discussion is trying to keep a record of the rationale for decisions
such that there isn't buried tribal knowledge. This is why Dave has always been
quite insistent on having discussions on the mailing list. There doesn't seem to
be a good long term record other than Documentation/networking or commit logs.