On Fri, Sep 20, 2019 at 5:06 PM Daniel Borkmann <dan...@iogearbox.net> wrote: > > On 9/21/19 12:56 AM, Jakub Kicinski wrote: > [...] > >> I thought idea of stuffing things into skb extensions are only justified if > >> it's not enabled by default for everyone. :( > >> > >> [0] > >> https://lore.kernel.org/netdev/cahc9vhsz1_ka1tcjtnjwk26bokghkgbpt7v1o82mwpduvww...@mail.gmail.com/T/#u > > > > The skb ext allocation is only done with GOTO_CHAIN, which AFAIK only > > has practical use for offload. We could perhaps add another static > > branch there or move the OvS static branch out of the OvS module so > > there are no linking issues? > > > > I personally have little sympathy for this piece of code, it is perhaps > > the purest form of a wobbly narrow-use construct pushed into TC for HW > > offload. > > > > Any suggestions on the way forward? :( > > Presumably there are no clean solutions here, but on the top of my head for > this use case, you'd need to /own/ the underlying datapath anyway, so couldn't > you program the OVS key->recirc_id based on skb->mark (or alternatively via > skb->tc_index) which was previously set by tc ingress? >
If we are going down this path, tc_index should be used. skb->mark is already used in OVS flow match, overloading it for this purpose would be complicated.
