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/#uThe 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? Thanks, Daniel
