Subject: Re: [xdp-hints] Re: [RFC bpf-next v2 09/24] xdp: Add VLAN tag hint

From: David Ahern <[email-masked]>
Date: Thu, 5 Oct 2023 11:20:49 -0600

On 10/5/23 11:16 AM, Jakub Kicinski wrote:
> On Thu, 5 Oct 2023 18:58:33 +0200 Alexander Lobakin wrote:
>>> No unsharing - you can still strip it in the driver.  
>>
>> Nobody manually strips VLAN tags in the drivers. You either have HW
>> stripping or pass VLAN-tagged skb to the stack, so that skb_vlan_untag()
>> takes care of it.
> 
> Isn't it just a case of circular logic tho?
> We don't optimize the stack for SW stripping because HW does it.
> Then HW does it because SW is not optimized.
> 
>>> Do you really think that for XDP kfunc call will be cheaper?  
>>
>> Wait, you initially asked:
>>
>> * discussion about the validity of VLAN stripping as an offload?
>> * Do people actually care about having it enabled?
>>
>> I did read this as "do we still need HW VLAN stripping in general?", not
>> only for XDP. So I replied for "in general" -- yes.
>> Forcefully disabling stripping when XDP is active is obscure IMO, let
>> the user decide.
> 
> Every time I'm involved in conversations about NIC datapath host
> interfaces I cringe at this stupid VLAN offload. Maybe I'm too
> daft to understand it's amazing value but we just shift 2B from
> the packet to the descriptor and then we have to worry about all
> the corner cases that come from vlan stacking :(

4B (vlan tci + protocol).

VLAN stripping in S/W and pushing the header on Tx is measurable and
does have a noticeable performance impact.

XDP programs need to co-exist with enabled offloads. If the tag is not
stripped, XDP program needs to handle it. If the tag is stripped, the
XDP program needs to access to the value.