All of lore.kernel.org
 help / color / mirror / Atom feed
From: Song Liu <songliubraving@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	"Kernel Team" <Kernel-team@fb.com>,
	Alexei Starovoitov <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	john fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>
Subject: Re: [PATCH v2 bpf-next 2/3] libbpf: introduce bpf_prog_test_run_xattr_opts
Date: Thu, 24 Sep 2020 01:20:56 +0000	[thread overview]
Message-ID: <DD0ABBCE-A24E-4058-B79F-62EEDE558A15@fb.com> (raw)
In-Reply-To: <CAEf4BzYDsBMmBBtgauqdR9HYDeRG-GbMMTG6FUDbpWgOuU_Ljg@mail.gmail.com>



> On Sep 23, 2020, at 6:11 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> 
> On Wed, Sep 23, 2020 at 4:54 PM Song Liu <songliubraving@fb.com> wrote:
>> 
>> 
>> 
>>> On Sep 23, 2020, at 12:31 PM, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>>> 
>>> On Wed, Sep 23, 2020 at 9:55 AM Song Liu <songliubraving@fb.com> wrote:
>>>> 
>>>> This API supports new field cpu_plus in bpf_attr.test.
>>>> 
>>>> Acked-by: John Fastabend <john.fastabend@gmail.com>
>>>> Signed-off-by: Song Liu <songliubraving@fb.com>
>>>> ---
>>>> tools/lib/bpf/bpf.c      | 13 ++++++++++++-
>>>> tools/lib/bpf/bpf.h      | 11 +++++++++++
>>>> tools/lib/bpf/libbpf.map |  1 +
>>>> 3 files changed, 24 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>>>> index 2baa1308737c8..3228dd60fa32f 100644
>>>> --- a/tools/lib/bpf/bpf.c
>>>> +++ b/tools/lib/bpf/bpf.c
>>>> @@ -684,7 +684,8 @@ int bpf_prog_test_run(int prog_fd, int repeat, void *data, __u32 size,
>>>>       return ret;
>>>> }
>>>> 
>>>> -int bpf_prog_test_run_xattr(struct bpf_prog_test_run_attr *test_attr)
>>>> +int bpf_prog_test_run_xattr_opts(struct bpf_prog_test_run_attr *test_attr,
>>>> +                                const struct bpf_prog_test_run_opts *opts)
>>> 
>>> opts are replacement for test_attr, not an addition to it. We chose to
>>> use _xattr suffix for low-level APIs previously, but it's already
>>> "taken". So I'd suggest to go with just  bpf_prog_test_run_ops and
>>> have prog_fd as a first argument and then put all the rest of
>>> test_run_attr into opts.
>> 
>> One question on this: from the code, most (if not all) of these xxx_opts
>> are used as input only. For example:
>> 
>> LIBBPF_API int bpf_prog_bind_map(int prog_fd, int map_fd,
>>                                 const struct bpf_prog_bind_opts *opts);
>> 
>> However, bpf_prog_test_run_attr contains both input and output. Do you
>> have any concern we use bpf_prog_test_run_opts for both input and output?
>> 
> 
> I think it should be ok. opts are about passing optional things in a
> way that would be backward/forward compatible. Whether it's input
> only, output only, or input/output is secondary. We haven't had a need
> for output params yet, so this will be the first, but I think it fits
> here just fine. Just document it in the struct definition clearly and
> that's it. As for the mechanics, we might want to do OPTS_SET() macro,
> that will set some fields only if the user provided enough memory to
> fir that output parameter. That should work here pretty cleanly,
> right?

Yep, just sent v4 with OPTS_SET(). ;)

Thanks,
Song


  reply	other threads:[~2020-09-24  1:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 16:53 [PATCH v2 bpf-next 0/3] enable BPF_PROG_TEST_RUN for raw_tp Song Liu
2020-09-23 16:53 ` [PATCH v2 bpf-next 1/3] bpf: enable BPF_PROG_TEST_RUN for raw_tracepoint Song Liu
2020-09-23 19:36   ` Andrii Nakryiko
2020-09-23 21:59     ` Song Liu
2020-09-23 16:54 ` [PATCH v2 bpf-next 2/3] libbpf: introduce bpf_prog_test_run_xattr_opts Song Liu
2020-09-23 19:31   ` Andrii Nakryiko
2020-09-23 22:04     ` Song Liu
2020-09-23 23:53     ` Song Liu
2020-09-24  1:11       ` Andrii Nakryiko
2020-09-24  1:20         ` Song Liu [this message]
2020-09-23 16:54 ` [PATCH v2 bpf-next 3/3] selftests/bpf: add raw_tp_test_run Song Liu
2020-09-23 19:40   ` Andrii Nakryiko
2020-09-23 21:30     ` Song Liu

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=DD0ABBCE-A24E-4058-B79F-62EEDE558A15@fb.com \
    --to=songliubraving@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=kpsingh@chromium.org \
    --cc=netdev@vger.kernel.org \
    /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.