From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::]) by mail.toke.dk (Postfix) with ESMTPS id 43F499BE065 for ; Fri, 11 Nov 2022 00:58:30 +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=IIbeSYgL Message-ID: <74eb911b-9c23-1987-fa25-6381b1f130c6@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1668124708; 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=TafO0ZmXjcFX0Eee4EPBfJ97gtbawCv8zaw6b8H+fkI=; b=IIbeSYgLRbHfc/x9J8VtQb79DJ50BrW/4nKjuKdO3uBExd2N+mjEZ9sCzbluZ1RIntpYd7 RuBBuNGrjj/8sKUCQY2Nh3ejxxspvbkbl+/iPGF8QlswUzMxgXFoD80aI0h4GbVKJFa8AU vG9TktVACFiDYK+GeNJ3eS+o2CAUM1I= Date: Thu, 10 Nov 2022 15:58:22 -0800 MIME-Version: 1.0 Content-Language: en-US To: Stanislav Fomichev , =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-7-sdf@google.com> <187e89c3-d7de-7bec-c72e-d9d6eb5bcca0@linux.dev> <9a8fefe4-2fcb-95b7-cda0-06509feee78e@linux.dev> <6f57370f-7ec3-07dd-54df-04423cab6d1f@linux.dev> <87leokz8lq.fsf@toke.dk> <5a23b856-88a3-a57a-2191-b673f4160796@linux.dev> <32f81955-8296-6b9a-834a-5184c69d3aac@linux.dev> <87y1siyjf6.fsf@toke.dk> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Message-ID-Hash: MWE7G76UDRY4IES7CCZM6SGSDOPVVWO3 X-Message-ID-Hash: MWE7G76UDRY4IES7CCZM6SGSDOPVVWO3 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: 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 , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, bpf@vger.kernel.org X-Mailman-Version: 3.3.6 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v2 06/14] 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/10/22 10:52 AM, Stanislav Fomichev wrote: >>> Oh, that seems even better than returning it from >>> bpf_xdp_metadata_export_to_skb. >>> bpf_xdp_metadata_export_to_skb can return true/false and the rest goes >>> via default verifier ctx resolution mechanism.. >>> (returning ptr from a kfunc seems to be a bit complicated right now) What is the complication in returning ptr from a kfunc? I want to see if it can be solved because it will be an easier API to use instead of calling another kfunc to get the ptr. >> See my response to John in the other thread about mixing stable UAPI (in >> xdp_md) and unstable BTF structures in the xdp_md struct: I think this >> is confusing and would prefer a kfunc. hmm... right, it will be one of the first considering the current __bpf_md_ptr() usages are only exposing another struct in uapi, eg. __bpf_md_ptr(struct bpf_sock *, sk). A kfunc will also be fine.