[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <540DD049-B544-4967-8300-E743940FD6FC@fb.com>
Date: Wed, 23 Sep 2020 23:53:57 +0000
From: Song Liu <songliubraving@...com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
CC: Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
"Kernel Team" <Kernel-team@...com>,
Alexei Starovoitov <ast@...nel.org>,
"Daniel Borkmann" <daniel@...earbox.net>,
john fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>
Subject: Re: [PATCH v2 bpf-next 2/3] libbpf: introduce
bpf_prog_test_run_xattr_opts
> On Sep 23, 2020, at 12:31 PM, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
>
> On Wed, Sep 23, 2020 at 9:55 AM Song Liu <songliubraving@...com> wrote:
>>
>> This API supports new field cpu_plus in bpf_attr.test.
>>
>> Acked-by: John Fastabend <john.fastabend@...il.com>
>> Signed-off-by: Song Liu <songliubraving@...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;
>> }
>>
>
> [...]
Powered by blists - more mailing lists