All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Ido Schimmel <idosch@mellanox.com>
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 16:43:31 +0100	[thread overview]
Message-ID: <20190111154331.GE20924@lunn.ch> (raw)
In-Reply-To: <20190111150637.GA897@splinter.mtl.com>

> > +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.

	 Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Ido Schimmel <idosch@mellanox.com>
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 16:43:31 +0100	[thread overview]
Message-ID: <20190111154331.GE20924@lunn.ch> (raw)
In-Reply-To: <20190111150637.GA897@splinter.mtl.com>

> > +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.

	 Andrew

  reply	other threads:[~2019-01-11 15:43 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   ` Andrew Lunn [this message]
2019-01-11 15:43     ` Andrew Lunn
2019-01-11 15:53     ` [Bridge] " Ido Schimmel
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=20190111154331.GE20924@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@mellanox.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.