[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6fb25aa-5bfc-cf97-f960-5966154e5ef5@iogearbox.net>
Date: Mon, 11 Mar 2019 21:45:49 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Song Liu <songliubraving@...com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, ast@...nel.org, kernel-team@...com,
peterz@...radead.org, acme@...hat.com, jolsa@...nel.org,
namhyung@...nel.org
Subject: Re: [PATCH v7 perf,bpf 02/15] bpf: libbpf: introduce
bpf_program__get_prog_info_linear()
On 03/11/2019 07:26 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 07, 2019 at 09:57:57AM -0800, Song Liu escreveu:
>> Currently, bpf_prog_info includes 9 arrays. The user has the option to
>> fetch any combination of these arrays. However, this requires a lot of
>> handling of these arrays. This work becomes more tricky when we need to
>> store bpf_prog_info to a file, because these arrays are allocated
>> independently.
>>
>> This patch introduces struct bpf_prog_info_linear, which stores arrays
>> of bpf_prog_info in continues memory. Helper functions are introduced
>> to unify the work to get different information of bpf_prog_info.
>> Specifically, bpf_program__get_prog_info_linear() allows the user to
>> select which arrays to fetch, and handles details for the user.
>>
>> Plesae see the comments before enum bpf_prog_info_array for more details
>> and examples.
>>
>> Cc: Daniel Borkmann <daniel@...earbox.net>
>> Cc: Alexei Starovoitov <ast@...nel.org>
>
> Daniel, are you ok with these changes to libbpf and bpftool? Perhaps
> those should be detached from this patchkit and submitted sooner,
> eroding the size of this kit.
>
> Alternatively, if you're ok with it, please provide your Acked-by and
> I'll process as soon as I get back to it after Jiri is done reviewing.
Overall looks okay. Are you planning to get these in for 5.1 window? If
yes, that would be great, otherwise we might need to cherry-pick the libbpf
and bpftool ones from your tree into bpf-next as well since there's just
too much going on in this area where we'd potentially run into complex
merge conflicts. In the latter case, libbpf.map would need to be fixed up
to LIBBPF_0.0.3 as convention is that this is in line with kernel release.
Thanks,
Daniel
> - Arnaldo
Powered by blists - more mailing lists