netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@mellanox.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	David Miller <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	jiri@mellanox.com
Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic
Date: Thu, 9 Nov 2017 23:40:18 +0200	[thread overview]
Message-ID: <20171109214018.GA18330@splinter> (raw)
In-Reply-To: <20171109211315.GA22805@lunn.ch>

On Thu, Nov 09, 2017 at 10:13:15PM +0100, Andrew Lunn wrote:
> On Thu, Nov 09, 2017 at 12:35:32PM -0800, Florian Fainelli wrote:
> > +Ido, Jiri,
> > 
> > On 11/09/2017 12:21 PM, Andrew Lunn wrote:
> > > On Thu, Nov 09, 2017 at 11:38:26AM -0800, Florian Fainelli wrote:
> > >> On 11/09/2017 11:30 AM, Andrew Lunn wrote:
> > >>>> This means that switchdev drivers won't ever have to treat a HOST_MDB
> > >>>> notification any differently than a PORT_MDB notification
> > >>>
> > >>> No, they need to treat it very differently. 
> > >>
> > >> Allow me to rephrase, switchdev drivers will ignore HOST_MDB
> > >> notifications because that does not resolve to something they can do
> > >> something about.
> > > 
> > > Hi Florian
> > > 
> > > Yes, they can. In fact, if they want to support IGMP snooping on the
> > > bridge interface, they have to. How else do they know to forward
> > > traffic to the host?
> > 
> > On a switchdev fabric, you need to have at least one user-facing port be
> > a member of the bridge, and when the switchdev driver configures that,
> > it should just make the IGMP packets trap to the management interface
> > such that they can be delivered from the port member to the bridge
> > network device (br0). In that case, I don't really see why you would
> > need to send a HOST_MDB message to a switchdev fabric, since that should
> > be part of enslaving the port to the bridge in the first place and
> > appropriately configure the management interface to get IGMP snooping,
> > BDPU etc.
> 
> So your network is carrying gigabits of multicast traffic. Are you
> saying it should all hit the host, so the bridge can throw it away?
> No, it is much more efficient that the bridge tells the switch when it
> is interested in a specific multicast group. I.e. it sends a HOST_MDB
> request for the group. Only then will the switch start to send the
> data for that group to the host.

Yep. We already have support for marking br0 as router port which means
the bridge driver will get both unregistered multicast packets and
packets hitting mdb entries. With your patch, we'll need to add the
ability to get only packets hitting a specific mdb entry which should be
trivial enough.

Florian, you're right that by default IGMP (control) packets are trapped
to the bridge driver, but Andrew's set adds the ability to trap the
_data_ packets hitting a specific mdb entry.

  reply	other threads:[~2017-11-09 21:40 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06 23:26 [PATCH v3 net-next 0/5] IGMP snooping for local traffic Andrew Lunn
2017-11-06 23:26 ` [PATCH v3 net-next 1/5] net: bridge: Rename mglist to host_joined Andrew Lunn
2017-11-08  1:31   ` Nikolay Aleksandrov
2017-11-08  1:40   ` Florian Fainelli
2017-11-06 23:26 ` [PATCH v3 net-next 2/5] net: bridge: Send notification when host join/leaves a group Andrew Lunn
2017-11-08  1:39   ` Nikolay Aleksandrov
2017-11-08  1:41   ` Florian Fainelli
2017-11-06 23:26 ` [PATCH v3 net-next 3/5] net: bridge: Add/del switchdev object on host join/leave Andrew Lunn
2017-11-08  1:48   ` Nikolay Aleksandrov
2017-11-06 23:26 ` [PATCH v3 net-next 4/5] net: dsa: slave: Handle switchdev host mdb add/del Andrew Lunn
2017-11-06 23:26 ` [PATCH v3 net-next 5/5] net: dsa: switch: Don't add CPU port to an mdb by default Andrew Lunn
2017-11-07 10:12   ` Sergei Shtylyov
2017-11-07  1:01 ` [PATCH v3 net-next 0/5] IGMP snooping for local traffic Stephen Hemminger
2017-11-07 17:03 ` Vivien Didelot
2017-11-07 17:42   ` Andrew Lunn
2017-11-07 18:10     ` Florian Fainelli
2017-11-07 18:16     ` Vivien Didelot
2017-11-07 21:01       ` Andrew Lunn
2017-11-07 21:18         ` Florian Fainelli
2017-11-07 22:17           ` Andrew Lunn
2017-11-07 22:37             ` Vivien Didelot
2017-11-07 23:17               ` Andrew Lunn
2017-11-08  0:41                 ` Florian Fainelli
2017-11-09 18:41                   ` Florian Fainelli
2017-11-09 19:30                     ` Andrew Lunn
2017-11-09 19:38                       ` Florian Fainelli
2017-11-09 20:21                         ` Andrew Lunn
2017-11-09 20:35                           ` Florian Fainelli
2017-11-09 21:13                             ` Andrew Lunn
2017-11-09 21:40                               ` Ido Schimmel [this message]
2017-11-07 17:34 ` Egil Hjelmeland
2017-11-07 17:58   ` Andrew Lunn
2017-11-08 15:11     ` Egil Hjelmeland
2017-11-08 15:21       ` Andrew Lunn
2017-11-08 15:53       ` Vivien Didelot
2017-11-09  2:30 ` David Miller
2017-11-09  2:47   ` David Miller
2017-11-09 14:44     ` Vivien Didelot

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=20171109214018.GA18330@splinter \
    --to=idosch@mellanox.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).