From: Andrew Lunn <andrew@lunn.ch>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
netdev <netdev@vger.kernel.org>,
roopa@cumulusnetworks.com, bridge@lists.linux-foundation.org,
jiri@mellanox.com
Subject: Re: [Bridge] [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
WARNING: multiple messages have this Message-ID (diff)
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: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-26 20:56 [Bridge] [PATCH RFC WIP 0/5] IGMP snooping for local traffic Andrew Lunn
2017-08-26 20:56 ` Andrew Lunn
2017-08-26 20:56 ` [Bridge] [PATCH RFC WIP 1/5] net: rtnetlink: Handle bridge port without upper device Andrew Lunn
2017-08-26 20:56 ` Andrew Lunn
2017-08-26 20:56 ` [Bridge] [PATCH RFC WIP 2/5] net: bridge: Skip receive handler on brX interface Andrew Lunn
2017-08-26 20:56 ` Andrew Lunn
2017-08-26 20:56 ` [Bridge] [PATCH RFC WIP 3/5] net: bridge: Make the brX interface a member of the bridge Andrew Lunn
2017-08-26 20:56 ` Andrew Lunn
2017-08-26 20:56 ` [Bridge] [PATCH RFC WIP 4/5] net: dsa: HACK: Handle MDB add/remove for none-switch ports Andrew Lunn
2017-08-26 20:56 ` Andrew Lunn
2017-08-26 20:56 ` [Bridge] [PATCH RFC WIP 5/5] net: dsa: Don't include CPU port when adding MDB to a port Andrew Lunn
2017-08-26 20:56 ` Andrew Lunn
2017-08-26 22:17 ` [Bridge] [PATCH RFC WIP 0/5] IGMP snooping for local traffic Nikolay Aleksandrov
2017-08-26 22:17 ` Nikolay Aleksandrov
2017-08-26 22:40 ` [Bridge] " Nikolay Aleksandrov
2017-08-26 22:40 ` Nikolay Aleksandrov
2017-08-26 23:02 ` Andrew Lunn [this message]
2017-08-26 23:02 ` Andrew Lunn
2017-08-28 2:44 ` [Bridge] " Florian Fainelli
2017-08-28 2:44 ` Florian Fainelli
2017-08-28 13:45 ` [Bridge] " Andrew Lunn
2017-08-28 13:45 ` Andrew Lunn
2017-08-28 15:11 ` [Bridge] " Stephen Hemminger
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=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 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.