From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by mail.toke.dk (Postfix) with ESMTPS id E631C9C2D5A for ; Wed, 16 Nov 2022 22:50:11 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=Uj+JvpJs Message-ID: <475cc762-5183-90c8-a347-cc1dfa5c1976@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1668635410; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f8tDS2E/rfOvHtRZr1ZxwOkAC6UWU/9cveBrm7Gnkpk=; b=Uj+JvpJsavOL5EznkcZGdWhZbiIJ3RcMUOR6JnJEuIpngElxbQycQMaofOMJGitG4Wt7wA M8W2sl5ghBa0aE59nSsKcIjZI6heSg4xwQEKQBuUuDx/cCGu2k1gTX+7j5txSpBfdtAubQ E2vu216Ifw7RE7Xl84UDrOKHPQT8W7E= Date: Wed, 16 Nov 2022 13:49:58 -0800 MIME-Version: 1.0 Content-Language: en-US To: Jakub Kicinski References: <20221115030210.3159213-1-sdf@google.com> <20221115030210.3159213-7-sdf@google.com> <20221116131253.6703f1c6@kernel.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: <20221116131253.6703f1c6@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Message-ID-Hash: R4LKUOEV3Z4UGL4ZUDVTD3NJFQWOKSBV X-Message-ID-Hash: R4LKUOEV3Z4UGL4ZUDVTD3NJFQWOKSBV X-MailFrom: martin.lau@linux.dev 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: Stanislav Fomichev , bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, 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 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 Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 11/16/22 1:12 PM, Jakub Kicinski wrote: > 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. +1 Good idea.