Hi ! > Please give people more time to review the proposed RFCs before > sending v1. Also you specifically asked bridge maintainers to comment > and did not wait for us to do so.
Fair point. I jumped to v1 too quickly. I CC'd the bridge list and you specifically, then turned around v1 inside a day on the strength of one review. I should have waited; sorry for the noise. > First, I'd like to ask: could you please elaborate why bridge's > group_fwd_mask isn't working out for you? Honest answer: I should have tested that configuration before posting, and I didn't. Let me actually run a 2-port bridge with group_fwd_mask set, no_learning, stp_state 0, vlan_filtering 0, and see where it falls short of a TPMR — if it falls short at all. The places I'd expect to differ are PAUSE handling, multicast outside the 01:80:c2:00:00:0x range, and carrier semantics, but I haven't proven any of that with real traffic. If the bridge configuration covers everything materially, dropping this driver is the right call — 400 LOC duplicating existing functionality isn't worth it. If there's a concrete gap, I'd rather close it inside the bridge than maintain a parallel driver. > Second, what else did you try and how exactly did you try it? Same admission. tc mirred, cls_bpf, nftables, XDP_REDIRECT are all on the table and I haven't evaluated any of them seriously against the use case. Let me come back with measurements instead of arguing in the abstract. Please consider v1 parked until then. Thanks for the pushback. David
