On Thu, Jun 20, 2019 at 2:28 AM Lorenz Bauer wrote:
>
> On Mon, 17 Jun 2019 at 22:00, Andrii Nakryiko
> wrote:
> > > In my mind, BPF loaders should be able to pass through BTF to the kernel
> > > as a binary blob as much as possible. That's why I want the format to
> > > be "self describing". Co
On Mon, 17 Jun 2019 at 22:00, Andrii Nakryiko wrote:
> > In my mind, BPF loaders should be able to pass through BTF to the kernel
> > as a binary blob as much as possible. That's why I want the format to
> > be "self describing". Compatibility then becomes a question of: what
> > feature are you u
On Mon, Jun 17, 2019 at 2:07 AM Lorenz Bauer wrote:
>
> On Thu, 6 Jun 2019 at 23:35, Andrii Nakryiko
> wrote:
> >
> > On Thu, Jun 6, 2019 at 9:43 AM Lorenz Bauer wrote:
> > >
> > > Thanks for sending this RFC! For me, the biggest draw is that map-in-map
> > > would be so much nicer to use, plus
On Thu, 6 Jun 2019 at 23:35, Andrii Nakryiko wrote:
>
> On Thu, Jun 6, 2019 at 9:43 AM Lorenz Bauer wrote:
> >
> > Thanks for sending this RFC! For me, the biggest draw is that map-in-map
> > would be so much nicer to use, plus automatic dumping of map values.
> >
> > Others on the thread have ra
This patch adds support for a new way to define BPF maps. It relies on
BTF to describe mandatory and optional attributes of a map, as well as
captures type information of key and value naturally. This eliminates
the need for BPF_ANNOTATE_KV_PAIR hack and ensures key/value sizes are
always in sync w
On Sun, Jun 9, 2019 at 6:17 PM Alexei Starovoitov wrote:
>
> On 6/6/19 6:02 PM, Jakub Kicinski wrote:
> > On Fri, 7 Jun 2019 00:27:52 +, Alexei Starovoitov wrote:
> >> the solution we're discussing should solve BPF_ANNOTATE_KV_PAIR too.
> >> That hack must go.
> >
> > I see.
> >
> >> If I unde
On Mon, 10 Jun 2019 01:17:13 +, Alexei Starovoitov wrote:
> On 6/6/19 6:02 PM, Jakub Kicinski wrote:
> > On Fri, 7 Jun 2019 00:27:52 +, Alexei Starovoitov wrote:
> >> the solution we're discussing should solve BPF_ANNOTATE_KV_PAIR too.
> >> That hack must go.
> >
> > I see.
> >
> >>
On 6/6/19 6:02 PM, Jakub Kicinski wrote:
> On Fri, 7 Jun 2019 00:27:52 +, Alexei Starovoitov wrote:
>> the solution we're discussing should solve BPF_ANNOTATE_KV_PAIR too.
>> That hack must go.
>
> I see.
>
>> If I understood your objections to Andrii's format is that
>> you don't like pointe
On Fri, 7 Jun 2019 00:27:52 +, Alexei Starovoitov wrote:
> the solution we're discussing should solve BPF_ANNOTATE_KV_PAIR too.
> That hack must go.
I see.
> If I understood your objections to Andrii's format is that
> you don't like pointer part of key/value while Andrii explained
> why we p
On 6/6/19 5:10 PM, Jakub Kicinski wrote:
> On Thu, 6 Jun 2019 23:27:36 +, Alexei Starovoitov wrote:
>> On 6/6/19 4:02 PM, Andrii Nakryiko wrote:
struct {
int type;
int max_entries;
} my_map __attribute__((map(int,struct my_value))) = {
.typ
On Thu, 6 Jun 2019 23:27:36 +, Alexei Starovoitov wrote:
> On 6/6/19 4:02 PM, Andrii Nakryiko wrote:
> >> struct {
> >> int type;
> >> int max_entries;
> >> } my_map __attribute__((map(int,struct my_value))) = {
> >> .type = BPF_MAP_TYPE_ARRAY,
> >> .max_entr
On 6/6/19 4:02 PM, Andrii Nakryiko wrote:
>> struct {
>> int type;
>> int max_entries;
>> } my_map __attribute__((map(int,struct my_value))) = {
>> .type = BPF_MAP_TYPE_ARRAY,
>> .max_entries = 16,
>> };
>>
>> Of course this would need BPF backend support, but at
On Thu, Jun 6, 2019 at 2:09 PM Daniel Borkmann wrote:
>
> On 06/04/2019 07:31 PM, Andrii Nakryiko wrote:
> > On Tue, Jun 4, 2019 at 6:45 AM Stanislav Fomichev wrote:
> >> On 06/03, Stanislav Fomichev wrote:
> BTF is mandatory for _any_ new feature.
> >>> If something is easy to support witho
On Thu, Jun 6, 2019 at 9:43 AM Lorenz Bauer wrote:
>
> Thanks for sending this RFC! For me, the biggest draw is that map-in-map
> would be so much nicer to use, plus automatic dumping of map values.
>
> Others on the thread have raised this point already: not everybody lives
> on the bleeding edge
On 06/04/2019 07:31 PM, Andrii Nakryiko wrote:
> On Tue, Jun 4, 2019 at 6:45 AM Stanislav Fomichev wrote:
>> On 06/03, Stanislav Fomichev wrote:
BTF is mandatory for _any_ new feature.
>>> If something is easy to support without asking everyone to upgrade to
>>> a bleeding edge llvm, why not
Thanks for sending this RFC! For me, the biggest draw is that map-in-map
would be so much nicer to use, plus automatic dumping of map values.
Others on the thread have raised this point already: not everybody lives
on the bleeding edge or can control all of their dependencies. To me this means
tha
On Tue, Jun 4, 2019 at 2:07 PM Stanislav Fomichev wrote:
>
> On 06/04, Andrii Nakryiko wrote:
> > On Tue, Jun 4, 2019 at 6:45 AM Stanislav Fomichev wrote:
> > >
> > > On 06/03, Stanislav Fomichev wrote:
> > > > > BTF is mandatory for _any_ new feature.
> > > > If something is easy to support with
On 06/04, Andrii Nakryiko wrote:
> On Tue, Jun 4, 2019 at 6:45 AM Stanislav Fomichev wrote:
> >
> > On 06/03, Stanislav Fomichev wrote:
> > > > BTF is mandatory for _any_ new feature.
> > > If something is easy to support without asking everyone to upgrade to
> > > a bleeding edge llvm, why not do
On Tue, Jun 4, 2019 at 6:45 AM Stanislav Fomichev wrote:
>
> On 06/03, Stanislav Fomichev wrote:
> > > BTF is mandatory for _any_ new feature.
> > If something is easy to support without asking everyone to upgrade to
> > a bleeding edge llvm, why not do it?
> > So much for backwards compatibility
On 06/03, Stanislav Fomichev wrote:
> > BTF is mandatory for _any_ new feature.
> If something is easy to support without asking everyone to upgrade to
> a bleeding edge llvm, why not do it?
> So much for backwards compatibility and flexibility.
>
> > It's for introspection and debuggability in th
> BTF is mandatory for _any_ new feature.
If something is easy to support without asking everyone to upgrade to
a bleeding edge llvm, why not do it?
So much for backwards compatibility and flexibility.
> It's for introspection and debuggability in the first place.
> Good debugging is not optional.
On 6/3/19 6:02 PM, Stanislav Fomichev wrote:
> Do we want to lock everyone out of new libbpf features?
BTF is mandatory for _any_ new feature.
It's for introspection and debuggability in the first place.
Good debugging is not optional.
On 06/03, Andrii Nakryiko wrote:
> On Mon, Jun 3, 2019 at 9:32 AM Stanislav Fomichev wrote:
> >
> > On 05/31, Andrii Nakryiko wrote:
> > > On Fri, May 31, 2019 at 2:28 PM Stanislav Fomichev
> > > wrote:
> > > >
> > > > On 05/31, Andrii Nakryiko wrote:
> > > > > This patch adds support for a new
On Mon, 3 Jun 2019 14:54:53 -0700, Andrii Nakryiko wrote:
> On Sun, Jun 2, 2019 at 5:33 PM Jakub Kicinski wrote:
> > On Fri, 31 May 2019 15:58:41 -0700, Andrii Nakryiko wrote:
> > > On Fri, May 31, 2019 at 2:28 PM Stanislav Fomichev
> > > wrote:
> > > > On 05/31, Andrii Nakryiko wrote:
> >
On Fri, May 31, 2019 at 1:21 PM Andrii Nakryiko wrote:
>
> This patch adds support for a new way to define BPF maps. It relies on
> BTF to describe mandatory and optional attributes of a map, as well as
> captures type information of key and value naturally. This eliminates
> the need for BPF_ANNO
On Mon, Jun 3, 2019 at 9:32 AM Stanislav Fomichev wrote:
>
> On 05/31, Andrii Nakryiko wrote:
> > On Fri, May 31, 2019 at 2:28 PM Stanislav Fomichev wrote:
> > >
> > > On 05/31, Andrii Nakryiko wrote:
> > > > This patch adds support for a new way to define BPF maps. It relies on
> > > > BTF to de
On Sun, Jun 2, 2019 at 5:33 PM Jakub Kicinski
wrote:
>
> On Fri, 31 May 2019 15:58:41 -0700, Andrii Nakryiko wrote:
> > On Fri, May 31, 2019 at 2:28 PM Stanislav Fomichev wrote:
> > > On 05/31, Andrii Nakryiko wrote:
> > > > This patch adds support for a new way to define BPF maps. It relies on
>
On 05/31, Andrii Nakryiko wrote:
> On Fri, May 31, 2019 at 2:28 PM Stanislav Fomichev wrote:
> >
> > On 05/31, Andrii Nakryiko wrote:
> > > This patch adds support for a new way to define BPF maps. It relies on
> > > BTF to describe mandatory and optional attributes of a map, as well as
> > > capt
On Fri, 31 May 2019 15:58:41 -0700, Andrii Nakryiko wrote:
> On Fri, May 31, 2019 at 2:28 PM Stanislav Fomichev wrote:
> > On 05/31, Andrii Nakryiko wrote:
> > > This patch adds support for a new way to define BPF maps. It relies on
> > > BTF to describe mandatory and optional attributes of a ma
On Fri, May 31, 2019 at 2:28 PM Stanislav Fomichev wrote:
>
> On 05/31, Andrii Nakryiko wrote:
> > This patch adds support for a new way to define BPF maps. It relies on
> > BTF to describe mandatory and optional attributes of a map, as well as
> > captures type information of key and value natura
On 05/31, Andrii Nakryiko wrote:
> This patch adds support for a new way to define BPF maps. It relies on
> BTF to describe mandatory and optional attributes of a map, as well as
> captures type information of key and value naturally. This eliminates
> the need for BPF_ANNOTATE_KV_PAIR hack and ens
This patch adds support for a new way to define BPF maps. It relies on
BTF to describe mandatory and optional attributes of a map, as well as
captures type information of key and value naturally. This eliminates
the need for BPF_ANNOTATE_KV_PAIR hack and ensures key/value sizes are
always in sync w
32 matches
Mail list logo
