From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794771545; b=ht9e48ECeeIMNUqO+SRYsM/BmzBRrlj9HEetx5xgSeK9e1Pr9flttt4fE0Rj/X3byksg 7Ig3hjz4aMw7jH/cmNiz9GPrDs/q+LLev7lZz2JnEW+CUukGFg1lplAfmWfjFu/5b8urH U8n7G/j56i2srEiI0eId/aDUoVHdF5Lq5MlopxZD0Z0YaOpZfdryHU98DNpux4hpy9q67 jKfgsTZz/b2f0V7qLuh6vo99MI4AvSUkcVmAb1Yd4fErYQlU1Usy50QDBHraaLKiOADjQ 3o8gPouYIMIByJ5oRcbL5/q7NcfYODzyPzEKAB2/fR8JJ9wB7E1k5fM7ggxZDtgruNg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794771545; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=nhfeoYtF7WorX7zGjUIuskRdAMeUM/Fthys1xBCjJm0=; b=nOxt/zB4e2MAd88yK2g6LfDYzNXqU2MvfapAk8CsotFrau6kNJE6jd2C4FpfLSoBibwx nwaFAItza7ciyuNcjDA1bqIGJj1ifKkikkjg/D8uztDgjs6+gGHXii6+23VYWCjUEAAOm +L3RdHRMjSmCGAEnCxxzffrq03qLuCrZPAh3pzKjNgf8XqddbUcxBz0RLyoLiBZWLYnrU D/wmyfYxkQ1qM01MKOW06kkeccG6Lp5+28SOPJA1C39o6iDqXs2416W6pwfljMUdzJgrz TcXduxZsgFgd4ym2bKWQVc5tcRIflntz2Vg5ZDx/KjVyYDUPmWY36P4PHOme6Bt9OtA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=dVa3kJOZ; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 179CA606A333; Sun, 15 Nov 2026 19:39:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=dVa3kJOZ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C8141F000C4; Sun, 15 Nov 2026 19:39:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794771544; bh=nhfeoYtF7WorX7zGjUIuskRdAMeUM/Fthys1xBCjJm0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=dVa3kJOZBz7IO1OByxjM4DlK62AKKz9Ka3JoFzukyf8Mtt0WvAaVeywOTe2Oxg/b8 pJyd/Hcb01G5boe98nFycm5mUUClT8X7Ntu/1hFxdikFhRyhtf5j8ITJmO/TeBJjtn MllBZTZzBOIQzHQks6G53m4E5EztR9RrlaTTKls1hOvK+K0NTFkTZ0W9xoU+OfWydr ehuUkkZB4od/5R7m6mbCjNblOJ3ivYl6FVgGGrPUx9aJuPBpos7I+xoq6QBgkYsa+6 gWd3jR4JLD89gS/0b1XfIfCvKSoESH/3bKWJJBKhwwBrXXZ7j6EIEV0axeTCYXQoLi 8Uf7b4PEUNkjQ== Date: Sun, 15 Nov 2026 11:39:02 -0800 From: Jakub Kicinski To: Tianyi Gao Cc: Stanislav Fomichev , bpf@vger.kernel.org, netdev@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Lorenzo Bianconi , Vladimir Vdovin , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Andrew Lunn , Donald Hunter , Eduard Zingerman , Kumar Kartikeya Dwivedi , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Tony Nguyen , Przemek Kitszel , Maciej Fijalkowski , Alexander Lobakin , Magnus Karlsson , Tushar Vyavahare , Jason Xing , Nikolay Aleksandrov , Madalin Bucur , Ioana Ciornei , Jonathan Corbet , Shuah Khan , Shuah Khan , Randy Dunlap , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Chris J Arges , Jakub Sitnicki , linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, intel-wired-lan@lists.osuosl.org, llvm@lists.linux.dev, kernel-team@cloudflare.com Subject: Re: [PATCH bpf-next 00/15] xdp: add SKB core extensions to keep RX metadata until skb creation Message-ID: <20261115113902.4834dda6@kernel.org> In-Reply-To: References: X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 11 Nov 2026 01:07:46 +0000 Tianyi Gao wrote: > - On veth, an XDP program removes software GSO from the peer, limits > its MTU, and can copy skbs from the peer. Could you remind us why you XDP_REDIRECT xdp_frames to the veth if you end up allocating the skb on the veth, anyway? I thought that was to let veth run its own prog before skb is allocated but you're saying that you want to avoid veth having a prog, so clearly it's not that.