From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Wilkie Subject: Re: [PATCH net-next] team: account for oper state Date: Wed, 18 Apr 2018 16:33:12 +0100 Message-ID: <20180418153312.24h7mvle6sy2dv25@debian9.gwilkie> References: <20180418102950.1033-1-gwilkie@vyatta.att-mail.com> <20180418125644.GD1989@nanopsycho> <20180418133549.qd5uqp3km45vw3ar@debian9.gwilkie> <20180418145822.GE1989@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: Jiri Pirko Return-path: Received: from mx0b-00191d01.pphosted.com ([67.231.157.136]:45978 "EHLO mx0a-00191d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750872AbeDRPdg (ORCPT ); Wed, 18 Apr 2018 11:33:36 -0400 Content-Disposition: inline In-Reply-To: <20180418145822.GE1989@nanopsycho> Sender: netdev-owner@vger.kernel.org List-ID: 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(). 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 > >> >