> 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.
