From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A26B318A6CE; Mon, 27 Jan 2025 19:20:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738005648; cv=none; b=eoaSH+WsXJTuroO+GM/mPxvj39xskMYBHGQeFg/O9JOWLtuUzwK7ec78qT1ben7j5CLKCeG/Gw1XSTcqHZ/lSvT7qKwT3aPVknSnTCnf/4atc+fyFGEgo02Rnt1PqVHcw5ZUnY93+l2JXsiJAUERsTOFSuEQBEaxV1K0ykbkL9I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738005648; c=relaxed/simple; bh=YeJVXMPKQVT2qsyx36ahTAqXBMoa9oYa3q1Abfi3NGk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AVVEhHmCAhkG675aIOSq6SI7pIROOYAhiFg0EjFE36l+437MmP+va2Mp1BilJWpdvcA5cSV3ojLtP4s34US6S9y6Z5IC9Z4A4H5L6GMNcfkcNm65Q5UgglwlIAVX9gpa2WfK9AEc1gI2w89Z/yunCeb752BWeyztM/6vaCceetA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X/EKy9Og; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X/EKy9Og" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E1C8C4CED2; Mon, 27 Jan 2025 19:20:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738005648; bh=YeJVXMPKQVT2qsyx36ahTAqXBMoa9oYa3q1Abfi3NGk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=X/EKy9OgP8a/LbZ2+lTRgcEO98s5Q0e1iAJTMz4l9hD2J3dHrzjvTTRln8GGKfwMx gXoEPDaOxs1078NbidR7ETR3lQXPuvQj6o97rpdgTt5nmVX7CnW9kVpybWiq52kcjO PnQSV0eQyFqEIM6fwU09ysiQVyygIu5mQBoh6wcWh00yGxuCAqMy84r6TrUt3JqcGQ Ige7cvkgY8D7eTqbUJ4smnrzZK9K6t1/No66UKwMjSznrq7Izo3TDhCW3hQRaV2U8A EL0zrywHlI0Sj+Y7YMn+op7H7PbtXeAbIz0riCWqAKG/P6SGefd57yFL550KIAwfnZ TbJou8dble8Xw== Date: Mon, 27 Jan 2025 11:20:45 -0800 From: Jakub Kicinski To: Florian Bezdeka Cc: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , Stanislav Fomichev , "Song, Yoong Siang" , "Bouska, Zdenek" , "David S . Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Willem de Bruijn , Donald Hunter , Jonathan Corbet , Bjorn Topel , "Karlsson, Magnus" , "Fijalkowski, Maciej" , Jonathan Lemon , Andrew Lunn , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , "Damato, Joe" , Stanislav Fomichev , Xuan Zhuo , Mina Almasry , Daniel Jurgens , Andrii Nakryiko , Eduard Zingerman , Mykola Lysenko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Shuah Khan , Alexandre Torgue , Jose Abreu , Maxime Coquelin , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "bpf@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "intel-wired-lan@lists.osuosl.org" , "xdp-hints@xdp-project.net" Subject: Re: [xdp-hints] Re: [PATCH bpf-next v6 4/4] igc: Add launch time support to XDP ZC Message-ID: <20250127112045.7e3997fc@kernel.org> In-Reply-To: <221bb71f7d2464cd566e4a4110423ea56b173cf6.camel@siemens.com> References: <20250116155350.555374-1-yoong.siang.song@intel.com> <20250116155350.555374-5-yoong.siang.song@intel.com> <87bjvwqvtl.fsf@toke.dk> <20250127100441.0b11e1b8@kernel.org> <221bb71f7d2464cd566e4a4110423ea56b173cf6.camel@siemens.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 27 Jan 2025 19:29:35 +0100 Florian Bezdeka wrote: > > > Yeah, I don't think we can impose UAPI restrictions on the metadata a= rea > > > at this point. I guess the best we can do is to educate users that th= ey > > > should call the timestamp kfunc before they modify the metadata? =20 > >=20 > > I may be misunderstanding the discussion, but I think the answer=20 > > is that the driver must be fixed. The metadata-in-prepend problem > > also exists for simple adjust head use case, so it existed since > > early days of BPF. The driver should copy out (or parse) the metadata > > before it invokes the XDP prog. The nfp driver does that. =20 >=20 > That would have to happen for each packet, without affecting ZC > performance. How can that be achieved? Are you asking how we can make it not affect performance? We should really see some benchmarks before we say that it is okay to sacrifice correctness.. > So we have at least two drivers with that problem, igc + nfp.=20 To be clear nfp copies the HW metadata out before calling XDP. So XDP program can do whatever it wants to the space before the packet. > My main point: Enabling and implementing ZC (zero copy) mode at one > hand, but then starting to copy the meta data for each packet doesn't > sound reasonable. =F0=9F=A4=B7=EF=B8=8F From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 38ECBC02188 for ; Mon, 27 Jan 2025 19:20:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id D27D3406C9; Mon, 27 Jan 2025 19:20:54 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id 6xFNXIS6B3sk; Mon, 27 Jan 2025 19:20:54 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E7021406B1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1738005654; bh=YeJVXMPKQVT2qsyx36ahTAqXBMoa9oYa3q1Abfi3NGk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=zDzuG/wigWLkqAyVtwJgFm0Tr1mq6h1xpSRDUgvTHMDRacozk4jC6n7r94+WsVwmi Xoy9DoiWveauzbTWqFOvvZ0R9dA/PoVuPJK79nqYtBlZk84AuE/Cs+liEGSDSEC2// GZpTH4SsiO/p54UXIuN6N/qYXQekFlnEdADWaszdK7uCu/ZH/OeXpDcfSH7o2wr5vr GROwQRs0zvC+gzKHMusZcfjm+2VGz0cDnt9d1KK9w2CH8OBvgPceCxFpaOer85Vbiy R42QSDWr+7D95M2GXCYGtYI6lYCXC+vMZswGxwyiuksXoYLmNJF3K7TGlgdmzT67yq 8thnLnGFmCCdA== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp4.osuosl.org (Postfix) with ESMTP id E7021406B1; Mon, 27 Jan 2025 19:20:53 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists1.osuosl.org (Postfix) with ESMTP id C856E976 for ; Mon, 27 Jan 2025 19:20:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B5E6040179 for ; Mon, 27 Jan 2025 19:20:51 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id UWXbL4SYV55O for ; Mon, 27 Jan 2025 19:20:51 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2604:1380:45d1:ec00::3; helo=nyc.source.kernel.org; envelope-from=kuba@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp2.osuosl.org 8C8DB40259 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8C8DB40259 Received: from nyc.source.kernel.org (nyc.source.kernel.org [IPv6:2604:1380:45d1:ec00::3]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8C8DB40259 for ; Mon, 27 Jan 2025 19:20:50 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D5F8FA419E9; Mon, 27 Jan 2025 19:19:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E1C8C4CED2; Mon, 27 Jan 2025 19:20:46 +0000 (UTC) Date: Mon, 27 Jan 2025 11:20:45 -0800 From: Jakub Kicinski To: Florian Bezdeka Cc: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , Stanislav Fomichev , "Song, Yoong Siang" , "Bouska, Zdenek" , "David S . Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Willem de Bruijn , Donald Hunter , Jonathan Corbet , Bjorn Topel , "Karlsson, Magnus" , "Fijalkowski, Maciej" , Jonathan Lemon , Andrew Lunn , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , "Damato, Joe" , Stanislav Fomichev , Xuan Zhuo , Mina Almasry , Daniel Jurgens , Andrii Nakryiko , Eduard Zingerman , Mykola Lysenko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Shuah Khan , Alexandre Torgue , Jose Abreu , Maxime Coquelin , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "bpf@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "intel-wired-lan@lists.osuosl.org" , "xdp-hints@xdp-project.net" Message-ID: <20250127112045.7e3997fc@kernel.org> In-Reply-To: <221bb71f7d2464cd566e4a4110423ea56b173cf6.camel@siemens.com> References: <20250116155350.555374-1-yoong.siang.song@intel.com> <20250116155350.555374-5-yoong.siang.song@intel.com> <87bjvwqvtl.fsf@toke.dk> <20250127100441.0b11e1b8@kernel.org> <221bb71f7d2464cd566e4a4110423ea56b173cf6.camel@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738005648; bh=YeJVXMPKQVT2qsyx36ahTAqXBMoa9oYa3q1Abfi3NGk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=X/EKy9OgP8a/LbZ2+lTRgcEO98s5Q0e1iAJTMz4l9hD2J3dHrzjvTTRln8GGKfwMx gXoEPDaOxs1078NbidR7ETR3lQXPuvQj6o97rpdgTt5nmVX7CnW9kVpybWiq52kcjO PnQSV0eQyFqEIM6fwU09ysiQVyygIu5mQBoh6wcWh00yGxuCAqMy84r6TrUt3JqcGQ Ige7cvkgY8D7eTqbUJ4smnrzZK9K6t1/No66UKwMjSznrq7Izo3TDhCW3hQRaV2U8A EL0zrywHlI0Sj+Y7YMn+op7H7PbtXeAbIz0riCWqAKG/P6SGefd57yFL550KIAwfnZ TbJou8dble8Xw== X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=X/EKy9Og Subject: Re: [Intel-wired-lan] [xdp-hints] Re: [PATCH bpf-next v6 4/4] igc: Add launch time support to XDP ZC X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Mon, 27 Jan 2025 19:29:35 +0100 Florian Bezdeka wrote: > > > Yeah, I don't think we can impose UAPI restrictions on the metadata a= rea > > > at this point. I guess the best we can do is to educate users that th= ey > > > should call the timestamp kfunc before they modify the metadata? =20 > >=20 > > I may be misunderstanding the discussion, but I think the answer=20 > > is that the driver must be fixed. The metadata-in-prepend problem > > also exists for simple adjust head use case, so it existed since > > early days of BPF. The driver should copy out (or parse) the metadata > > before it invokes the XDP prog. The nfp driver does that. =20 >=20 > That would have to happen for each packet, without affecting ZC > performance. How can that be achieved? Are you asking how we can make it not affect performance? We should really see some benchmarks before we say that it is okay to sacrifice correctness.. > So we have at least two drivers with that problem, igc + nfp.=20 To be clear nfp copies the HW metadata out before calling XDP. So XDP program can do whatever it wants to the space before the packet. > My main point: Enabling and implementing ZC (zero copy) mode at one > hand, but then starting to copy the meta data for each packet doesn't > sound reasonable. =F0=9F=A4=B7=EF=B8=8F