From: Vladimir Oltean <olteanv@gmail.com>
To: Joseph Huang <joseph.huang.2024@gmail.com>
Cc: "Nikolay Aleksandrov" <razor@blackwall.org>,
"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, 30 Apr 2024 04:21:59 +0300 [thread overview]
Message-ID: <20240430012159.rmllu5s5gcdepjnc@skbuf> (raw)
In-Reply-To: <1f385946-84d0-499c-9bf6-90ef65918356@gmail.com>
On Mon, Apr 29, 2024 at 04:14:03PM -0400, Joseph Huang wrote:
> How about the following syntax? I think it satisfies all the "not breaking
> existing behavior" requirements (new option defaults to off, and missing
> user space netlink attributes does not change the existing behavior):
>
> mcast_flood off
> all off
> mcast_flood off mcast_flood_rfc4541 off
> all off
> mcast_flood off mcast_flood_rfc4541 on
> 224.0.0.X and ff02::1 on, the rest off
> mcast_flood on
> all on
> mcast_flood on mcast_flood_rfc4541 off
> all on (mcast_flood on overrides mcast_flood_rfc4541)
> mcast_flood on mcast_flood_rfc4541 on
> all on
> mcast_flood_rfc4541 off
> invalid (mcast_flood_rfc4541 is only valid if mcast_flood [on | off] is
> specified first)
> mcast_flood_rfc4541 on
> invalid (mcast_flood_rfc4541 is only valid if mcast_flood [on | off] is
> specified first)
A bridge port defaults to having BR_MCAST_FLOOD set - see new_nbp().
Netlink attributes are only there to _change_ the state of properties in
the kernel. They don't need to be specified by user space if there's
nothing to be changed. "Only valid if another netlink attribute comes
first" makes no sense. You can alter 2 bridge port flags as part of the
same netlink message, or as part of different netlink messages (sent
over sockets of other processes).
>
> Think of mcast_flood_rfc4541 like a pet door if you will.
Ultimately, as far as I see it, both the OR-based and the AND-based UAPI
addition could be made to work in a way that's perhaps similarly backwards
compatible. It needs to be worked out with the bridge maintainers. Given
that I'm not doing great with my spare time, I will take a back seat on
that.
However, what I don't quite understand in your proposal is how many IPv4
addresses lie beyond the "224.0.0.X" notation? 256? Explain why there is
such a large discrepancy in the number of IPv4 addresses you are in
control of (256), vs only 1 IPv6 address with the new rfc4541 flag?
next prev parent reply other threads:[~2024-04-30 1:22 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
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 [this message]
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=20240430012159.rmllu5s5gcdepjnc@skbuf \
--to=olteanv@gmail.com \
--cc=Joseph.Huang@garmin.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=joseph.huang.2024@gmail.com \
--cc=kuba@kernel.org \
--cc=linus.luessing@c0d3.blue \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.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