From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ido Schimmel Subject: Re: [PATCH net-next v4] Documentation: networking: Clarify switchdev devices behavior Date: Fri, 11 Jan 2019 15:06:39 +0000 Message-ID: <20190111150637.GA897@splinter.mtl.com> References: <20190110193206.9872-1-f.fainelli@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "netdev@vger.kernel.org" , "davem@davemloft.net" , "andrew@lunn.ch" , "vivien.didelot@gmail.com" , "cphealy@gmail.com" , Jiri Pirko , "bridge@lists.linux-foundation.org" , "nikolay@cumulusnetworks.com" , "roopa@cumulusnetworks.com" , "rdunlap@infradead.org" , "ilias.apalodimas@linaro.org" , "ivan.khoronzhuk@linaro.org" To: Florian Fainelli Return-path: Received: from mail-eopbgr30045.outbound.protection.outlook.com ([40.107.3.45]:18944 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388611AbfAKPGo (ORCPT ); Fri, 11 Jan 2019 10:06:44 -0500 In-Reply-To: <20190110193206.9872-1-f.fainelli@gmail.com> Content-Language: en-US Content-ID: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Jan 10, 2019 at 11:32:06AM -0800, Florian Fainelli wrote: > This patch provides details on the expected behavior of switchdev > enabled network devices when operating in a "stand alone" mode, as well > as when being bridge members. This clarifies a number of things that > recently came up during a bug fixing session on the b53 DSA switch > driver. >=20 > Signed-off-by: Florian Fainelli > --- > Changes in v4: >=20 > - more spelling/grammar/sentence fixes (Randy) >=20 > Changes in v3: >=20 > - spell checks, past vs. present use (Randy) > - clarified some behaviors a bit more regarding multicast flooding > - added some missing sentence about multicast snopping knob being > dynamically turned on/off >=20 > Changes in v2: >=20 > - clarified a few parts about VLAN devices wrt. VLAN filtering and their > behavior during enslaving. >=20 > Documentation/networking/switchdev.txt | 105 +++++++++++++++++++++++++ > 1 file changed, 105 insertions(+) >=20 > diff --git a/Documentation/networking/switchdev.txt b/Documentation/netwo= rking/switchdev.txt > index 82236a17b5e6..dd58c957c557 100644 > --- a/Documentation/networking/switchdev.txt > +++ b/Documentation/networking/switchdev.txt > @@ -392,3 +392,108 @@ switchdev_trans_item_dequeue() > =20 > If a transaction is aborted during "prepare" phase, switchdev code will = handle > cleanup of the queued-up objects. > + > +Switchdev enabled network device expected behavior > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +Below is a set of defined behavior that switchdev enabled network device= s must > +adhere to. > + > +Configuration less state > +------------------------ > + > +Upon driver bring up, the network devices must be fully operational, and= the > +backing driver must configure the network device such that it is possibl= e to > +send and receive traffic to this network device and it is properly separ= ated > +from other network devices/ports (e.g.: as is frequent with a switch ASI= C). How > +this is achieved is heavily hardware dependent, but a simple solution ca= n be to > +use per-port VLAN identifiers unless a better mechanism is available > +(proprietary metadata for each network port for instance). > + > +The network device must be capable of running a full IP protocol stack > +including multicast, DHCP, IPv4/6, etc. If necessary, it should be progr= am the > +appropriate filters for VLAN, multicast, unicast etc. The underlying dev= ice > +driver must effectively be configured in a similar fashion to what it wo= uld do > +when IGMP snooping is enabled for IP multicast over these switchdev netw= ork > +devices and unsolicited multicast must be filtered as early as possible = into > +the hardware. > + > +When configuring VLANs on top of the network device, all VLANs must be w= orking, > +irrespective of the state of other network devices (e.g.: other ports be= ing part > +of a VLAN aware bridge doing ingress VID checking). See below for detail= s. > + > +Bridged network devices > +----------------------- > + > +When a switchdev enabled network device is added as a bridge member, it = should > +not disrupt any functionality of non-bridged network devices and they > +should continue to behave as normal network devices. Depending on the br= idge > +configuration knobs below, the expected behavior is documented. > + > +VLAN filtering > +~~~~~~~~~~~~~~ > + > +The Linux bridge allows the configuration of a VLAN filtering mode (comp= ile and > +run time) which must be observed by the underlying switchdev network > +device/hardware: > + > +- with VLAN filtering turned off: frames ingressing the device with a VI= D that > + is not programmed into the bridge/switch's VLAN table must be forwarde= d. When VLAN filtering is turned off the expectation is that only untagged frames will ingress the bridge. Either because they were sent untagged or because a VLAN device enslaved to the bridge untagged them. > + > +- with VLAN filtering turned on: frames ingressing the device with a VID= that is > + not programmed into the bridges/switch's VLAN table must be dropped. > + > +Non-bridged network ports of the same switch fabric must not be disturbe= d in any > +way, shape or form by the enabling of VLAN filtering. "shape or form" ? > + > +VLAN devices configured on top of a switchdev network device (e.g: sw0p1= .100) > +which is a bridge port member must also observe the following behavior: It is not clear where VLAN filtering is on / off. On the bridge the VLAN device is enslaved to I believe? Not the bridge the physical port is enslaved to. > + > +- with VLAN filtering turned off, these VLAN devices must be fully funct= ional > + since the hardware is allowed VID frames. Enslaving VLAN devices into = the "the hardware is allowed VID frames" ? > + bridge might be allowed provided that there is sufficient separation u= sing > + e.g.: a reserved VLAN ID (4095 for instance) for untagged traffic. > + > +- with VLAN filtering turned on, these VLAN devices should not be allowe= d to > + be created because they duplicate functionality/use case with the brid= ge's > + VLAN functionality. We always allow VLAN devices to be created. It is just that we don't allow their *enslavement* to VLAN-aware bridges. > + > +Because VLAN filtering can be turned on/off at runtime, the switchdev dr= iver > +must be able to re-configure the underlying hardware on the fly to honor= the > +toggling of that option and behave appropriately. > + > +A switchdev driver can also refuse to support dynamic toggling of the VL= AN > +filtering knob at runtime and require a destruction of the bridge device= (s) and > +creation of new bridge device(s) with a different VLAN filtering value t= o > +ensure VLAN awareness is pushed down to the HW. > + > +IGMP snooping > +~~~~~~~~~~~~~ > + > +The Linux bridge allows the configuration of IGMP snooping (compile and = run > +time) which must be observed by the underlying switchdev network device/= hardware > +in the following way: > + > +- when IGMP snooping is turned off, multicast traffic must be flooded to= all > + switch ports within the same broadcast domain. The CPU/management port > + should ideally not be flooded and continue to learn multicast traffic = through > + the network stack notifications. If the hardware is not capable of doi= ng that > + then the CPU/management port must also be flooded and multicast filter= ing > + happens in software. > + > +- when IGMP snooping is turned on, multicast traffic must selectively fl= ow > + to the appropriate network ports (including CPU/management port) and n= ot flood > + the switch. > + > +Note: reserved multicast addresses (e.g.: BPDUs) as well as Local Networ= k > +Control block (224.0.0.0 - 224.0.0.255) do not require IGMP and should a= lways > +be flooded. I'm not sure that these paragraphs are actually needed. You're basically describing RFC 4541 on which the IGMP snooping functionality in the Linux bridge is based on. > + > +Because IGMP snooping can be turned on/off at runtime, the switchdev dri= ver must > +be able to re-configure the underlying hardware on the fly to honor the = toggling > +of that option and behave appropriately. > + > +A switchdev driver can also refuse to support dynamic toggling of the mu= lticast > +snooping knob at runtime and require the destruction of the bridge devic= e(s) > +and creation of a new bridge device(s) with a different multicast snoopi= ng > +value. You should probably get the patch that allows this vetoing merged before sending this documentation patch. > --=20 > 2.17.1 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5042AC43387 for ; Fri, 11 Jan 2019 15:06:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0B91020874 for ; Fri, 11 Jan 2019 15:06:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="XZXZXmNO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391777AbfAKPGr (ORCPT ); Fri, 11 Jan 2019 10:06:47 -0500 Received: from mail-eopbgr30045.outbound.protection.outlook.com ([40.107.3.45]:18944 "EHLO EUR03-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388611AbfAKPGo (ORCPT ); Fri, 11 Jan 2019 10:06:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k6zchpLUT39RU5ntPZG8TmaYJNj5xg2jcPd61CUs2KQ=; b=XZXZXmNOrWg9QwwzJXazOYpXitywHJh5lQ1YoKhxf02iKnAqGxtFZWGIafGVdd0aqW47dWIJ5GPBscqAcJMw4FYZHEAy8DIgACSIjD5CZC3uLy6t3wZtQWFyu1EpLh2uUzJ5zoim7wzE+8QCdcQVA5lQn0kdV9ko0dtb2cJjxtE= Received: from AM6PR05MB6056.eurprd05.prod.outlook.com (20.179.2.148) by AM6PR05MB6199.eurprd05.prod.outlook.com (20.178.95.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Fri, 11 Jan 2019 15:06:39 +0000 Received: from AM6PR05MB6056.eurprd05.prod.outlook.com ([fe80::5490:e4ea:7798:e65f]) by AM6PR05MB6056.eurprd05.prod.outlook.com ([fe80::5490:e4ea:7798:e65f%3]) with mapi id 15.20.1516.016; Fri, 11 Jan 2019 15:06:39 +0000 From: Ido Schimmel To: Florian Fainelli CC: "netdev@vger.kernel.org" , "davem@davemloft.net" , "andrew@lunn.ch" , "vivien.didelot@gmail.com" , "cphealy@gmail.com" , Jiri Pirko , "bridge@lists.linux-foundation.org" , "nikolay@cumulusnetworks.com" , "roopa@cumulusnetworks.com" , "rdunlap@infradead.org" , "ilias.apalodimas@linaro.org" , "ivan.khoronzhuk@linaro.org" Subject: Re: [PATCH net-next v4] Documentation: networking: Clarify switchdev devices behavior Thread-Topic: [PATCH net-next v4] Documentation: networking: Clarify switchdev devices behavior Thread-Index: AQHUqRtgzFA7/KCYD0GTS2XYRQrioqWqLEiA Date: Fri, 11 Jan 2019 15:06:39 +0000 Message-ID: <20190111150637.GA897@splinter.mtl.com> References: <20190110193206.9872-1-f.fainelli@gmail.com> In-Reply-To: <20190110193206.9872-1-f.fainelli@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM6PR0102CA0026.eurprd01.prod.exchangelabs.com (2603:10a6:209:14::39) To AM6PR05MB6056.eurprd05.prod.outlook.com (2603:10a6:20b:ab::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=idosch@mellanox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [79.180.15.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AM6PR05MB6199;6:YNUd1ybmZ03RDnGTCMp7HEm2VVM790vhhpAUOEu3OUx+xZ4Fl/3rPGmIRBbgo/Uggi5yEFnKmKAxnoJspo4lZcS/n/PsZ4VsJPESgBZgnyuFdyMGS6Avqb2pjZk1eRQf9ChtLiE4bM2YGDdrD0itD3WQ/1I41jQE31BV1ov10ushfs6GGgp0qfzEczY1IC6ydIHyOIKIRZJwcjYE6oJtJjRJZwgCw21UE/YqrQkK0uwi4podoyBXtBJfatyMKHH76Ww7DiZBuGnUKd7rSV52OfoMzh7uQFR31Ij4DX0mamE512EAz8ebIViHeE7ChCDbejRr1Oranrhs/c91LTwTaCFn93hJkGTvTQKXhNeTmKBXJ7Yz3ynNlgGD5vLqGPHjl1x7GSePxcznHiMuzEzoS2sdgE9VKjw8EFccW7ueUddZw1tNe8K/7uaAEo1OFFb80Mn0Cmr0u+6BzTnoCtU7pg==;5:YLlv4eWZEqGq5+oNc8zbCCBYq09RlmnfpNNhcaHqdJWOfVvg9RE8BX7MHYnicPEytw57zwVy03cMEVrIZyQD0nme2D2p+0Tq2qnMT1th7TB0GnrUKuDucHDFiSDYbc2EmTiIZhkyiixP8clGeo8+GvgmjsVc1BcV93xqFMJIYK/vZ+zhL9KwwZDufJ8+ugE46ZHDDZVXplKwODe1AVn3zg==;7:2T4x3QBieFlU7eyqs2yLtT0nOcL/bJk9I1fJRg2Rqygl3IxJd5A36P0JOnDq/9SNrLIkPfeHuCwDZEQ2b4tJxIQVGOaZS0/Jbxe376BwMXB7DKY42/r1+2Z8HP/NZtmQds+VAJtxTVkYoK6wXttKIw== x-ms-office365-filtering-correlation-id: def6c8c0-1b16-42ec-4cf1-08d677d66346 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020);SRVR:AM6PR05MB6199; x-ms-traffictypediagnostic: AM6PR05MB6199: x-microsoft-antispam-prvs: x-forefront-prvs: 09144DB0F7 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(376002)(346002)(366004)(136003)(396003)(39860400002)(189003)(199004)(305945005)(3846002)(6916009)(106356001)(6116002)(4326008)(7736002)(39060400002)(105586002)(446003)(5660300001)(6436002)(11346002)(6506007)(25786009)(386003)(33896004)(486006)(7416002)(102836004)(26005)(478600001)(53936002)(52116002)(186003)(6246003)(76176011)(6512007)(6486002)(14454004)(9686003)(33656002)(8936002)(99286004)(81166006)(81156014)(8676002)(54906003)(551934003)(229853002)(86362001)(575784001)(1076003)(71200400001)(71190400001)(256004)(476003)(66066001)(97736004)(2906002)(68736007)(316002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM6PR05MB6199;H:AM6PR05MB6056.eurprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1sSgBG8i3LRVKTFlHikG6UzLD+KwrwkYHZ0jMa63Rk3pjh5Q31mTRoTSgtc6/ljlIC9nSEsLpunfviSetvM8pMpd67QnT9sFqUJur/H2GYaWpU6nPMCL5J4o+9qRLkI7pmu0L/O3oqLaCbXBPUIOwVqBO12R3MT70zdwu5Z41lSQZy3oljzAQnFbP3i7+kexAWxcfAaD1aGGDJPlHmC2GZI5UPWh4iUFRNU+FHzgvOeiqZlxrAzoYUqVVtpqumKx1q9sGUQRD9iV6nU2QH6HgyQqJa+tt1nSKt1JJo4H3oygEmSaYakBdSR+2ZVRLjYUTp+2LrDpwZBK31/KY/WkGNKFFoMjUlZC5fHjILs14iWYN0sO9gD3pMv/qnLaD1Bg1Xtbt+ggdy7f9raVrxC6Ri1D3KNxRKgrAvoqKrFYAHc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: def6c8c0-1b16-42ec-4cf1-08d677d66346 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 15:06:38.9190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB6199 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Message-ID: <20190111150639.KTElk17-OoIchFKFYK_N6UH94TxC_IF2ws6NzPEVqv0@z> On Thu, Jan 10, 2019 at 11:32:06AM -0800, Florian Fainelli wrote: > This patch provides details on the expected behavior of switchdev > enabled network devices when operating in a "stand alone" mode, as well > as when being bridge members. This clarifies a number of things that > recently came up during a bug fixing session on the b53 DSA switch > driver. >=20 > Signed-off-by: Florian Fainelli > --- > Changes in v4: >=20 > - more spelling/grammar/sentence fixes (Randy) >=20 > Changes in v3: >=20 > - spell checks, past vs. present use (Randy) > - clarified some behaviors a bit more regarding multicast flooding > - added some missing sentence about multicast snopping knob being > dynamically turned on/off >=20 > Changes in v2: >=20 > - clarified a few parts about VLAN devices wrt. VLAN filtering and their > behavior during enslaving. >=20 > Documentation/networking/switchdev.txt | 105 +++++++++++++++++++++++++ > 1 file changed, 105 insertions(+) >=20 > diff --git a/Documentation/networking/switchdev.txt b/Documentation/netwo= rking/switchdev.txt > index 82236a17b5e6..dd58c957c557 100644 > --- a/Documentation/networking/switchdev.txt > +++ b/Documentation/networking/switchdev.txt > @@ -392,3 +392,108 @@ switchdev_trans_item_dequeue() > =20 > If a transaction is aborted during "prepare" phase, switchdev code will = handle > cleanup of the queued-up objects. > + > +Switchdev enabled network device expected behavior > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +Below is a set of defined behavior that switchdev enabled network device= s must > +adhere to. > + > +Configuration less state > +------------------------ > + > +Upon driver bring up, the network devices must be fully operational, and= the > +backing driver must configure the network device such that it is possibl= e to > +send and receive traffic to this network device and it is properly separ= ated > +from other network devices/ports (e.g.: as is frequent with a switch ASI= C). How > +this is achieved is heavily hardware dependent, but a simple solution ca= n be to > +use per-port VLAN identifiers unless a better mechanism is available > +(proprietary metadata for each network port for instance). > + > +The network device must be capable of running a full IP protocol stack > +including multicast, DHCP, IPv4/6, etc. If necessary, it should be progr= am the > +appropriate filters for VLAN, multicast, unicast etc. The underlying dev= ice > +driver must effectively be configured in a similar fashion to what it wo= uld do > +when IGMP snooping is enabled for IP multicast over these switchdev netw= ork > +devices and unsolicited multicast must be filtered as early as possible = into > +the hardware. > + > +When configuring VLANs on top of the network device, all VLANs must be w= orking, > +irrespective of the state of other network devices (e.g.: other ports be= ing part > +of a VLAN aware bridge doing ingress VID checking). See below for detail= s. > + > +Bridged network devices > +----------------------- > + > +When a switchdev enabled network device is added as a bridge member, it = should > +not disrupt any functionality of non-bridged network devices and they > +should continue to behave as normal network devices. Depending on the br= idge > +configuration knobs below, the expected behavior is documented. > + > +VLAN filtering > +~~~~~~~~~~~~~~ > + > +The Linux bridge allows the configuration of a VLAN filtering mode (comp= ile and > +run time) which must be observed by the underlying switchdev network > +device/hardware: > + > +- with VLAN filtering turned off: frames ingressing the device with a VI= D that > + is not programmed into the bridge/switch's VLAN table must be forwarde= d. When VLAN filtering is turned off the expectation is that only untagged frames will ingress the bridge. Either because they were sent untagged or because a VLAN device enslaved to the bridge untagged them. > + > +- with VLAN filtering turned on: frames ingressing the device with a VID= that is > + not programmed into the bridges/switch's VLAN table must be dropped. > + > +Non-bridged network ports of the same switch fabric must not be disturbe= d in any > +way, shape or form by the enabling of VLAN filtering. "shape or form" ? > + > +VLAN devices configured on top of a switchdev network device (e.g: sw0p1= .100) > +which is a bridge port member must also observe the following behavior: It is not clear where VLAN filtering is on / off. On the bridge the VLAN device is enslaved to I believe? Not the bridge the physical port is enslaved to. > + > +- with VLAN filtering turned off, these VLAN devices must be fully funct= ional > + since the hardware is allowed VID frames. Enslaving VLAN devices into = the "the hardware is allowed VID frames" ? > + bridge might be allowed provided that there is sufficient separation u= sing > + e.g.: a reserved VLAN ID (4095 for instance) for untagged traffic. > + > +- with VLAN filtering turned on, these VLAN devices should not be allowe= d to > + be created because they duplicate functionality/use case with the brid= ge's > + VLAN functionality. We always allow VLAN devices to be created. It is just that we don't allow their *enslavement* to VLAN-aware bridges. > + > +Because VLAN filtering can be turned on/off at runtime, the switchdev dr= iver > +must be able to re-configure the underlying hardware on the fly to honor= the > +toggling of that option and behave appropriately. > + > +A switchdev driver can also refuse to support dynamic toggling of the VL= AN > +filtering knob at runtime and require a destruction of the bridge device= (s) and > +creation of new bridge device(s) with a different VLAN filtering value t= o > +ensure VLAN awareness is pushed down to the HW. > + > +IGMP snooping > +~~~~~~~~~~~~~ > + > +The Linux bridge allows the configuration of IGMP snooping (compile and = run > +time) which must be observed by the underlying switchdev network device/= hardware > +in the following way: > + > +- when IGMP snooping is turned off, multicast traffic must be flooded to= all > + switch ports within the same broadcast domain. The CPU/management port > + should ideally not be flooded and continue to learn multicast traffic = through > + the network stack notifications. If the hardware is not capable of doi= ng that > + then the CPU/management port must also be flooded and multicast filter= ing > + happens in software. > + > +- when IGMP snooping is turned on, multicast traffic must selectively fl= ow > + to the appropriate network ports (including CPU/management port) and n= ot flood > + the switch. > + > +Note: reserved multicast addresses (e.g.: BPDUs) as well as Local Networ= k > +Control block (224.0.0.0 - 224.0.0.255) do not require IGMP and should a= lways > +be flooded. I'm not sure that these paragraphs are actually needed. You're basically describing RFC 4541 on which the IGMP snooping functionality in the Linux bridge is based on. > + > +Because IGMP snooping can be turned on/off at runtime, the switchdev dri= ver must > +be able to re-configure the underlying hardware on the fly to honor the = toggling > +of that option and behave appropriately. > + > +A switchdev driver can also refuse to support dynamic toggling of the mu= lticast > +snooping knob at runtime and require the destruction of the bridge devic= e(s) > +and creation of a new bridge device(s) with a different multicast snoopi= ng > +value. You should probably get the patch that allows this vetoing merged before sending this documentation patch. > --=20 > 2.17.1 >=20