On Tue, 2023-05-23 at 11:10 +0300, 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? Looks good to me. I think you would only need to set/add the extension when l2_miss is true, right? (with no extension l2 hit is assumed). That will avoid unneeded overhead for br_dev_xmit(). All the others involved paths look like slow(er) one, so the occasional skb extension overhead should not be a problem. Cheers, Paolo
