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

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: <CAJieiUgQpOidyE-OH73QQpMcQnzEgd+9bGPOKA-yAaFtb3fcwQ@mail.gmail.com>
Date:   Tue, 14 Mar 2017 15:38:40 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     David Miller <davem@...emloft.net>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        David Ahern <dsa@...ulusnetworks.com>, jkbs@...hat.com,
        Eric Dumazet <edumazet@...gle.com>,
        Peter Christensen <pch@...bogen.com>
Subject: Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

On Tue, Mar 14, 2017 at 2:42 PM, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> On Tue, 14 Mar 2017 14:10:22 -0700
> Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>
>> On Tue, Mar 14, 2017 at 1:25 PM, Stephen Hemminger
>> <stephen@...workplumber.org> wrote:
>> > On Tue, 14 Mar 2017 11:48:37 -0700 (PDT)
>> > David Miller <davem@...emloft.net> wrote:
>> >
>> >> From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>

[snip]


>> >> > 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.

ok. understand the switchdev offload part. It was that way in the past...but
today you can listen to sysctl updates on the netconf netlink channel.
it works pretty well.

>
> 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.
>

agree. Most of the discussion around this has happened on the netdev
mailing list so far.
The previous set that updated ecmp algo tried to add a per route
attribute and after review on this list was moved to
on by default. Nikolay's first version included a per route
attribute...to follow the previous ecmp work.
Before Nikolay posted the second version, my feedback was to make it
global. And this feedback was only re-iterated at
last netconf/netdev. so, we can continue the discussion here if there
are other opinions.