From: Andrew Lunn <andrew@lunn.ch>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: netdev <netdev@vger.kernel.org>,
Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
Florian Fainelli <f.fainelli@gmail.com>,
jiri@mellanox.com, roopa@cumulusnetworks.com,
stephen@networkplumber.org, bridge@lists.linux-foundation.org
Subject: Re: [PATCH RFC WIP 0/5] IGMP snooping for local traffic
Date: Sun, 27 Aug 2017 01:02:30 +0200 [thread overview]
Message-ID: <20170826230230.GA13622@lunn.ch> (raw)
In-Reply-To: <c3f5050f-7a38-c28c-31d0-df5909259fb1@cumulusnetworks.com>
> Hi Andrew,
>
> Have you taken a look at mglist (the boolean, probably needs a rename) ? It is for
> exactly that purpose, to track which groups the bridge is interested in.
> I assume I'm forgetting or missing something here.
>
> > performed. With a pure software bridge, it is not required. All
> > mulitcast frames are passed to the brX interface, and the network
>
> If mglist (again the boolean) is false then they won't be passed up.
>
> > stack filters them, as it does for any interface. However, when
> > hardware offload is involved, things change. We should program the
> > hardware to only send multcast packets to the host when the host has
> > in interest in them.
>
> Granted the boolean mglist might need some changes (esp. with host group leave)
> but I think it can be used to program switchdev for host join/leave, can't
> we adjust its behaviour instead of introducing this complexity and avoid many
> headaches ?
I would like to avoid this complexity as well. I will take a look at
mglist. Thanks for the hint.
Andrew
next prev parent reply other threads:[~2017-08-26 23:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-26 20:56 [PATCH RFC WIP 0/5] IGMP snooping for local traffic Andrew Lunn
2017-08-26 20:56 ` [PATCH RFC WIP 1/5] net: rtnetlink: Handle bridge port without upper device Andrew Lunn
2017-08-26 20:56 ` [PATCH RFC WIP 2/5] net: bridge: Skip receive handler on brX interface Andrew Lunn
2017-08-26 20:56 ` [PATCH RFC WIP 3/5] net: bridge: Make the brX interface a member of the bridge Andrew Lunn
2017-08-26 20:56 ` [PATCH RFC WIP 4/5] net: dsa: HACK: Handle MDB add/remove for none-switch ports Andrew Lunn
2017-08-26 20:56 ` [PATCH RFC WIP 5/5] net: dsa: Don't include CPU port when adding MDB to a port Andrew Lunn
2017-08-26 22:17 ` [PATCH RFC WIP 0/5] IGMP snooping for local traffic Nikolay Aleksandrov
2017-08-26 22:40 ` Nikolay Aleksandrov
2017-08-26 23:02 ` Andrew Lunn [this message]
2017-08-28 2:44 ` Florian Fainelli
2017-08-28 13:45 ` Andrew Lunn
2017-08-28 15:11 ` Stephen Hemminger
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=20170826230230.GA13622@lunn.ch \
--to=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=f.fainelli@gmail.com \
--cc=jiri@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=stephen@networkplumber.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).