From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1])
	by mail.toke.dk (Postfix) with ESMTPS id 454FD9C2D3D
	for <xdp-hints@xdp-project.net>; Wed, 16 Nov 2022 22:12:57 +0100 (CET)
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=TBru58/i
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ams.source.kernel.org (Postfix) with ESMTPS id A299BB81EBF;
	Wed, 16 Nov 2022 21:12:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F667C433C1;
	Wed, 16 Nov 2022 21:12:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1668633175;
	bh=vnx9mVfARHSrVJaNSRXAJQNrlYPKT7VsWaOhORiVAsY=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=TBru58/iEJoBJkVXDPZ4OYBSELb8Zna/f0jpjYlAQH6YR3qTxWTE/rqin+qdqkzRs
	 eQzuRHfjwaFRgd8nHdQkoqdNEWchMZIuslNUAvviQrD68iHj3+jwyQutGF0fLdnhE/
	 0nq0jEADm/SjpCe5KWYTrA+bRzrQkNv2eQuUTmdEeFohAIAivVP5pvso9TDED+0OE2
	 AsXznuFw9dRzl9H9JlT+DkutaLn0NZJTiv6GoeBK6+z7hQ4Daj04UT8Xmho3mbogHj
	 nwB1Kxd2nw4ytMj+KSPK19FBFVh/lgWLtNBABuqrdxH5MTmkHg+UvtPW6l0QLuMsNK
	 DBwzIXp/EngYg==
Date: Wed, 16 Nov 2022 13:12:53 -0800
From: Jakub Kicinski <kuba@kernel.org>
To: Stanislav Fomichev <sdf@google.com>
Message-ID: <20221116131253.6703f1c6@kernel.org>
In-Reply-To: <20221115030210.3159213-7-sdf@google.com>
References: <20221115030210.3159213-1-sdf@google.com>
	<20221115030210.3159213-7-sdf@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID-Hash: ORYMY6RYSE5K5GR6FIYNB32JP6F6JHMU
X-Message-ID-Hash: ORYMY6RYSE5K5GR6FIYNB32JP6F6JHMU
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: 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, haoluo@google.com, jolsa@kernel.org, David Ahern <dsahern@gmail.com>, Willem de Bruijn <willemb@google.com>, Jesper Dangaard Brouer <brouer@redhat.com>, Anatoly Burakov <anatoly.burakov@intel.com>, Alexander Lobakin <alexandr.lobakin@intel.com>, Magnus Karlsson <magnus.karlsson@gmail.com>, Maryam Tahhan <mtahhan@redhat.com>, xdp-hints@xdp-project.net, netdev@vger.kernel.org
X-Mailman-Version: 3.3.6
Precedence: list
Subject: [xdp-hints] Re: [PATCH bpf-next 06/11] xdp: Carry over xdp metadata into skb context
List-Id: XDP hardware hints design discussion <xdp-hints.xdp-project.net>
Archived-At: <https://lists.xdp-project.net/xdp-hints/20221116131253.6703f1c6@kernel.org/>
List-Archive: <https://lists.xdp-project.net/xdp-hints/>
List-Help: <mailto:xdp-hints-request@xdp-project.net?subject=help>
List-Owner: <mailto:xdp-hints-owner@xdp-project.net>
List-Post: <mailto:xdp-hints@xdp-project.net>
List-Subscribe: <mailto:xdp-hints-join@xdp-project.net>
List-Unsubscribe: <mailto:xdp-hints-leave@xdp-project.net>

On Mon, 14 Nov 2022 19:02:05 -0800 Stanislav Fomichev wrote:
> Implement new bpf_xdp_metadata_export_to_skb kfunc which
> prepares compatible xdp metadata for kernel consumption.
> This kfunc should be called prior to bpf_redirect
> or when XDP_PASS'ing the frame into the kernel (note, the drivers
> have to be updated to enable consuming XDP_PASS'ed metadata).
> 
> veth driver is amended to consume this metadata when converting to skb.
> 
> Internally, XDP_FLAGS_HAS_SKB_METADATA flag is used to indicate
> whether the frame has skb metadata. The metadata is currently
> stored prior to xdp->data_meta. bpf_xdp_adjust_meta refuses
> to work after a call to bpf_xdp_metadata_export_to_skb (can lift
> this requirement later on if needed, we'd have to memmove
> xdp_skb_metadata).

IMO we should split the xdp -> skb work from the pure HW data access 
in XDP. We have a proof point here that there is a way of building 
on top of the first 5 patches to achieve the objective, and that's
sufficient to let the prior work going in.

..because some of us may not agree that we should be pushing in a
fixed-format structure that's also listed in uAPI. And prefer to,
say, let the user define their format and add a call point for a
BPF prog to populate the skb from whatever data they decided to stash...

That's how I interpreted some of John's comments as well, but I may be
wrong.

Either way, there is no technical reason for the xdp -> skb field
propagation to hold up the HW descriptor access, right? If anything 
we may be able to make quicker progress if prior work is in tree
and multiple people can hack...