From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by mail.toke.dk (Postfix) with ESMTPS id ACBD5A2EBA6 for ; Thu, 5 Oct 2023 19:16:09 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=OQgZ4R74 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 03ADBCE239C; Thu, 5 Oct 2023 17:16:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6398EC433CA; Thu, 5 Oct 2023 17:16:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696526166; bh=6TQPomYGzW80iUud7BEbLiiItfun6wvVQP2bFLm/bWs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OQgZ4R74PH/6FVF4WXTtHbAPY4fs3kBrO1oPh4677MYWPjNQRLnppFa63YkDQtCZV lDT+5a+MV1b275EQ5LYdUwoj2juDbcHv3LlqDGJhZlkg6CnMLpXX2NbCoSAdhiQevH J0VuMf0Jp7gW6AjCHUnH2ScMM6/y60bnSr3nJI38IKuFSw/ExgOy7xj6bIRIfWZ4mr AftudFVaHtmN05gZZa1Vqfu65P64Cv+Ri8n3duDa3yt1/1XeCJ94VduIV9OWCQHkjz LU5JbVwIB7UJ2HDjLDyrt2gCs5iPYbaJ6JZS9pqZCy1v/XIr/kbfl1vVhKJiT9bEiX rMPagj8eXtI1A== Date: Thu, 5 Oct 2023 10:16:04 -0700 From: Jakub Kicinski To: Alexander Lobakin Message-ID: <20231005101604.33b382d8@kernel.org> In-Reply-To: References: <20230927075124.23941-1-larysa.zaremba@intel.com> <20230927075124.23941-10-larysa.zaremba@intel.com> <20231003053519.74ae8938@kernel.org> <8e9d830b-556b-b8e6-45df-0bf7971b4237@intel.com> <20231004110850.5501cd52@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: FNJMUGJ7QYB4CUSWEKXXUFLIC4KWVJQG X-Message-ID-Hash: FNJMUGJ7QYB4CUSWEKXXUFLIC4KWVJQG X-MailFrom: kuba@kernel.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Larysa Zaremba , bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, David Ahern , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, Willem de Bruijn , Alexei Starovoitov , Simon Horman , Tariq Toukan , Saeed Mahameed , Maciej Fijalkowski X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v2 09/24] xdp: Add VLAN tag hint List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 :(