Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754089AbcCIVnf (ORCPT ); Wed, 9 Mar 2016 16:43:35 -0500 Received: from mail-db3on0094.outbound.protection.outlook.com ([157.55.234.94]:60608 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750819AbcCIVn0 (ORCPT ); Wed, 9 Mar 2016 16:43:26 -0500 Authentication-Results: savoirfairelinux.com; dkim=none (message not signed) header.d=none;savoirfairelinux.com; dmarc=none action=none header.from=mellanox.com; Date: Wed, 9 Mar 2016 23:42:14 +0200 From: Ido Schimmel To: Vivien Didelot CC: , , , "David S. Miller" , Florian Fainelli , Andrew Lunn , "Scott Feldman" , Jiri Pirko , , Elad Raz Subject: Re: [RFC PATCH net-next 1/2] net: bridge: add switchdev attr for port bridging Message-ID: <20160309214214.GA4865@colbert.idosch.org> References: <1457545368-20647-1-git-send-email-vivien.didelot@savoirfairelinux.com> <1457545368-20647-2-git-send-email-vivien.didelot@savoirfairelinux.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1457545368-20647-2-git-send-email-vivien.didelot@savoirfairelinux.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [149.78.144.178] X-ClientProxiedBy: AM3PR03CA017.eurprd03.prod.outlook.com (10.141.191.145) To VI1PR05MB0991.eurprd05.prod.outlook.com (25.162.11.139) X-Microsoft-Exchange-Diagnostics: 1;VI1PR05MB0991;2:HAOSCOnmKgsAtpd+ndh/ACi5GBo0992Fm5wt9TY8tP1GDj4jlUaduH3cjQvIvC2VK2ekW15FJ0wc2CELZL4DUUojzaH2B69+grxJWMf+FCZzIMLG/DVBt1/GApXPNNDPr93120UwK/nyzi5P37ToTA==;3:AKoaDrl12l1wQ9MxxORERWrT65Go36dSHxg3qV0doDGY18NogBsEhrjaYoecuBEteMSsF8GwEYRyZ1L2DaUz0usEWpGfLI9j7ccUWRTiR7V85Yp5EoMSHaMEumRQE11a;25:PL+7dXM/cLiN9ObxiyVn1M2Yxdf9kIrH5vKb0NzszzOgtd23BXFbh3Zjw6HL82my6xWn8y9Rmd6l5nvw/X7jxnX5Ah4JWIGSbvQal5P5iwQwTqqkj/b31wqgkpHKoerVQaQBjabNUwwtL3o3ZeaR5tSHedkGm+1313DfuU2MOs+ZJC5kwAFaqfTIMT57Vv8xQWCr9g3kbOWURfVdYa+BXrM32ha+mcp/b4IKenYKWpWgWXSddteub5xTXiDzHT46WFJNeN9ETJVHnXvRJUC6nSJM3OYGfeIikrDRk5oesWHLhLk43JtxihbmrMa55zSvY+oli6TQp+oPkFG/16iVlw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB0991; X-MS-Office365-Filtering-Correlation-Id: 8be3ce83-e578-49c9-80c2-08d34863d5f6 X-Microsoft-Exchange-Diagnostics: 1;VI1PR05MB0991;20:ib85ErTD+2LlxSUdIa+e2fCVNFsgtVpE0nyN4mmnEBQjTdFXzow6Eagl6WYRlsjEXXgBGeG9VCgZY2gRc1E20gSOK0Gc916hfVLoUOIWq3Fj/qpyoNFaIh40xZLciR95dB5+5huHSRf1LkgAxOEjfK8Y8djV08GtfArz44/BTN7gpFGQsTFYn+UJfh/eZiqxgsE0jUFZ0jAaFCEi19xxPPKaIZjoFHZOYZoBtVGo8xw7R3ONP897BhyHHv1BAc/ratswXbhhxOVVznszBvjrv7iAqcATutWkNHCz5iVQB092FVdjklsAuvpiLXIPAya3EwNjPJl4WmYaUqlqm7LHa6soiSyAj0+vbZmMeFDsLemIAzLRkgHz8SFVhFF1wScz9Y9uQmhjENPoiiF/x18Ibrj++oC2EfXNdnPZoExX1ZNjsQbzd1DBDtid2oS8IbC8iYpMn2GCYhoxN3eUQlvwOkTF1LSo/sqsf6elP6PVv6Gw5ax2x6uOTjBqeSQPKlQ6;4:QDfUp/0MCrSHFqSVZlfMy5rJKyVN1D60m3QzrxBOlwdVHaPzfUanhaZq5vaYB8EMrG/QjBrXF00V+7KXFTLDayHhEFdyD6FZXvqQT4bfLCvTHNVu+fQEufOAVSjR6QRurVFlYRj4LemEitnADH9zlHSwz0ykFZ2zFdjwn5HeB0Eu+RYySqzjB2U5noCenaagS4rwcv57kbT0qS1ySum5K8E9k3dDAYwKRaph5rojJ9hFHcDUI8F7FvqU8rRDGS6YmuRggTqzIFU7PkqgIgZ/T7ANt/8xYsdCrPvJ+srzEyAPvZ6DN3BR/75uTz//DaQOm8wEzyeSnJqXMriTUlMj2GWIj0Cn+7k4P7tHcJ53QRMoMY1vxEtfM6MYlOa02o+C X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:VI1PR05MB0991;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB0991; X-Forefront-PRVS: 0876988AF0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(24454002)(86362001)(50466002)(2906002)(92566002)(4326007)(76176999)(54356999)(50986999)(3846002)(23726003)(5004730100002)(47776003)(66066001)(4001430100002)(42186005)(1076002)(83506001)(19580395003)(110136002)(5008740100001)(6116002)(33656002)(586003)(77096005)(107886002)(76506005)(81166005)(46406003)(19580405001)(189998001)(1096002)(2950100001)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR05MB0991;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;VI1PR05MB0991;23:fiLq0TMLJmu7CZrj2QKr01pQG8njcRLGXMlFSP6JU?= =?us-ascii?Q?xGSTOcUDhFFbTQ7jY2i8C8O0a4sY08HBcZELhZS5kTx7y5jt4MqQwg7emgGD?= =?us-ascii?Q?XNB56QOJJ/2rK5shQ2+BQ1AB5XdpO9LGxSpjeJhr4534QjoaoT//fGcAlH8A?= =?us-ascii?Q?qOVrVX3tjQr9X6/hq3GfI+rgVbcdxmjx1bNormriL9gyA/ccBEQFJymHHUjG?= =?us-ascii?Q?/o+g1UqFCT1hcAR4OFe0drHV3SkPoH9+0LtygGrWvTWtDmiWAf5XRf/uTV3p?= =?us-ascii?Q?f7rmJPmef6qwp/TSWBmgplntwTkFD6UviUzDf3JagybbVB1MmVSRwc8wuGfw?= =?us-ascii?Q?h781jAvPqI477DOMjoLPHSV6pgPSwIVfjf3xIGv7Liz9ZZi8BXs1XB6I0mqE?= =?us-ascii?Q?EtcZtFhIXxWs8yv4/23f9EqF4e6SMfK7EFViJXcMMmZGJ6Xr8dKQKCdG9BRk?= =?us-ascii?Q?GKN03ILCKTOVYkjTCEA+N9Z9M7nuk16etA+ORkxCh6V3T422kYhNikmg2FTp?= =?us-ascii?Q?JJVBCZmapB7PiCJYfSkRfvsDJaUfHKNn7h7a8WJhm+hcLQjHb73x+AlVuG19?= =?us-ascii?Q?SQuuno4fGLb4iqEcBLULm3qz052hkn28J0O/nkK8IxSR0eNPEmEu9mw1rUrb?= =?us-ascii?Q?yP61oXiRPQybrGXbP5EOYMCZJOUU7h6YVc1nfsXzV+3pZg+O7BLt1U1d+f32?= =?us-ascii?Q?nW0v2NEoqG3Vecl6jbI1QfCvJda6ZMH4gVNkSNdyITho8kyl0us9S/NGuu3k?= =?us-ascii?Q?ll0RrtOWpqq0I1saVzGQMoS8+ZjE1NGcneNmSPzYdYd0NpGXdlNB8YhWeFqw?= =?us-ascii?Q?I26ZlG9z1JIOLgdWwp/OSykTwou40rp6Q5ZsKjr/Kh9Gcl1ibgiASISdD+if?= =?us-ascii?Q?m3PMCF5+sjcVY5XqNpc9hBJNYUdNiju76iUyS0/x9ye9e0Nz1bYBSovFR+tj?= =?us-ascii?Q?xAn3fqpRDUroJgDqMbMBU96zFiFz9n8DeInhbJnpw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR05MB0991;5:t3j4T1vA3oey8g7bNrlZDHuI9w7PV1mYmhMU9a1H4Y8OXiBu/w3i1YeFzbQ+uc5j9mafSiX2ZyG+tu9rqGkf7fn4HGTuUSVVvh9Lw2XAC80Qe833L7W4+nmnulAr/ffUah/PEMh92UKZoTAEKBYJGw==;24:QQeo9g1EbVdr6X9DovDXpWVCcEoHglLN/ASpX5+TOidZ345CDSoQiNlXEPqmECSeVr7GY0ETuJsMbzzhG+43rilMdwdadV3B2IIdcJzQBwo= X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2016 21:43:21.4598 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB0991 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4057 Lines: 123 Hi Vivien, Wed, Mar 09, 2016 at 07:42:47PM IST, vivien.didelot@savoirfairelinux.com wrote: >Add a new SWITCHDEV_ATTR_ID_PORT_BRIDGE_IF switchdev attribute which is >set before adding a port to a bridge and deleting a port from a bridge. > >The main purpose for this attribute is to provide switchdev users a >simple and common way to retrieve bridging information, instead of >implementing complex notifier blocks to listen to global netdev events. > >We can also imagine a switchdev user returning an error different from >-EOPNOTSUPP in the prepare phase to prevent a port from being bridged. I don't really understand the motivation for this change. We are already doing all these stuff with the notifiers and it's pretty straight-forward. In fact, I believe using an existing mechanism instead of introducing more switchdev hooks is more elegant. This RFC only deals with bridge, but you'll have to do the same for team, bond and vlan devices. And you'll probably place the hooks in the exact locations where the notifiers are called from anyway. > >Signed-off-by: Vivien Didelot >--- > include/net/switchdev.h | 2 ++ > net/bridge/br_if.c | 27 +++++++++++++++++++++++++++ > 2 files changed, 29 insertions(+) > >diff --git a/include/net/switchdev.h b/include/net/switchdev.h >index d451122..65f8514 100644 >--- a/include/net/switchdev.h >+++ b/include/net/switchdev.h >@@ -46,6 +46,7 @@ enum switchdev_attr_id { > SWITCHDEV_ATTR_ID_PORT_PARENT_ID, > SWITCHDEV_ATTR_ID_PORT_STP_STATE, > SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS, >+ SWITCHDEV_ATTR_ID_PORT_BRIDGE_IF, > SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME, > SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING, > }; >@@ -58,6 +59,7 @@ struct switchdev_attr { > struct netdev_phys_item_id ppid; /* PORT_PARENT_ID */ > u8 stp_state; /* PORT_STP_STATE */ > unsigned long brport_flags; /* PORT_BRIDGE_FLAGS */ >+ bool join; /* PORT_BRIDGE_IF */ > u32 ageing_time; /* BRIDGE_AGEING_TIME */ > bool vlan_filtering; /* BRIDGE_VLAN_FILTERING */ > } u; >diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c >index a73df33..105b9fd 100644 >--- a/net/bridge/br_if.c >+++ b/net/bridge/br_if.c >@@ -28,6 +28,24 @@ > > #include "br_private.h" > >+static int switchdev_bridge_if(struct net_device *dev, struct net_bridge *br, >+ bool join) >+{ >+ struct switchdev_attr attr = { >+ .orig_dev = br->dev, This should be just 'dev', since you need to know for which stacked device on top of the port this was called for. This also means you'll have to call netdev_master_upper_dev_get() from within your driver if you want to limit the number of VLAN filtering bridges (for example). However, since this is called before bridge dev and dev itself are linked, you'll get NULL. >+ .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_IF, >+ .flags = SWITCHDEV_F_SKIP_EOPNOTSUPP, >+ .u.join = join, >+ }; >+ int err; >+ >+ err = switchdev_port_attr_set(dev, &attr); >+ if (err && err != -EOPNOTSUPP) >+ return err; >+ >+ return 0; >+} >+ > /* > * Determine initial path cost based on speed. > * using recommendations from 802.1d standard >@@ -297,6 +315,10 @@ static void del_nbp(struct net_bridge_port *p) > br_netpoll_disable(p); > > call_rcu(&p->rcu, destroy_nbp_rcu); >+ >+ if (switchdev_bridge_if(dev, br, false)) >+ br_warn(br, "error unbridging port %u(%s)\n", >+ (unsigned int) p->port_no, dev->name); > } > > /* Delete bridge device */ >@@ -347,6 +369,11 @@ static struct net_bridge_port *new_nbp(struct net_bridge *br, > { > int index; > struct net_bridge_port *p; >+ int err; >+ >+ err = switchdev_bridge_if(dev, br, true); If you look at br_add_if() - where new_nbp() is called from - then you'll see that you aren't rollbacking this operation in case of error. Same for subsequent errors in this function I believe. >+ if (err) >+ return ERR_PTR(err); > > index = find_portno(br); > if (index < 0) >-- >2.7.2 > Maybe this is something we'll have to do in the future, but for now I think we are OK with the notifiers. :) Thanks Vivien!