[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230523132951.623288cb@kernel.org>
Date: Tue, 23 May 2023 13:29:51 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Ido Schimmel <idosch@...dia.com>
Cc: razor@...ckwall.org, netdev@...r.kernel.org,
bridge@...ts.linux-foundation.org, davem@...emloft.net, pabeni@...hat.com,
edumazet@...gle.com, roopa@...dia.com, taras.chornyi@...ision.eu,
saeedm@...dia.com, leon@...nel.org, petrm@...dia.com,
vladimir.oltean@....com, claudiu.manoil@....com,
alexandre.belloni@...tlin.com, UNGLinuxDriver@...rochip.com,
jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...nulli.us,
taspelund@...dia.com
Subject: Re: [PATCH net-next 1/5] skbuff: bridge: Add layer 2 miss
indication
On Tue, 23 May 2023 11:10:38 +0300 Ido Schimmel wrote:
> > 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?
Sounds good, yup. Thanks!
Powered by blists - more mailing lists