From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [PATCH net-next] team: account for oper state Date: Wed, 18 Apr 2018 21:17:32 +0200 Message-ID: <20180418191732.GB1922@nanopsycho> References: <20180418102950.1033-1-gwilkie@vyatta.att-mail.com> <20180418125644.GD1989@nanopsycho> <20180418133549.qd5uqp3km45vw3ar@debian9.gwilkie> <20180418145822.GE1989@nanopsycho> <20180418153312.24h7mvle6sy2dv25@debian9.gwilkie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: George Wilkie Return-path: Received: from mail-wr0-f194.google.com ([209.85.128.194]:45113 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751830AbeDRTRe (ORCPT ); Wed, 18 Apr 2018 15:17:34 -0400 Received: by mail-wr0-f194.google.com with SMTP id u11-v6so7680146wri.12 for ; Wed, 18 Apr 2018 12:17:33 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20180418153312.24h7mvle6sy2dv25@debian9.gwilkie> Sender: netdev-owner@vger.kernel.org List-ID: 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? > >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 >> >> >