Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
Hi Nikolay, > For the MDB to have a dynamic reservation entry means someone must've added > it, > these are not dynamically learned, so you can just as well build the table > in a more appropriate place which can tag or filter the packet. Fair enough, also a reasonable argument :) Without 802.1Q Dynamic Reservation Entries having first-class support in the MDB, I don’t think there’s an abstraction that also maps well to the mv88e6xxx. I’ll keep thinking about it, but for now this had probably best remain a local patch. [1] Thanks for taking the time to give feedback, I learned a lot. Cheers, Luke [1] https://github.com/PADL/linux/tree/b4/mv88e6xxx-8021qat-mqprio
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
On Sun, Jun 07, 2026 at 07:49:26AM +1000, Luke Howard wrote: > > > > On 6 Jun 2026, at 6:21 pm, Nikolay Aleksandrov wrote: > > > > On 06/06/2026 11:02, Luke Howard wrote: > >> The definition of Dynamic Reservation Entries in 802.1Q (clause 8.8.7) > >> might support the addition of a new MDB (or even FDB) entry state to the > >> kernel: > >> - add MDB_DYNAMIC_RESERVATION (a state, not a flag); > >> - the software bridge only _classifies_ packets against > >> MDB_DYNAMIC_RESERVATION entries, and only when MDB is authoritative. > >> Classification sets dynamic_reservation_hit on tc_skb_ext; > >> - dynamic_reservation_hit is visible to the flow dissector so can be used > >> for policy enforcement. > > > > See, saying the bridge has to classify doesn't sound right. Why not do the > > classification where such operations are usually done, e.g. tc? > > You have to manually designate these entries anyway. > > s/classify/mark, i.e. marking a forwarding bit for tc to match, a la l2_miss. > > tc can’t see into the MDB to tell if a DA has a dynamic reservation entry so, > without an explicit DRE bit, the SRP daemon would need to maintain a flower > permit filter per DRE. Not needing this allows the user to set a single > policy filter prior to starting SRP, e.g.: > > tc filter add dev lan0 egress protocol 802.1Q pref 1 handle 1 flower > vlan_prio 3 dynamic_reservation_hit 0 action drop > > It also maps cleanly to chips that support 802.1Qav with priority > regeneration or filtering, but which can’t support tc-flower. Yeah, that was an expected answer and I've seen such claims multiple times. Just because it is convenient to add it in the bridge, does not make it the right software model. There are layers that do filtering, marking and manipulation this must be done at such layer. If you have to create a new table with the entries filled there then that is what your user-space software must do, or come up with a better alternative. There're also bridge netfilter chains that can do packet filtering and manipulation, that might be an option. For the MDB to have a dynamic reservation entry means someone must've added it, these are not dynamically learned, so you can just as well build the table in a more appropriate place which can tag or filter the packet.
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
> On 6 Jun 2026, at 6:21 pm, Nikolay Aleksandrov wrote: > > On 06/06/2026 11:02, Luke Howard wrote: >> The definition of Dynamic Reservation Entries in 802.1Q (clause 8.8.7) might >> support the addition of a new MDB (or even FDB) entry state to the kernel: >> - add MDB_DYNAMIC_RESERVATION (a state, not a flag); >> - the software bridge only _classifies_ packets against >> MDB_DYNAMIC_RESERVATION entries, and only when MDB is authoritative. >> Classification sets dynamic_reservation_hit on tc_skb_ext; >> - dynamic_reservation_hit is visible to the flow dissector so can be used >> for policy enforcement. > > See, saying the bridge has to classify doesn't sound right. Why not do the > classification where such operations are usually done, e.g. tc? > You have to manually designate these entries anyway. s/classify/mark, i.e. marking a forwarding bit for tc to match, a la l2_miss. tc can’t see into the MDB to tell if a DA has a dynamic reservation entry so, without an explicit DRE bit, the SRP daemon would need to maintain a flower permit filter per DRE. Not needing this allows the user to set a single policy filter prior to starting SRP, e.g.: tc filter add dev lan0 egress protocol 802.1Q pref 1 handle 1 flower vlan_prio 3 dynamic_reservation_hit 0 action drop It also maps cleanly to chips that support 802.1Qav with priority regeneration or filtering, but which can’t support tc-flower.
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
On 06/06/2026 11:02, Luke Howard wrote: So it sounds like you first need to work on the software implementation and expand the simplified version with the features you need. You can then add support to accelerate this by offloading it to the hardware. Agreed. The definition of Dynamic Reservation Entries in 802.1Q (clause 8.8.7) might support the addition of a new MDB (or even FDB) entry state to the kernel: - add MDB_DYNAMIC_RESERVATION (a state, not a flag); - the software bridge only _classifies_ packets against MDB_DYNAMIC_RESERVATION entries, and only when MDB is authoritative. Classification sets dynamic_reservation_hit on tc_skb_ext; - dynamic_reservation_hit is visible to the flow dissector so can be used for policy enforcement. See, saying the bridge has to classify doesn't sound right. Why not do the classification where such operations are usually done, e.g. tc? You have to manually designate these entries anyway. Advantages: - the new MDB state maps well to 802.1Q; - minimal changes to bridge; - actual policy (reclassify, drop, etc) is left to the user; - doesn’t require a new tc-flower entry for each stream DA; - entry state maps 1:1 to mv88e6xxx AVB_NRL ATU EntryState. Disadvantages: - no unicast support, although potentially can be extended (there are some subtleties); - mv88e6xxx support would either require rich enough tc-flower support in TCAM, intercepting TCA_FLOWER_DYNAMIC_RESERVATION_HIT and mapping to native AVB admission control, or a per-port devlink parameter (not so nice). This is implemented and working with the software bridge, I still haven’t quite figured out the right mapping for mv88e6xxx. Luke PS. I previously incorrectly asserted that 802.1Q required dropping frames with AVB/SRP PCPs but without valid dynamic reservation entries. 802.1Q discussions priority mapping in clause 6.9.4 for traffic from SRP boundary ports (those not participating in SRP). In practice I think this should all be policy, e.g. you might want to reprioritise valid DSCP traffic from within a SRP domain, or drop instead of reprioritise, etc.
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
> So it sounds like you first need to work on the software > implementation and expand the simplified version with the features you > need. You can then add support to accelerate this by offloading it to > the hardware. Agreed. The definition of Dynamic Reservation Entries in 802.1Q (clause 8.8.7) might support the addition of a new MDB (or even FDB) entry state to the kernel: - add MDB_DYNAMIC_RESERVATION (a state, not a flag); - the software bridge only _classifies_ packets against MDB_DYNAMIC_RESERVATION entries, and only when MDB is authoritative. Classification sets dynamic_reservation_hit on tc_skb_ext; - dynamic_reservation_hit is visible to the flow dissector so can be used for policy enforcement. Advantages: - the new MDB state maps well to 802.1Q; - minimal changes to bridge; - actual policy (reclassify, drop, etc) is left to the user; - doesn’t require a new tc-flower entry for each stream DA; - entry state maps 1:1 to mv88e6xxx AVB_NRL ATU EntryState. Disadvantages: - no unicast support, although potentially can be extended (there are some subtleties); - mv88e6xxx support would either require rich enough tc-flower support in TCAM, intercepting TCA_FLOWER_DYNAMIC_RESERVATION_HIT and mapping to native AVB admission control, or a per-port devlink parameter (not so nice). This is implemented and working with the software bridge, I still haven’t quite figured out the right mapping for mv88e6xxx. Luke PS. I previously incorrectly asserted that 802.1Q required dropping frames with AVB/SRP PCPs but without valid dynamic reservation entries. 802.1Q discussions priority mapping in clause 6.9.4 for traffic from SRP boundary ports (those not participating in SRP). In practice I think this should all be policy, e.g. you might want to reprioritise valid DSCP traffic from within a SRP domain, or drop instead of reprioritise, etc.
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
> But the concept comes from the 802.1Q spec. The spec describes different types > of FDB entries. One of these is Dynamic Reservation Entries, which are created > from the Stream Reservation Protocol. > The issue here is the Marvell switch has an implementation where we need to > know if an entry is a Dynamic Reservation Entry. But the linux bridge has a > simplified version of the FDB described in 802.1Q. > By adding a way to distinguish between the type of FDB entries, it's possible > to program a Marvell which has this distinction between Dynamic Reservation > Entries (or AVB entries) and other entries. If we only care about the multicast case, and we can depend on snooping being enabled and flooding disabled, then I think Dynamic Reservation Entries collapse to permanent MDB entries. Unicast is trickier. The issue of reclassifying (or dropping) frames that share a SRP class PCP is separate. I think it could be done with a tc-flower entry that reclassifies all ingress traffic with SRP PCPs (e.g. see 802.1Q Table 6-5) and then a per-stream egress entry that sets the queue and priority.
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
> The issue here is the Marvell switch has an implementation where we need to > know if an entry is a Dynamic Reservation Entry. But the linux bridge has a > simplified version of the FDB described in 802.1Q. > By adding a way to distinguish between the type of FDB entries, it's possible > to program a Marvell which has this distinction between Dynamic Reservation > Entries (or AVB entries) and other entries. So it sounds like you first need to work on the software implementation and expand the simplified version with the features you need. You can then add support to accelerate this by offloading it to the hardware. Andrew
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
On Thu, Jun 04, 2026 at 03:39:25PM +1000, Luke Howard wrote: > On 3 Jun 2026, at 5:35 pm, Nikolay Aleksandrov wrote: > > So looking at how this is implemented, why not put most of it in TC? > > It is testing for skb class, for tc qdisc, I don't see a reason for it > > to be in the bridge at all. You can filter the mcast groups and simulate > > the "reserved" flag, it has to be set manually anyway. Adding new > > tests in the bridge software fast-path just for this is a waste. > > This makes sense. Maybe it’s better to use flower+TCAM to implement this, and > have our SRP daemon manage flower entries in addition to MDB entries. The > mv88e6xxx driver’s TCAM support is recent (hi Cedric!) and does not yet > appear to support the 6352 or matching on PCP/DA, but one presumes this is > possible to add. > > Alternatively, responding to your comments, the bridge could mark frames with > a “stream reserved” DA with a new tc_skb_ext bit, which would be surfaced to > flower similarly to l2_miss. The rest of the policy would live in the flower > rule. MDB_FLAGS_STREAM_RESERVED would remain but > IFLA_BRPORT_FILTER_STREAM_RESERVED could go (we would dynamically enable the > equivalent in mv88e6xxx by refcounting MDB_FLAGS_STREAM_RESERVED entries). > I don't know if this can be done in TC. For the usecase of SRP the Marvell has bits in it's mac entries to specify is an AVB entry. This looks vendor specific, and other vendors don't have it. But the concept comes from the 802.1Q spec. The spec describes different types of FDB entries. One of these is Dynamic Reservation Entries, which are created from the Stream Reservation Protocol. The issue here is the Marvell switch has an implementation where we need to know if an entry is a Dynamic Reservation Entry. But the linux bridge has a simplified version of the FDB described in 802.1Q. By adding a way to distinguish between the type of FDB entries, it's possible to program a Marvell which has this distinction between Dynamic Reservation Entries (or AVB entries) and other entries. Cedric
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
On 3 Jun 2026, at 5:35 pm, Nikolay Aleksandrov wrote: > So looking at how this is implemented, why not put most of it in TC? > It is testing for skb class, for tc qdisc, I don't see a reason for it > to be in the bridge at all. You can filter the mcast groups and simulate > the "reserved" flag, it has to be set manually anyway. Adding new > tests in the bridge software fast-path just for this is a waste. This makes sense. Maybe it’s better to use flower+TCAM to implement this, and have our SRP daemon manage flower entries in addition to MDB entries. The mv88e6xxx driver’s TCAM support is recent (hi Cedric!) and does not yet appear to support the 6352 or matching on PCP/DA, but one presumes this is possible to add. Alternatively, responding to your comments, the bridge could mark frames with a “stream reserved” DA with a new tc_skb_ext bit, which would be surfaced to flower similarly to l2_miss. The rest of the policy would live in the flower rule. MDB_FLAGS_STREAM_RESERVED would remain but IFLA_BRPORT_FILTER_STREAM_RESERVED could go (we would dynamically enable the equivalent in mv88e6xxx by refcounting MDB_FLAGS_STREAM_RESERVED entries). Luke
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
On 02/06/2026 03:43, Luke Howard wrote:
Add the BR_FILTER_STREAM_RESERVED bridge port flag, gated by
CONFIG_BRIDGE_8021Q_SRP, which may be used to enforce 802.1Qat admission
control on ports that have it set.
A frame received by a port with the flag set, and whose 802.1p priority
maps (via an MQPRIO/TAPRIO Qdisc on the bridge) to a non-zero traffic
class, is admitted only if it belongs to a reserved stream. Reserved
streams are multicast frames whose MDB entry has FLAGS_STREAM_RESERVED
set. Unicast and broadcast frames sharing this priority are dropped.
Non-admitted frames are dropped after source address learning.
Multicast snooping must be enabled on the bridge for admission control
to function correctly: with snooping disabled, no MDB entries exist and
all SR-class multicast frames on SR-filtered ports would be dropped.
There is no support for reserved unicast streams at present; although
permitted by 802.1Qat (SRP) they are rarely used in practice.
The choice to not allow configurable mapping of traffic classes was done
in the interest of simplicity and keeping the number of additional
instructions in the forwarding path to a minimum. It is anticipated this
will suffice for the common AVB/TSN use case.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Luke Howard
---
include/linux/if_bridge.h | 1 +
include/uapi/linux/if_link.h | 9 +
net/bridge/Kconfig | 22 +
net/bridge/br_input.c | 59 ++-
net/bridge/br_netlink.c| 8 +-
net/bridge/br_private.h| 3 +-
net/bridge/br_switchdev.c | 3 +-
net/core/rtnetlink.c | 2 +-
tools/testing/selftests/net/forwarding/Makefile| 1 +
.../net/forwarding/bridge_mdb_stream_reserved.sh | 536 +
tools/testing/selftests/net/forwarding/config | 2 +
11 files changed, 641 insertions(+), 5 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index ec9ffea1e46ed..a5e91bace0464 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -62,6 +62,7 @@ struct br_ip_list {
#define BR_PORT_MAB BIT(22)
#define BR_NEIGH_VLAN_SUPPRESSBIT(23)
#define BR_NEIGH_FORWARD_GRAT BIT(24)
+#define BR_FILTER_STREAM_RESERVED BIT(25)
#define BR_DEFAULT_AGEING_TIME (300 * HZ)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 46413392b402c..80f5a2b4162c8 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -1106,6 +1106,14 @@ enum {
* backup port that has VLAN tunnel mapping enabled (via the
* *IFLA_BRPORT_VLAN_TUNNEL* option). Setting a value of 0 (default) has
* the effect of not attaching any ID.
+ *
+ * @IFLA_BRPORT_FILTER_STREAM_RESERVED
+ * Controls whether the port enforces 802.1Qat stream reservation
+ * admission control. When enabled, a frame received on the port whose
+ * 802.1p priority maps (via an MQPRIO/TAPRIO Qdisc on the bridge) to a
+ * non-zero traffic class is dropped at ingress unless it belongs to a
+ * reserved stream, i.e. it is multicast and its destination address has a
+ * stream-reserved MDB entry. The flag is off by default.
*/
enum {
IFLA_BRPORT_UNSPEC,
@@ -1154,6 +1162,7 @@ enum {
IFLA_BRPORT_NEIGH_VLAN_SUPPRESS,
IFLA_BRPORT_BACKUP_NHID,
IFLA_BRPORT_NEIGH_FORWARD_GRAT,
+ IFLA_BRPORT_FILTER_STREAM_RESERVED,
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/net/bridge/Kconfig b/net/bridge/Kconfig
index 318715c8fc9bc..7e46b791922a6 100644
--- a/net/bridge/Kconfig
+++ b/net/bridge/Kconfig
@@ -47,6 +47,28 @@ config BRIDGE_IGMP_SNOOPING
If unsure, say Y.
+config BRIDGE_8021Q_SRP
+ bool "802.1Qat Stream Reservation Protocol (SRP) admission control"
+ depends on BRIDGE
+ default n
While it's ok to have a kconfig, from experience almost all distros will
enable this, so you have to better optimize the software fast-path and
make this feature almost a no-op when not enabled, but more below..
This is also a very small feature and I'm not yet convinced it has to be
in the bridge at all, you can drop the kconfig.
+ help
+ If you say Y here, then the Ethernet bridge will enforce 802.1Qat
+ stream reservation admission control in software on ingress ports
+ that have the BR_FILTER_STREAM_RESERVED flag set: a frame whose
+ 802.1p priority maps (via an MQPRIO/TAPRIO Qdisc on the bridge) to
+ a non-zero traffic class is dropped unless it is multicast and its
+ destination address MDB_FLAGS_STREAM_RESERVED set on its MDB entry.
+
+ This option only controls software enforcement. The
+ BR_FILTER_STREAM_RESERVED port flag and MDB_FLAGS_STREAM_RESERVED
+
Re: [PATCH net-next v2 3/6] net: bridge: add 802.1Qat stream reservation admission control
> On 2 Jun 2026, at 10:43 am, Luke Howard wrote: > > + if (mdst->flags & BRIDGE_MDBE_F_HOST_STREAM_RESERVED) > + return false; This flag should not have appeared until patch 4/6 (allow MDB_FLAGS_STREAM_RESERVED on host groups). Will be fixed in the next revision.
