On 23/05/2023 11:10, Ido Schimmel wrote: > On Fri, May 19, 2023 at 02:52:18PM -0700, Jakub Kicinski wrote: >> On Fri, 19 May 2023 16:51:48 +0300 Ido Schimmel wrote: >>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c >>> index fc17b9fd93e6..274e55455b15 100644 >>> --- a/net/bridge/br_input.c >>> +++ b/net/bridge/br_input.c >>> @@ -46,6 +46,8 @@ static int br_pass_frame_up(struct sk_buff *skb) >>> */ >>> br_switchdev_frame_unmark(skb); >>> >>> + skb->l2_miss = BR_INPUT_SKB_CB(skb)->miss; >>> + >>> /* Bridge is just like any other port. Make sure the >>> * packet is allowed except in promisc mode when someone >>> * may be running packet capture. >>> >>> Ran these changes through the selftest and it seems to work. >> >> Can we possibly put the new field at the end of the CB and then have TC >> look at it in the CB? We already do a bit of such CB juggling in strp >> (first member of struct sk_skb_cb). > > Using the CB between different layers is very fragile and I would like > to avoid it. Note that the skb can pass various layers until hitting the > classifier, each of which can decide to memset() the CB. > > Anyway, I think I have a better alternative. I added the 'l2_miss' bit > to the tc skb extension and adjusted the bridge to mark packets via this > extension. The entire thing is protected by the existing 'tc_skb_ext_tc' > static key, so overhead is kept to a minimum when feature is disabled. > Extended flower to enable / disable this key when filters that match on > 'l2_miss' are added / removed. > > bridge change to mark the packet: > https://github.com/idosch/linux/commit/3fab206492fcad9177f2340680f02ced1b9a0dec.patch > > flow_dissector change to dissect the info from the extension: > https://github.com/idosch/linux/commit/1533c078b02586547817a4e63989a0db62aa5315.patch > > flower change to enable / disable the key: > https://github.com/idosch/linux/commit/cf84b277511ec80fe565c41271abc6b2e2f629af.patch > > Advantages compared to the previous approach are that we do not need a > new bit in the skb and that overhead is kept to a minimum when feature > is disabled. Disadvantage is that overhead is higher when feature is > enabled. > > WDYT? > > To be clear, merely asking for feedback on the general approach, not > code review. > > Thanks TBH, I like this approach much better for obvious reasons. :) Thanks for working on it.
