From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=JwxmY34s3I0BXIK1MktaYWuH15UJq1Towf0251sjd6Y=; b=dV55cbZlHFGqU1tmzN2CYx+wYaW0vrHSaN1D/QsuOmfIkV3YJO//twV+ng9oiqgunuLzNuq8mmKAcCcCC3BxDk4j688TdxLKZTJmXworammaoiJJvawalFzrOI/umH47lyHJKoqrNFPRUxUh5RRehkj7vZBO9cgjaVpJWh4409E= From: Ido Schimmel Date: Fri, 11 Jan 2019 15:53:08 +0000 Message-ID: <20190111155306.GA13197@splinter.mtl.com> References: <20190110193206.9872-1-f.fainelli@gmail.com> <20190111150637.GA897@splinter.mtl.com> <20190111154331.GE20924@lunn.ch> In-Reply-To: <20190111154331.GE20924@lunn.ch> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <56E563C58EBE924EAC7BB506CC1F23CE@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Bridge] [PATCH net-next v4] Documentation: networking: Clarify switchdev devices behavior List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Lunn Cc: Florian Fainelli , "ivan.khoronzhuk@linaro.org" , "nikolay@cumulusnetworks.com" , "netdev@vger.kernel.org" , "roopa@cumulusnetworks.com" , "bridge@lists.linux-foundation.org" , "vivien.didelot@gmail.com" , Jiri Pirko , "ilias.apalodimas@linaro.org" , "rdunlap@infradead.org" , "davem@davemloft.net" On Fri, Jan 11, 2019 at 04:43:31PM +0100, Andrew Lunn wrote: > > > +IGMP snooping > > > +~~~~~~~~~~~~~ > > > + > > > +The Linux bridge allows the configuration of IGMP snooping (compile = and run > > > +time) which must be observed by the underlying switchdev network dev= ice/hardware > > > +in the following way: > > > + > > > +- when IGMP snooping is turned off, multicast traffic must be floode= d to all > > > + switch ports within the same broadcast domain. The CPU/management = port > > > + should ideally not be flooded and continue to learn multicast traf= fic through > > > + the network stack notifications. If the hardware is not capable of= doing that > > > + then the CPU/management port must also be flooded and multicast fi= ltering > > > + happens in software. > > > + > > > +- when IGMP snooping is turned on, multicast traffic must selectivel= y flow > > > + to the appropriate network ports (including CPU/management port) a= nd not flood > > > + the switch. > > > + > > > +Note: reserved multicast addresses (e.g.: BPDUs) as well as Local Ne= twork > > > +Control block (224.0.0.0 - 224.0.0.255) do not require IGMP and shou= ld always > > > +be flooded. > >=20 > > I'm not sure that these paragraphs are actually needed. You're basicall= y > > describing RFC 4541 on which the IGMP snooping functionality in the > > Linux bridge is based on. >=20 > Hi Ido >=20 > My experience talking with people is that IGMP snooping is a bit > mystical and not well understood. I would not be surprised if > community driver writers, as opposed to vendor driver writers, don't > actually know how snooping works. So i find having some hints is good. Can we at least mention this RFC is the doc? It's very well written IMO 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:53:08 +0000 Message-ID: <20190111155306.GA13197@splinter.mtl.com> References: <20190110193206.9872-1-f.fainelli@gmail.com> <20190111150637.GA897@splinter.mtl.com> <20190111154331.GE20924@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Florian Fainelli , "netdev@vger.kernel.org" , "davem@davemloft.net" , "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: Andrew Lunn Return-path: Received: from mail-eopbgr140048.outbound.protection.outlook.com ([40.107.14.48]:29941 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730850AbfAKPxO (ORCPT ); Fri, 11 Jan 2019 10:53:14 -0500 In-Reply-To: <20190111154331.GE20924@lunn.ch> Content-Language: en-US Content-ID: <56E563C58EBE924EAC7BB506CC1F23CE@eurprd05.prod.outlook.com> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Jan 11, 2019 at 04:43:31PM +0100, Andrew Lunn wrote: > > > +IGMP snooping > > > +~~~~~~~~~~~~~ > > > + > > > +The Linux bridge allows the configuration of IGMP snooping (compile = and run > > > +time) which must be observed by the underlying switchdev network dev= ice/hardware > > > +in the following way: > > > + > > > +- when IGMP snooping is turned off, multicast traffic must be floode= d to all > > > + switch ports within the same broadcast domain. The CPU/management = port > > > + should ideally not be flooded and continue to learn multicast traf= fic through > > > + the network stack notifications. If the hardware is not capable of= doing that > > > + then the CPU/management port must also be flooded and multicast fi= ltering > > > + happens in software. > > > + > > > +- when IGMP snooping is turned on, multicast traffic must selectivel= y flow > > > + to the appropriate network ports (including CPU/management port) a= nd not flood > > > + the switch. > > > + > > > +Note: reserved multicast addresses (e.g.: BPDUs) as well as Local Ne= twork > > > +Control block (224.0.0.0 - 224.0.0.255) do not require IGMP and shou= ld always > > > +be flooded. > >=20 > > I'm not sure that these paragraphs are actually needed. You're basicall= y > > describing RFC 4541 on which the IGMP snooping functionality in the > > Linux bridge is based on. >=20 > Hi Ido >=20 > My experience talking with people is that IGMP snooping is a bit > mystical and not well understood. I would not be surprised if > community driver writers, as opposed to vendor driver writers, don't > actually know how snooping works. So i find having some hints is good. Can we at least mention this RFC is the doc? It's very well written IMO