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: Wed, 23 Sep 2020 23:53:57 +0000	[thread overview]
Message-ID: <540DD049-B544-4967-8300-E743940FD6FC@fb.com> (raw)
In-Reply-To: <CAEf4BzZ-qPNjDEvviJKHfLD7t7YJ97PdGixGQ_f70AJEg5oVEg@mail.gmail.com>



> 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?

Thanks,
Song


> BTW, it's also probably overdue to have a higher-level
> bpf_program__test_run(), which can re-use the same
> bpf_prog_test_run_opts options struct. It would be more convenient to
> use it with libbpf bpf_object/bpf_program APIs.
> 
>> {
>>        union bpf_attr attr;
>>        int ret;
>> @@ -693,6 +694,11 @@ int bpf_prog_test_run_xattr(struct bpf_prog_test_run_attr *test_attr)
>>                return -EINVAL;
>> 
>>        memset(&attr, 0, sizeof(attr));
>> +       if (opts) {
> 
> you don't need to check opts for being not NULL, OPTS_VALID handle that already.
> 
>> +               if (!OPTS_VALID(opts, bpf_prog_test_run_opts))
>> +                       return -EINVAL;
>> +               attr.test.cpu_plus = opts->cpu_plus;
> 
> And here you should use OPTS_GET(), please see other examples in
> libbpf for proper usage.
> 
> 
>> +       }
>>        attr.test.prog_fd = test_attr->prog_fd;
>>        attr.test.data_in = ptr_to_u64(test_attr->data_in);
>>        attr.test.data_out = ptr_to_u64(test_attr->data_out);
>> @@ -712,6 +718,11 @@ int bpf_prog_test_run_xattr(struct bpf_prog_test_run_attr *test_attr)
>>        return ret;
>> }
>> 
> 
> [...]


  parent reply	other threads:[~2020-09-23 23:54 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 [this message]
2020-09-24  1:11       ` Andrii Nakryiko
2020-09-24  1:20         ` Song Liu
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=540DD049-B544-4967-8300-E743940FD6FC@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.