From: Nikolay Aleksandrov <razor@blackwall.org>
To: Joseph Huang <joseph.huang.2024@gmail.com>,
Joseph Huang <Joseph.Huang@garmin.com>,
netdev@vger.kernel.org
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"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>, Simon Horman <horms@kernel.org>,
linux-kernel@vger.kernel.org, bridge@lists.linux.dev
Subject: Re: [Patch net-next 0/3] Add support for mdb offload failure notification
Date: Fri, 21 Mar 2025 10:47:08 +0200 [thread overview]
Message-ID: <5512ee47-37ea-41b0-86b6-efdb4a2e10c4@blackwall.org> (raw)
In-Reply-To: <52b437bc-3f0e-4a5e-ae18-aea6576eb1ad@gmail.com>
On 3/20/25 23:14, Joseph Huang wrote:
> On 3/20/2025 2:17 AM, Nikolay Aleksandrov wrote:
>> On 3/19/25 00:42, Joseph Huang wrote:
>>> Currently the bridge does not provide real-time feedback to user space
>>> on whether or not an attempt to offload an mdb entry was successful.
>>>
>>> This patch set adds support to notify user space about successful and
>>> failed offload attempts, and the behavior is controlled by a new knob
>>> mdb_notify_on_flag_change:
>>>
>>> 0 - the bridge will not notify user space about MDB flag change
>>> 1 - the bridge will notify user space about flag change if either
>>> MDB_PG_FLAGS_OFFLOAD or MDB_PG_FLAGS_OFFLOAD_FAILED has changed
>>> 2 - the bridge will notify user space about flag change only if
>>> MDB_PG_FLAGS_OFFLOAD_FAILED has changed
>>>
>>> The default value is 0.
>>>
>>> A break-down of the patches in the series:
>>>
>>> Patch 1 adds offload failed flag to indicate that the offload attempt
>>> has failed. The flag is reflected in netlink mdb entry flags.
>>>
>>> Patch 2 adds the knob mdb_notify_on_flag_change, and notify user space
>>> accordingly in br_switchdev_mdb_complete() when the result is known.
>>>
>>> Patch 3 adds netlink interface to manipulate mdb_notify_on_flag_change
>>> knob.
>>>
>>> This patch set was inspired by the patch series "Add support for route
>>> offload failure notifications" discussed here:
>>> https://lore.kernel.org/all/20210207082258.3872086-1-idosch@idosch.org/
>>>
>>> Joseph Huang (3):
>>> net: bridge: mcast: Add offload failed mdb flag
>>> net: bridge: mcast: Notify on offload flag change
>>> net: bridge: Add notify on flag change netlink i/f
>>>
>>> include/uapi/linux/if_bridge.h | 9 +++++----
>>> include/uapi/linux/if_link.h | 14 ++++++++++++++
>>> net/bridge/br_mdb.c | 30 +++++++++++++++++++++++++-----
>>> net/bridge/br_multicast.c | 25 +++++++++++++++++++++++++
>>> net/bridge/br_netlink.c | 21 +++++++++++++++++++++
>>> net/bridge/br_private.h | 26 +++++++++++++++++++++-----
>>> net/bridge/br_switchdev.c | 31 ++++++++++++++++++++++++++-----
>>> 7 files changed, 137 insertions(+), 19 deletions(-)
>>>
>>
>> Hi,
>> Could you please share more about the motivation - why do you need this and
>> what will be using it?
>
> Hi Nik,
>
> The API for a user space application to join a multicast group is write-only (and really best-efforts only), meaning that after an application calls setsockopt(), the application has no way to know whether the operation actually succeeded or not. Normally for soft bridges this is not an issue; however for switchdev-backed bridges, due to limited hardware resources, the failure rate is meaningfully higher.
>
> With this patch set, the user space application will now get a notification about a failed attempt to join a multicast group. The user space application can then have the opportunity to mitigate the failure [1][2].
>
Thanks for the pointers.
>> Also why do you need an option with 3 different modes
>> instead of just an on/off switch for these notifications?
>>
>> Thanks,
>> Nik
>>
>
> Some user space application might be interested in both successful and failed offload attempts (for example the application might want to keep an mdb database which is perfectly in sync with the hardware), while some other user space application might only be interested in failed attempts (so that it can retry the operation or choose a different group for example).
>
> This knob is modeled after fib_notify_on_flag_change knob on route offload failure notification (see https://lore.kernel.org/all/20210207082258.3872086-4-idosch@idosch.org/). The rationale is that "Separate value (read: 2) is added for such notifications because there are less of them, so they do not impact performance and some users will find them more important."
>
> Thanks,
> Joseph
>
Can we please not add features that don't have actual users? It seems you're interested
in failed attempts, so you can just add a bridge boolopt on/off switch to notify about
those events, if anyone becomes interested in all then we can extend it. Also it can
have a more specific name like mdb_offload_fail_notification instead, saying that we
notify on mdb flags change is misleading because there are more flags which can change.
Also please drop all of the switchdev ifdefs and just always have this option available
it will actually be used only with switchdev enabled so setting it in other
cases is a noop, these flags will never be seen anyway.
Cheers,
Nik
prev parent reply other threads:[~2025-03-21 8:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 22:42 Joseph Huang
2025-03-18 22:42 ` [Patch net-next 1/3] net: bridge: mcast: Add offload failed mdb flag Joseph Huang
2025-03-21 8:19 ` Nikolay Aleksandrov
2025-03-26 22:38 ` Joseph Huang
2025-03-27 22:52 ` Nikolay Aleksandrov
2025-03-28 15:53 ` Joseph Huang
2025-03-31 12:51 ` Nikolay Aleksandrov
2025-03-18 22:42 ` [Patch net-next 2/3] net: bridge: mcast: Notify on offload flag change Joseph Huang
2025-03-21 8:47 ` Nikolay Aleksandrov
2025-03-31 20:11 ` Joseph Huang
2025-04-01 12:49 ` Nikolay Aleksandrov
2025-04-01 13:37 ` Nikolay Aleksandrov
2025-03-18 22:42 ` [Patch net-next 3/3] net: bridge: Add notify on flag change netlink i/f Joseph Huang
2025-03-20 6:17 ` [Patch net-next 0/3] Add support for mdb offload failure notification Nikolay Aleksandrov
2025-03-20 21:14 ` Joseph Huang
2025-03-21 8:47 ` Nikolay Aleksandrov [this message]
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=5512ee47-37ea-41b0-86b6-efdb4a2e10c4@blackwall.org \
--to=razor@blackwall.org \
--cc=Joseph.Huang@garmin.com \
--cc=andrew+netdev@lunn.ch \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=joseph.huang.2024@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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
all inboxes | Powered by JetHome®