From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [PATCH net-next] net/ipv6: Block IPv6 addrconf on team ports Date: Fri, 26 Oct 2018 08:01:06 +0200 Message-ID: <20181026060106.GB2229@nanopsycho.orion> References: <20181025210227.25544-1-3chas3@gmail.com> <25151.1540504752@famine> <26415.1540507231@famine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chas Williams <3chas3@gmail.com>, davem@davemloft.net, netdev@vger.kernel.org, vfalico@gmail.com, andy@greyhouse.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org To: Jay Vosburgh Return-path: Received: from mail-wr1-f67.google.com ([209.85.221.67]:39782 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725893AbeJZOmk (ORCPT ); Fri, 26 Oct 2018 10:42:40 -0400 Received: by mail-wr1-f67.google.com with SMTP id r10-v6so22735wrv.6 for ; Thu, 25 Oct 2018 23:07:01 -0700 (PDT) Content-Disposition: inline In-Reply-To: <26415.1540507231@famine> Sender: netdev-owner@vger.kernel.org List-ID: Fri, Oct 26, 2018 at 12:40:31AM CEST, jay.vosburgh@canonical.com wrote: >Chas Williams <3chas3@gmail.com> wrote: > >>On 10/25/2018 05:59 PM, Jay Vosburgh wrote: >>> Chas Williams <3chas3@gmail.com> wrote: >>> >>>> netif_is_lag_port should be used to identify link aggregation ports. >>>> For this to work, we need to reorganize the bonding and team drivers >>>> so that the necessary flags are set before dev_open is called. >>>> >>>> commit 31e77c93e432 ("sched/fair: Update blocked load when newly idle") >>>> made this decision originally based on the IFF_SLAVE flag which isn't >>>> used by the team driver. Note, we do need to retain the IFF_SLAVE >>>> check for the eql driver. >>> >>> Is 31e77c93e432 the correct commit reference? I don't see >>> anything in there about IFF_SLAVE or bonding; it's a patch to the >>> process scheduler. >> >>No, that's wrong. It should be c2edacf80e155. >> >>> And, as Jiri said, the subject doesn't mention bonding. >> >>The behavior of bonding wasn't changed. The intent of the patch >>is to add team slaves to the interfaces that don't get automatic >>IPv6 addresses. The body discusses why bonding had to change as >>well. > > Sure, but the bonding code has changed, and the current >presentation makes it harder for reviewers to follow (or perhaps even >notice). > >>I was under the impression that the subject needs to kept short. >>If there a better way to phrase what I want to do? > > I'd suggest splitting this into three patches: A first patch >that adds the new IPv6 functionality, then one patch each for team and >bonding to take advantage of that new functionality. Each of the three >would then be very straightforward, change just one thing, and should be >clearer all around. +1