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.
