From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by mail.toke.dk (Postfix) with ESMTPS id A7D1A9BE28E for ; Fri, 11 Nov 2022 01:20:30 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=s2k1nLr5 Received: by mail-il1-x12c.google.com with SMTP id e19so1873308ili.4 for ; Thu, 10 Nov 2022 16:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jS+5YemzmhyT8sEWWf1R305iTxH7ZVLfWmWJu/iLS10=; b=s2k1nLr5gewWd1RFs5B2HWkmrF8ed7ugavDGh7RqH6V+XM4HtU+/iumzakWrTUz10y LnmWTO4giw8npL9TJ2P5PrH1o+gBFC3yw721PEJ3htirXFFG4AtaBRvcjdSsyRijwTzn jyde6+zhI5dLFY0RFLSh1+l8Khezct+ZBF4Rv5LlRmINFZjc3+tbsigKME691/cocqx+ qdNWeB05DV2XKMHgLbTlxjuECiJjsrm+q7yrMwuj5nERtYJkkDsmLg7Bg4xWSIYnxoVP L8viwrEtIZiS9gj1hwC+kPPQ5xBOTGHtjg/68ai4SJvL+29nWM+qvYiyo3z0oKdYuDMK mDcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jS+5YemzmhyT8sEWWf1R305iTxH7ZVLfWmWJu/iLS10=; b=V+xKUWqVVBSE5+Yn/lzgMH5etlzU2TZxGb3DE7mssr/ghW+mZBopLWmn47kFsyQ/YL /X1vmgvKnQSQZE+q1gMdYjAfT6yivZ2FoqCBQ0NHyMVj14tWOtdIXvFl+Pel0Pic9iXw KqEgcSE5NnCayUDxZfB/59c+hhFQ6FNY1H4hLWdX6BAb0nfK0Mdg+1aIFUPo5E7Szdcz hoWxbfzsCea4oc4DByRnn39RJmhzeJyyfW50baD2bSE4NGt45RRYUgnJPS42oQANkLrU oT3QOeq+yY+HggOsBUzYu4JowPUTtUjcRq+zd+IQqKPPciK4mK46JYCm2LB8HENGh5DB iP2w== X-Gm-Message-State: ANoB5plXqsJPftzOI1lLMj4p0JQVX7pcBq2NoJpFuwA/SnnO/pAKG9g6 CmdIFypOyC1ncYk4Ba2mM65U9499TTq9PNBkpZDPyQ== X-Google-Smtp-Source: AA0mqf4esUtV5rJxKkiqO+stth7j24dbDdoFtjIPnNUiVG6OUeqy8z8gmFunxMJm5LP+40HDqm9tTsuGLdYOWIkCYKg= X-Received: by 2002:a92:c5ca:0:b0:302:37bb:ee9f with SMTP id s10-20020a92c5ca000000b0030237bbee9fmr1243389ilt.117.1668126028616; Thu, 10 Nov 2022 16:20:28 -0800 (PST) MIME-Version: 1.0 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> <74eb911b-9c23-1987-fa25-6381b1f130c6@linux.dev> In-Reply-To: <74eb911b-9c23-1987-fa25-6381b1f130c6@linux.dev> From: Stanislav Fomichev Date: Thu, 10 Nov 2022 16:20:17 -0800 Message-ID: To: Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: PMFQEL4WRIPHYQD63ZUHGT24JTC2TPGF X-Message-ID-Hash: PMFQEL4WRIPHYQD63ZUHGT24JTC2TPGF X-MailFrom: sdf@google.com 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: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , 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 Thu, Nov 10, 2022 at 3:58 PM Martin KaFai Lau wrote: > > 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. At least for returning a pointer to the basic c types like int/long, I was hitting the following: commit eb1f7f71c126c8fd50ea81af98f97c4b581ea4ae Author: Benjamin Tissoires AuthorDate: Tue Sep 6 17:13:02 2022 +0200 Commit: Alexei Starovoitov CommitDate: Wed Sep 7 11:05:17 2022 -0700 bpf/verifier: allow kfunc to return an allocated mem Where I had to add an extra "const int rdonly_buf_size" argument to the kfunc to make the verifier happy. But I haven't really looked at what would happen with the pointers to structs (or why, at all, we have this restriction). > >> 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. >