include/uapi/linux/if_bridge.h | 10 ++++++---- net/bridge/br.c | 5 +++++ net/bridge/br_mdb.c | 28 +++++++++++++++++++++++----- net/bridge/br_private.h | 30 +++++++++++++++++++++++++----- net/bridge/br_switchdev.c | 13 +++++++++---- 5 files changed, 68 insertions(+), 18 deletions(-)
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 failed offload
attempts, and is controlled by a new knob mdb_offload_fail_notification.
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 new bridge bool option mdb_offload_fail_notification.
Patch 3 notifies user space when the result is known, controlled by
mdb_offload_fail_notification setting.
Joseph Huang (3):
net: bridge: mcast: Add offload failed mdb flag
net: bridge: Add offload_fail_notification bopt
net: bridge: mcast: Notify on mdb offload failure
include/uapi/linux/if_bridge.h | 10 ++++++----
net/bridge/br.c | 5 +++++
net/bridge/br_mdb.c | 28 +++++++++++++++++++++++-----
net/bridge/br_private.h | 30 +++++++++++++++++++++++++-----
net/bridge/br_switchdev.c | 13 +++++++++----
5 files changed, 68 insertions(+), 18 deletions(-)
---
v1: https://lore.kernel.org/netdev/20250318224255.143683-1-Joseph.Huang@garmin.com/
iproute2 link:
https://lore.kernel.org/netdev/20250318225026.145501-1-Joseph.Huang@garmin.com/
v2: https://lore.kernel.org/netdev/20250403234412.1531714-1-Joseph.Huang@garmin.com/
iproute2 link:
https://lore.kernel.org/netdev/20250403235452.1534269-1-Joseph.Huang@garmin.com/
Add br_multicast_pg_set_offload_flags helper to set offload flags
Change multi-valued option mdb_notify_on_flag_change to bool option
mdb_offload_fail_notification
Change _br_mdb_notify to __br_mdb_notify
Drop all #ifdef CONFIG_NET_SWITCHDEV
Add br_mdb_should_notify helper and reorganize code in
br_switch_mdb_complete
v3: Patch 1/3 Do not set offload flags when switchdev returns -EOPNOTSUPP
--
2.49.0
On Fri, 4 Apr 2025 17:29:32 -0400 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 failed offload > attempts, and is controlled by a new knob mdb_offload_fail_notification. > > 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 new bridge bool option mdb_offload_fail_notification. > > Patch 3 notifies user space when the result is known, controlled by > mdb_offload_fail_notification setting. You submitted this during the merge window, when the net-next tree was closed. See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle Could you repost so that the series will be re-enqueued? Thanks! -- pw-bot: defer
On 4/7/2025 1:29 PM, Jakub Kicinski wrote: > On Fri, 4 Apr 2025 17:29:32 -0400 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 failed offload >> attempts, and is controlled by a new knob mdb_offload_fail_notification. >> >> 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 new bridge bool option mdb_offload_fail_notification. >> >> Patch 3 notifies user space when the result is known, controlled by >> mdb_offload_fail_notification setting. > > You submitted this during the merge window, when the net-next tree > was closed. See: > https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle > Could you repost so that the series will be re-enqueued? > > Thanks! Sure thing! A couple of questions: - Should the re-post be v3 (no change) or v4 (bump)? - Do I re-post after 6.15 is released? Around what time frame (so that I can set a reminder)? Thanks, Joseph
On Mon, 7 Apr 2025 14:15:31 -0400 Joseph Huang wrote: > - Should the re-post be v3 (no change) or v4 (bump)? Doesn't matter much, but probably v4 is less confusing. > - Do I re-post after 6.15 is released? Around what time frame (so that I > can set a reminder)? No, no, I mean very soon. Like tomorrow. The merge window is when maintainers merge their tress up, rather than when we merge code from contributors. It's a bit confusing. Merge window open == normal contribution closed, and vice versa.
On 4/7/2025 2:37 PM, Jakub Kicinski wrote: > On Mon, 7 Apr 2025 14:15:31 -0400 Joseph Huang wrote: >> - Should the re-post be v3 (no change) or v4 (bump)? > > Doesn't matter much, but probably v4 is less confusing. > >> - Do I re-post after 6.15 is released? Around what time frame (so that I >> can set a reminder)? > > No, no, I mean very soon. Like tomorrow. The merge window is when > maintainers merge their tress up, rather than when we merge code > from contributors. It's a bit confusing. Merge window open == > normal contribution closed, and vice versa. Got it. Thanks for the clarification. Will re-post tomorrow. Thanks, Joseph
© 2016 - 2026 Red Hat, Inc.