From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, bpf <bpf@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Mykola Lysenko <mykolal@fb.com>,
Vadim Fedorenko <vadfed@meta.com>,
"David S. Miller" <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH bpf-next v3 1/2] bpf: add skcipher API support to TC/XDP programs
Date: Thu, 2 Nov 2023 16:14:38 +0000 [thread overview]
Message-ID: <c4e6296d-f273-4b27-a33a-eee5c8f54aab@linux.dev> (raw)
In-Reply-To: <CAADnVQ+9pp33zv9DxouEmg24o7w27OKFUcvKChHuby_+d6-bLg@mail.gmail.com>
On 02/11/2023 15:36, Alexei Starovoitov wrote:
> On Thu, Nov 2, 2023 at 6:44 AM Vadim Fedorenko
> <vadim.fedorenko@linux.dev> wrote:
>>
>> On 01/11/2023 23:41, Martin KaFai Lau wrote:
>>> On 11/1/23 3:50 PM, Vadim Fedorenko wrote:
>>>>>> +static void *__bpf_dynptr_data_ptr(const struct bpf_dynptr_kern *ptr)
>>>>>> +{
>>>>>> + enum bpf_dynptr_type type;
>>>>>> +
>>>>>> + if (!ptr->data)
>>>>>> + return NULL;
>>>>>> +
>>>>>> + type = bpf_dynptr_get_type(ptr);
>>>>>> +
>>>>>> + switch (type) {
>>>>>> + case BPF_DYNPTR_TYPE_LOCAL:
>>>>>> + case BPF_DYNPTR_TYPE_RINGBUF:
>>>>>> + return ptr->data + ptr->offset;
>>>>>> + case BPF_DYNPTR_TYPE_SKB:
>>>>>> + return skb_pointer_if_linear(ptr->data, ptr->offset,
>>>>>> __bpf_dynptr_size(ptr));
>>>>>> + case BPF_DYNPTR_TYPE_XDP:
>>>>>> + {
>>>>>> + void *xdp_ptr = bpf_xdp_pointer(ptr->data, ptr->offset,
>>>>>> __bpf_dynptr_size(ptr));
>>>>>
>>>>> I suspect what it is doing here (for skb and xdp in particular) is
>>>>> very similar to bpf_dynptr_slice. Please check if
>>>>> bpf_dynptr_slice(ptr, 0, NULL, sz) will work.
>>>>>
>>>>
>>>> Well, yes, it's simplified version of bpf_dynptr_slice. The problem is
>>>> that bpf_dynptr_slice bpf_kfunc which cannot be used in another
>>>> bpf_kfunc. Should I refactor the code to use it in both places? Like
>>>
>>> Sorry, scrolled too fast in my earlier reply :(
>>>
>>> I am not aware of this limitation. What error does it have?
>>> The bpf_dynptr_slice_rdwr kfunc() is also calling the bpf_dynptr_slice()
>>> kfunc.
>>>
>>>> create __bpf_dynptr_slice() which will be internal part of bpf_kfunc?
>>
>> Apparently Song has a patch to expose these bpf_dynptr_slice* functions
>> ton in-kernel users.
>>
>> https://lore.kernel.org/bpf/20231024235551.2769174-2-song@kernel.org/
>>
>> Should I wait for it to be merged before sending next version?
>
> If you need something from another developer it's best to ask them
> explicitly :)
> In this case Song can respin with just that change that you need.
Got it. I actually need 2 different changes from the same patchset, I'll
ping Song in the appropriate thread, thanks!
next prev parent reply other threads:[~2023-11-02 16:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 13:48 [PATCH bpf-next v3 1/2] bpf: add skcipher API support to TC/XDP programs Vadim Fedorenko
2023-10-31 13:49 ` [PATCH bpf-next v3 2/2] selftests: bpf: crypto skcipher algo selftests Vadim Fedorenko
2023-11-01 22:53 ` Martin KaFai Lau
2023-11-02 0:54 ` Vadim Fedorenko
2023-10-31 15:46 ` [PATCH bpf-next v3 1/2] bpf: add skcipher API support to TC/XDP programs Jiri Olsa
2023-10-31 15:58 ` Vadim Fedorenko
2023-11-01 21:49 ` Martin KaFai Lau
2023-11-01 22:50 ` Vadim Fedorenko
2023-11-01 22:59 ` Martin KaFai Lau
2023-11-02 0:31 ` Vadim Fedorenko
2023-11-01 23:41 ` Martin KaFai Lau
2023-11-02 0:38 ` Vadim Fedorenko
2023-11-02 13:44 ` Vadim Fedorenko
2023-11-02 15:36 ` Alexei Starovoitov
2023-11-02 16:14 ` Vadim Fedorenko [this message]
2023-11-02 17:47 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4e6296d-f273-4b27-a33a-eee5c8f54aab@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=song@kernel.org \
--cc=vadfed@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.