On Wed, 5 Jan 2022, Daniel Borkmann wrote:
> On 1/5/22 3:57 PM, Jamal Hadi Salim wrote: > > On 2022-01-04 03:28, Paul Blakey wrote: > > [..] > >> --- a/include/linux/skbuff.h > >> +++ b/include/linux/skbuff.h > >> @@ -287,7 +287,9 @@ struct tc_skb_ext { > >> __u32 chain; > >> __u16 mru; > >> __u16 zone; > >> - bool post_ct; > >> + bool post_ct:1; > >> + bool post_ct_snat:1; > >> + bool post_ct_dnat:1; > >> }; > > > > is skb_ext intended only for ovs? If yes, why does it belong > > in the core code? Ex: Looking at tcf_classify() which is such > > a core function in the fast path any packet going via tc, it > > is now encumbered with with checking presence of skb_ext. > > I know passing around metadata is a paramount requirement > > for programmability but this is getting messier with speacial > > use cases for ovs and/or offload... > > Full ack on the bloat for corner cases like ovs offload, especially > given distros just enable most stuff anyway and therefore no light > fast path as with !CONFIG_NET_TC_SKB_EXT. :( > > Could this somehow be hidden behind static key or such if offloads > are not used, so we can shrink it back to just calling into plain > __tcf_classify() for sw-only use cases (like BPF)? > > It is used for both tc -> ovs and driver -> tc path. I think I can do what you suggest adn will work on something like that, but this specific patch doesn't really change the ext allocation/derefences count (and probably not the size as well). So can we take this (not yet posted v2 after fixing what already mentioned) and I'll do a patch of what you suggest in net-next? _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev