All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: nicolas.dichtel@6wind.com
Cc: David Ahern <dsa@cumulusnetworks.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Roopa Prabhu <roopa@cumulusnetworks.com>,
	David Miller <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	jkbs@redhat.com, Eric Dumazet <edumazet@google.com>,
	Peter Christensen <pch@ordbogen.com>
Subject: Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice
Date: Wed, 15 Mar 2017 12:46:23 +0200	[thread overview]
Message-ID: <B403ACFE-A028-454D-94C1-F7023457C87C@cumulusnetworks.com> (raw)
In-Reply-To: <5b5cf0ac-d152-3c8e-d54b-1059f561efee@6wind.com>


> On Mar 15, 2017, at 11:17 AM, Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> 
> Le 15/03/2017 à 00:45, David Ahern a écrit :
>> On 3/14/17 5:27 PM, Stephen Hemminger wrote:
>>> On Tue, 14 Mar 2017 15:38:40 -0700
>>> Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>>> 
>>>>>>>>> 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.
>>> 
>>> Is there another patch to add the NETCONFA_ECMP support?
>>> 
>> 
>> does userspace care?
> Yes, I think it is needed so that userspace can correctly monitor this behavior.
> It also enables to check this parameter through netlink.
> 
> 
> Regards,
> Nicolas

This doesn’t fit the NETCONFA model well, there is no “all”, “default” or per iface option to be set, also
the other multipath sysctl which affects behaviour doesn’t have a notification.

Thanks,
 Nik

  reply	other threads:[~2017-03-15 10:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 14:59 [PATCH net-next] net: ipv4: add support for ECMP hash policy choice Nikolay Aleksandrov
2017-03-06 16:24 ` David Ahern
2017-03-06 16:52   ` Nikolay Aleksandrov
2017-03-07  6:16 ` Roopa Prabhu
2017-03-07 11:01 ` [PATCH net-next v2] " Nikolay Aleksandrov
2017-03-08 12:05   ` Jakub Sitnicki
2017-03-08 12:43     ` Nikolay Aleksandrov
2017-03-08 16:00       ` Jakub Sitnicki
2017-03-13  2:23         ` David Miller
2017-03-14 15:36   ` [PATCH net-next v3] " Nikolay Aleksandrov
2017-03-14 15:55     ` Stephen Hemminger
2017-03-14 15:58       ` Nikolay Aleksandrov
2017-03-14 18:48         ` David Miller
2017-03-14 20:25           ` Stephen Hemminger
2017-03-14 21:10             ` Roopa Prabhu
2017-03-14 21:42               ` Stephen Hemminger
2017-03-14 22:38                 ` Roopa Prabhu
2017-03-14 23:27                   ` Stephen Hemminger
2017-03-14 23:45                     ` David Ahern
2017-03-15  9:17                       ` Nicolas Dichtel
2017-03-15 10:46                         ` Nikolay Aleksandrov [this message]
2017-03-15 11:18                           ` Nicolas Dichtel
2017-03-15 11:27                             ` Nikolay Aleksandrov
2017-03-15 15:01                         ` David Ahern
2017-03-15 15:20                           ` Stephen Hemminger
2017-03-15  0:24             ` David Miller
2017-03-15  2:30               ` Tom Herbert
2017-03-17  3:36                 ` David Miller
2017-03-14 18:55     ` Nikolay Aleksandrov
2017-03-15 11:32     ` Jakub Sitnicki
2017-03-15 12:10       ` Nikolay Aleksandrov
2017-03-16 13:28   ` [PATCH net-next v4] " Nikolay Aleksandrov
2017-03-16 16:41     ` Stephen Hemminger
2017-03-16 16:49       ` Nikolay Aleksandrov
2017-03-17 10:06         ` Nikolay Aleksandrov
2017-03-21 22:28     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B403ACFE-A028-454D-94C1-F7023457C87C@cumulusnetworks.com \
    --to=nikolay@cumulusnetworks.com \
    --cc=davem@davemloft.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=edumazet@google.com \
    --cc=jkbs@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=pch@ordbogen.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.