From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta-65-227.siemens.flowmailer.net (mta-65-227.siemens.flowmailer.net [185.136.65.227]) (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 E9AA618BC2F for ; Mon, 27 Jan 2025 18:39:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.136.65.227 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738003191; cv=none; b=ghsEVUymvKuDUvagIjOmkpsjISCWSf7NZjomJY+B78ZqiFTo3obZp84dOVCBvXDCV4xriH+UwFa4q9JJUWwkVbKijiy6RTMUV/R+hwU4wbVGIQ+fd+9g132AAE6M8f5v2zJasd5TLVGyi3ZdbW1jhSSFSPzzPjWo3zlWHV2Be6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738003191; c=relaxed/simple; bh=6panixb/x0os5ZapLWWRdFuJUYpBXz06VpJ2DjP+mog=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Tra0mkY4thMGTQ7KjSrVWwClg5x4+HcBhYB0zPzOEV88IgVyI6icDpwyvffQIJQYG/R5Yy0Zi1EW3tDuo2S2VykNHTH1qKC+le+IrXxY35Hs0HHFgob+XWmeJR2JOeXcf+RK4uIvQqdKmE1CetYf+dzkgXYxbdjNhybH30j3FZo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens.com; spf=pass smtp.mailfrom=rts-flowmailer.siemens.com; dkim=pass (2048-bit key) header.d=siemens.com header.i=florian.bezdeka@siemens.com header.b=A1zeyUFF; arc=none smtp.client-ip=185.136.65.227 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rts-flowmailer.siemens.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=siemens.com header.i=florian.bezdeka@siemens.com header.b="A1zeyUFF" Received: by mta-65-227.siemens.flowmailer.net with ESMTPSA id 20250127182936dda3d0868c72db7e8f for ; Mon, 27 Jan 2025 19:29:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm2; d=siemens.com; i=florian.bezdeka@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc:References:In-Reply-To; bh=6panixb/x0os5ZapLWWRdFuJUYpBXz06VpJ2DjP+mog=; b=A1zeyUFFCuD1/01IlvyP8a7nStl/yDefRzLmN46eDButuHBxshahsCwHerO9PK5bZUwBaa JjuZ5wN8wapbhPC7RQH833+3AZaTuy5Hg9Ykwfzz2qbR4tv9DDUEljsoo1ZPr0Oe7Ctz7mC+ wTnT8ep8aZOaz2/vVNjJtHPEGReehUgGbNGdIiGu/viqY/zVDKE21ZWEMttrkvLeZcasGW7/ bUjQ/l9tUym2erHZPCi2O/EuxulhwAgkra8vG+fKXFKYgN5pwU4OI0YQpq+ElJ/AqKR+EZmY GFEQX2KONvo3NAcX/+vsmHnehfI7eOIDOwh9xoWZpnQY3dJH4fvY2VUg==; Message-ID: <221bb71f7d2464cd566e4a4110423ea56b173cf6.camel@siemens.com> Subject: Re: [xdp-hints] Re: [PATCH bpf-next v6 4/4] igc: Add launch time support to XDP ZC From: Florian Bezdeka To: Jakub Kicinski , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: 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" Date: Mon, 27 Jan 2025 19:29:35 +0100 In-Reply-To: <20250127100441.0b11e1b8@kernel.org> 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-68982:519-21489:flowmailer On Mon, 2025-01-27 at 10:04 -0800, Jakub Kicinski wrote: > On Fri, 24 Jan 2025 12:45:42 +0100 Toke H=C3=B8iland-J=C3=B8rgensen wrote= : > > > > I think there is no simple fix for that. That needs some discussion > > > > around the "expectations" to the headroom / meta data area in front= of > > > > the actual packet data. =20 > > >=20 > > > By 'simple' you mean without some new UAPI to signal the size of that > > > 'reserved area' by the driver? I don't see any other easy way out as = well :-/ =20 > >=20 > > Yeah, I don't think we can impose UAPI restrictions on the metadata are= a > > at this point. I guess the best we can do is to educate users that they > > should call the timestamp kfunc before they modify the metadata? >=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. That would have to happen for each packet, without affecting ZC performance. How can that be achieved? So we have at least two drivers with that problem, igc + nfp.=20 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.