From: Vladimir Oltean <olteanv@gmail•com>
To: Nikolay Aleksandrov <razor@blackwall•org>
Cc: "Joseph Huang" <Joseph.Huang@garmin•com>,
netdev@vger•kernel.org, "Andrew Lunn" <andrew@lunn•ch>,
"Florian Fainelli" <f.fainelli@gmail•com>,
"David S. Miller" <davem@davemloft•net>,
"Eric Dumazet" <edumazet@google•com>,
"Jakub Kicinski" <kuba@kernel•org>,
"Paolo Abeni" <pabeni@redhat•com>,
"Roopa Prabhu" <roopa@nvidia•com>,
"Linus Lüssing" <linus.luessing@c0d3•blue>,
linux-kernel@vger•kernel.org, bridge@lists•linux.dev
Subject: Re: [PATCH RFC net-next 00/10] MC Flood disable and snooping
Date: Tue, 2 Apr 2024 20:43:48 +0300 [thread overview]
Message-ID: <20240402174348.wosc37adyub5o7xu@skbuf> (raw)
In-Reply-To: <7fc8264a-a383-4682-a144-8d91fe3971d9@blackwall.org>
Hi Nikolai,
On Tue, Apr 02, 2024 at 12:28:38PM +0300, Nikolay Aleksandrov wrote:
> For the bridge patches:
> Nacked-by: Nikolay Aleksandrov <razor@blackwall•org>
>
> You cannot break the multicast flood flag to add support for a custom
> use-case. This is unacceptable. The current bridge behaviour is correct
> your patch 02 doesn't fix anything, you should configure the bridge
> properly to avoid all those problems, not break protocols.
>
> Your special use case can easily be solved by a user-space helper or
> eBPF and nftables. You can set the mcast flood flag and bypass the
> bridge for these packets. I basically said the same in 2021, if this is
> going to be in the bridge it should be hidden behind an option that is
> default off. But in my opinion adding an option to solve such special
> cases is undesirable, they can be easily solved with what's currently
> available.
I appreciate your time is limited, but could you please translate your
suggestion, and detail your proposed alternative a bit, for those of us
who are not very familiar with IP multicast snooping?
Bypass the bridge for which packets? General IGMP/MLD queries? Wouldn't
that break snooping? And then do what with the packets, forward them in
another software layer than the bridge?
I also don't quite understand the suggestion of turning on mcast flooding:
isn't Joseph saying that he wants it off for the unregistered multicast
data traffic?
next prev parent reply other threads:[~2024-04-02 17:43 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 0:10 [PATCH RFC net-next 00/10] MC Flood disable and snooping Joseph Huang
2024-04-02 0:11 ` [PATCH RFC net-next 01/10] net: bridge: Flood Queries even when mc flood is disabled Joseph Huang
2024-04-02 0:11 ` [PATCH RFC net-next 02/10] net: bridge: Always multicast_flood Reports Joseph Huang
2024-04-03 15:52 ` Simon Horman
2024-04-02 0:11 ` [PATCH RFC net-next 03/10] net: bridge: Always flood local subnet mc packets Joseph Huang
2024-04-02 0:11 ` [PATCH RFC net-next 04/10] net: dsa: mv88e6xxx: Add all hosts mc addr to ATU Joseph Huang
2024-04-02 18:08 ` Vladimir Oltean
2024-04-02 0:11 ` [PATCH RFC net-next 05/10] net: dsa: Add support for PORT_MROUTER attribute Joseph Huang
2024-04-02 0:11 ` [PATCH RFC net-next 06/10] net: dsa: mv88e6xxx: Track soft bridge objects Joseph Huang
2024-04-02 0:11 ` [PATCH RFC net-next 07/10] net: dsa: mv88e6xxx: Track bridge mdb objects Joseph Huang
2024-04-02 12:23 ` Vladimir Oltean
2024-04-04 20:43 ` Joseph Huang
2024-04-05 11:07 ` Vladimir Oltean
2024-04-05 18:58 ` Joseph Huang
2024-04-29 22:07 ` Joseph Huang
2024-04-30 0:59 ` Vladimir Oltean
2024-04-30 16:27 ` Joseph Huang
2024-05-02 20:37 ` Joseph Huang
2024-04-02 0:11 ` [PATCH RFC net-next 08/10] net: dsa: mv88e6xxx: Convert MAB to use bit flags Joseph Huang
2024-04-02 0:11 ` [PATCH RFC net-next 09/10] net: dsa: mv88e6xxx: Enable mc flood for mrouter port Joseph Huang
2024-04-03 15:49 ` Simon Horman
2024-04-02 0:11 ` [PATCH RFC net-next 10/10] net: dsa: mv88e6xxx: Offload " Joseph Huang
2024-04-02 9:28 ` [PATCH RFC net-next 00/10] MC Flood disable and snooping Nikolay Aleksandrov
2024-04-02 17:43 ` Vladimir Oltean [this message]
2024-04-02 18:50 ` Nikolay Aleksandrov
2024-04-02 20:46 ` Vladimir Oltean
2024-04-02 21:59 ` Nikolay Aleksandrov
2024-04-04 22:16 ` Joseph Huang
2024-04-05 10:20 ` Vladimir Oltean
2024-04-05 11:00 ` Nikolay Aleksandrov
2024-04-05 20:22 ` Joseph Huang
2024-04-05 21:15 ` Vladimir Oltean
2024-04-29 20:14 ` Joseph Huang
2024-04-30 1:21 ` Vladimir Oltean
2024-04-30 17:01 ` Joseph Huang
2024-05-02 12:12 ` Nikolay Aleksandrov
2025-02-26 20:20 ` Linus Lüssing
2025-02-26 22:17 ` Linus Lüssing
2024-04-02 12:43 ` Andrew Lunn
2024-04-04 21:35 ` Joseph Huang
2024-04-04 22:11 ` Andrew Lunn
2024-04-04 22:40 ` Joseph Huang
2024-04-05 13:09 ` Andrew Lunn
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=20240402174348.wosc37adyub5o7xu@skbuf \
--to=olteanv@gmail$(echo .)com \
--cc=Joseph.Huang@garmin$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=bridge@lists$(echo .)linux.dev \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=f.fainelli@gmail$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=linus.luessing@c0d3$(echo .)blue \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=razor@blackwall$(echo .)org \
--cc=roopa@nvidia$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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