All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@mellanox.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	"ivan.khoronzhuk@linaro.org" <ivan.khoronzhuk@linaro.org>,
	"nikolay@cumulusnetworks.com" <nikolay@cumulusnetworks.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"roopa@cumulusnetworks.com" <roopa@cumulusnetworks.com>,
	"bridge@lists.linux-foundation.org"
	<bridge@lists.linux-foundation.org>,
	"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
	Jiri Pirko <jiri@mellanox.com>,
	"ilias.apalodimas@linaro.org" <ilias.apalodimas@linaro.org>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH net-next v4] Documentation: networking: Clarify switchdev devices behavior
Date: Fri, 11 Jan 2019 15:53:08 +0000	[thread overview]
Message-ID: <20190111155306.GA13197@splinter.mtl.com> (raw)
In-Reply-To: <20190111154331.GE20924@lunn.ch>

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 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 doing that
> > > +  then the CPU/management port must also be flooded and multicast filtering
> > > +  happens in software.
> > > +
> > > +- when IGMP snooping is turned on, multicast traffic must selectively flow
> > > +  to the appropriate network ports (including CPU/management port) and not flood
> > > +  the switch.
> > > +
> > > +Note: reserved multicast addresses (e.g.: BPDUs) as well as Local Network
> > > +Control block (224.0.0.0 - 224.0.0.255) do not require IGMP and should always
> > > +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.
> 
> Hi Ido
> 
> 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

WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@mellanox.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
	"cphealy@gmail.com" <cphealy@gmail.com>,
	Jiri Pirko <jiri@mellanox.com>,
	"bridge@lists.linux-foundation.org"
	<bridge@lists.linux-foundation.org>,
	"nikolay@cumulusnetworks.com" <nikolay@cumulusnetworks.com>,
	"roopa@cumulusnetworks.com" <roopa@cumulusnetworks.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"ilias.apalodimas@linaro.org" <ilias.apalodimas@linaro.org>,
	"ivan.khoronzhuk@linaro.org" <ivan.khoronzhuk@linaro.org>
Subject: Re: [PATCH net-next v4] Documentation: networking: Clarify switchdev devices behavior
Date: Fri, 11 Jan 2019 15:53:08 +0000	[thread overview]
Message-ID: <20190111155306.GA13197@splinter.mtl.com> (raw)
In-Reply-To: <20190111154331.GE20924@lunn.ch>

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 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 doing that
> > > +  then the CPU/management port must also be flooded and multicast filtering
> > > +  happens in software.
> > > +
> > > +- when IGMP snooping is turned on, multicast traffic must selectively flow
> > > +  to the appropriate network ports (including CPU/management port) and not flood
> > > +  the switch.
> > > +
> > > +Note: reserved multicast addresses (e.g.: BPDUs) as well as Local Network
> > > +Control block (224.0.0.0 - 224.0.0.255) do not require IGMP and should always
> > > +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.
> 
> Hi Ido
> 
> 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

  reply	other threads:[~2019-01-11 15:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10 19:32 [Bridge] [PATCH net-next v4] Documentation: networking: Clarify switchdev devices behavior Florian Fainelli
2019-01-10 19:32 ` Florian Fainelli
2019-01-10 21:50 ` [Bridge] " Randy Dunlap
2019-01-10 21:50   ` Randy Dunlap
2019-01-10 21:50   ` Randy Dunlap
2019-01-11 15:06 ` [Bridge] " Ido Schimmel
2019-01-11 15:06   ` Ido Schimmel
2019-01-11 15:43   ` [Bridge] " Andrew Lunn
2019-01-11 15:43     ` Andrew Lunn
2019-01-11 15:53     ` Ido Schimmel [this message]
2019-01-11 15:53       ` Ido Schimmel
2019-01-11 18:34   ` [Bridge] " Florian Fainelli
2019-01-11 18:34     ` Florian Fainelli
2019-01-11 19:20     ` [Bridge] " Ido Schimmel
2019-01-11 19:20       ` Ido Schimmel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190111155306.GA13197@splinter.mtl.com \
    --to=idosch@mellanox.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=ivan.khoronzhuk@linaro.org \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=rdunlap@infradead.org \
    --cc=roopa@cumulusnetworks.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.