From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Wilkie Subject: Re: [PATCH net-next] team: account for oper state Date: Thu, 19 Apr 2018 10:33:41 +0100 Message-ID: <20180419093341.7yxd74dlzqpbo7hc@debian9.gwilkie> References: <20180418102950.1033-1-gwilkie@vyatta.att-mail.com> <20180418125644.GD1989@nanopsycho> <20180418133549.qd5uqp3km45vw3ar@debian9.gwilkie> <20180418145822.GE1989@nanopsycho> <20180418153312.24h7mvle6sy2dv25@debian9.gwilkie> <20180418191732.GB1922@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: Jiri Pirko Return-path: Received: from mx0a-00191d01.pphosted.com ([67.231.149.140]:58940 "EHLO mx0a-00191d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753099AbeDSJeL (ORCPT ); Thu, 19 Apr 2018 05:34:11 -0400 Content-Disposition: inline In-Reply-To: <20180418191732.GB1922@nanopsycho> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Apr 18, 2018 at 09:17:32PM +0200, Jiri Pirko wrote: > Wed, Apr 18, 2018 at 05:33:12PM CEST, gwilkie@vyatta.att-mail.com wrote: > >On Wed, Apr 18, 2018 at 04:58:22PM +0200, Jiri Pirko wrote: > >> Wed, Apr 18, 2018 at 03:35:49PM CEST, gwilkie@vyatta.att-mail.com wrote: > >> >On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote: > >> >> Wed, Apr 18, 2018 at 12:29:50PM CEST, gwilkie@vyatta.att-mail.com wrote: > >> >> >Account for operational state when determining port linkup state, > >> >> >as per Documentation/networking/operstates.txt. > >> >> > >> >> Could you please point me to the exact place in the document where this > >> >> is suggested? > >> >> > >> > > >> >Various places cover it I think. > >> > > >> >In 1. Introduction: > >> >"interface is not usable just because the admin enabled it" > >> >"userspace must be granted the possibility to > >> >influence operational state" > >> > > >> >In 4. Setting from userspace: > >> >"the userspace application can set IFLA_OPERSTATE > >> >to IF_OPER_DORMANT or IF_OPER_UP as long as the driver does not set > >> >netif_carrier_off() or netif_dormant_on()" > >> > > >> >We have a use case where we want to set the oper state of the team ports based > >> >on whether they are actually usable or not (as opposed to just admin up). > >> > >> Are you running a supplicant there or what is the use-case? > >> > > > >We are using tun/tap interfaces for the team ports with the physical interfaces > >under the control of a user process. > > > >> How is this handle in other drivers like bond, openvswitch, bridge, etc? > > > >It looks like bridge is using it, looking at br_port_carrier_check() and > >br_add_if(). > > Okay, so why do you still need to check netif_carrier_ok? > Looks like netif_oper_up is enough, right? Yes, I was being overly cautious. Replacing netif_carrier_ok with netif_oper_up works OK. I'll send updated patch. Cheers. > > > > > >Cheers. > > > >> > >> > > >> >Cheers. > >> > > >> >> > >> >> > > >> >> >Signed-off-by: George Wilkie > >> >> >--- > >> >> > drivers/net/team/team.c | 3 ++- > >> >> > 1 file changed, 2 insertions(+), 1 deletion(-) > >> >> > > >> >> >diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c > >> >> >index a6c6ce19eeee..231264a05e55 100644 > >> >> >--- a/drivers/net/team/team.c > >> >> >+++ b/drivers/net/team/team.c > >> >> >@@ -2918,7 +2918,8 @@ static int team_device_event(struct notifier_block *unused, > >> >> > case NETDEV_CHANGE: > >> >> > if (netif_running(port->dev)) > >> >> > team_port_change_check(port, > >> >> >- !!netif_carrier_ok(port->dev)); > >> >> >+ !!(netif_carrier_ok(port->dev) && > >> >> >+ netif_oper_up(port->dev))); > >> >> > break; > >> >> > case NETDEV_UNREGISTER: > >> >> > team_del_slave(port->team->dev, dev); > >> >> >-- > >> >> >2.11.0 > >> >> > > >