> On 6 Jun 2026, at 6:21 pm, Nikolay Aleksandrov <[email protected]> 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.
