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 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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 15F66C43387 for ; Fri, 11 Jan 2019 15:53:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D0987206B7 for ; Fri, 11 Jan 2019 15:53:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="dV55cbZl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732813AbfAKPxO (ORCPT ); Fri, 11 Jan 2019 10:53:14 -0500 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 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= Received: from AM6PR05MB6056.eurprd05.prod.outlook.com (20.179.2.148) by AM6PR05MB5319.eurprd05.prod.outlook.com (20.177.198.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.13; Fri, 11 Jan 2019 15:53:09 +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:53:09 +0000 From: Ido Schimmel To: Andrew Lunn 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" 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/KCYD0GTS2XYRQrioqWqLEiAgAAKT4CAAAKuAA== 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> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM6PR0402CA0032.eurprd04.prod.outlook.com (2603:10a6:209::45) 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;AM6PR05MB5319;6:cFzrLQtA1dV0nY/5rSJBepOep5d3cIkjT4/myuw8Fflr0UaHsoieRDpNzQufpm2DAnWVFTgof9cqI3I3+c0rg0dg+odeWWnx5yRC5CgRh534SdcV+MK8b38EQMfDe/VX2LtPOUkJ52qzIUZ5OKUcgeQoFgi5pWfulX+pO4/tdhX3RhWeZzcIeoH5GKe/mwzvCiFKPYfaBonY4vTvRek3/2JdL5JcLX2NbdLdwF/5XToVdEVz0H/DVomu4KcbED670brshUe3NDlCAduZsThIQfbk0z1dtsqGFfZaqIs/rB1jzvDyme0npRlYPlSBLqr0OnQqpK57Jm4i4lJnMDcecWHEPmtSce5yd0Wmo9/Qra0538zZTW3M/xYHdTV27nEP1mOUmVke39fq0vvjGBmlLRyil1bj09Lh1LlZ2DXMdPmVTbHJp5QC3ASRS5KXX0vO3LgotjQHrpYbLlYyqSqmAQ==;5:V6imKUNv0k/JfatvuLjCOB0n+DoRbIp70gMrm6OHvF3BHn93GU9s8K8mM2ezktTyFigJsNtHvHXp/+91Tu7TFBzYaSC928mYhL6n+0uYQSq5QBfmDZbGJZSDD3OoxivymQIY3pgXoARW+5HllaDdf9qbh7e16k+fg1rWpfPuVmRAtKgYi+CgZCXMReYJOKPjbKXYJiJBClI878VrCwW/SQ==;7:0ms/48T6f2rel9Fk6gqZWaS6DT/t9I5BCUq/z7sNz0PyqjCzKFVYrrUWeF3Qa2Yume/1H4ZEr2c1kPj1D9sYw3cVG3OwJN2qNezTBCGNAnfeifboNLgxXOK565n4gJCqFMBds6Wtc88Sm+12oEmgsw== x-ms-office365-filtering-correlation-id: f2dc7d1d-35db-4840-f70c-08d677dce1de 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:AM6PR05MB5319; x-ms-traffictypediagnostic: AM6PR05MB5319: x-microsoft-antispam-prvs: x-forefront-prvs: 09144DB0F7 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(136003)(396003)(366004)(376002)(346002)(39860400002)(189003)(199004)(86362001)(9686003)(6512007)(106356001)(7736002)(68736007)(8676002)(7416002)(99286004)(229853002)(5660300001)(2906002)(446003)(39060400002)(11346002)(3846002)(53936002)(6246003)(6116002)(14454004)(105586002)(25786009)(6436002)(4326008)(1076003)(102836004)(76176011)(52116002)(476003)(486006)(186003)(97736004)(6916009)(6486002)(316002)(66066001)(8936002)(81156014)(33896004)(478600001)(26005)(33656002)(71200400001)(71190400001)(81166006)(6506007)(256004)(386003)(305945005)(54906003);DIR:OUT;SFP:1101;SCL:1;SRVR:AM6PR05MB5319;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: oL6ykcuR9eQ5fo47i3u5wzHrmj7wsMsZ01PI8+7MtJCawQLZU959V8JZA0E+d4ZNSRswNJVPUZrzc6d+bpmTB08nodNY2eXs0TJVm8vjUjTCSDc90XRsxif2nATJOWfwsDoBbrOPdeL77+xdzIm7MQsZOJ6z0UFoCtsfBO1SkBhxW98ZsXJSNHnOZBd3THWn217TCOy18dbrH8/qHJUktKkTXKo4XhXbTM1gLyA1svZMMtmHRMT87/PRQedREoQEnMMsuEA52cCBydmqOS6BnTJpmCFWe0+dQNs2Gh1RBfg6Bv0y0XUa/h89ROFVrlDq8/DjcYJbrCi0NRgE39zeSOAcUchOcSgoaMJxJrj+sankCmUTkuBVxHjYUTuboUnki94RfYREsEO6OyDSpz2kgqlRQd1+AmdYP0GKzcrik+Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <56E563C58EBE924EAC7BB506CC1F23CE@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2dc7d1d-35db-4840-f70c-08d677dce1de X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 15:53:08.3118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB5319 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Message-ID: <20190111155308.wDbO1YGr4uQ3lIuC3oXpE0jXhJgmlyqFX2Jeg3TI_uc@z> 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