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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E34E0C433FE for ; Thu, 10 Nov 2022 23:58:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231235AbiKJX6c (ORCPT ); Thu, 10 Nov 2022 18:58:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231511AbiKJX6b (ORCPT ); Thu, 10 Nov 2022 18:58:31 -0500 Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3A9D6351; Thu, 10 Nov 2022 15:58:30 -0800 (PST) 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 Subject: Re: [xdp-hints] Re: [RFC bpf-next v2 06/14] xdp: Carry over xdp metadata into skb context Content-Language: en-US To: Stanislav Fomichev , =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= 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 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 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org 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.