On 11/12/20 4:20 PM, Daniel Borkmann wrote:
> built-in given it otherwise comes with the base distro already. But then
> my question is what is planned here as deprecation process for the built-in
> lib/bpf.c code? I presume we'll remove it eventually to move on?
It will need to follow the establi
On Thu, Nov 12, 2020 at 4:35 PM Stephen Hemminger
wrote:
>
> On Fri, 13 Nov 2020 00:20:52 +0100
> Daniel Borkmann wrote:
>
> > On 11/12/20 11:36 PM, Toke Høiland-Jørgensen wrote:
> > > Daniel Borkmann writes:
> > >
> > >>> Besides, for the entire history of BPF support in iproute2 so far, the
>
On Fri, 13 Nov 2020 00:20:52 +0100
Daniel Borkmann wrote:
> On 11/12/20 11:36 PM, Toke Høiland-Jørgensen wrote:
> > Daniel Borkmann writes:
> >
> >>> Besides, for the entire history of BPF support in iproute2 so far, the
> >>> benefit has come from all the features that libbpf has just starte
On 11/12/20 11:36 PM, Toke Høiland-Jørgensen wrote:
Daniel Borkmann writes:
Besides, for the entire history of BPF support in iproute2 so far, the
benefit has come from all the features that libbpf has just started
automatically supporting on load (BTF, etc), so users would have
benefited from
Daniel Borkmann writes:
>> Besides, for the entire history of BPF support in iproute2 so far, the
>> benefit has come from all the features that libbpf has just started
>> automatically supporting on load (BTF, etc), so users would have
>> benefited from automatic library updates had it *not* bee
On Wed, Nov 11, 2020 at 11:31:47AM +, Edward Cree wrote:
> On 11/11/2020 00:53, Alexei Starovoitov wrote:
> > On Tue, Nov 10, 2020 at 12:47:28PM +, Edward Cree wrote:
> >> But I think it illustrates why having to
> >> interoperate with systems outside their control and mix-and-match
> >>
On 11/11/20 8:06 AM, Daniel Borkmann wrote:
>
> Not really. What you imply here is that we're living in a perfect world
> and that
> all distros follow suite and i) add libbpf dependency to their official
> iproute2
> package, ii) upgrade iproute2 package along with new kernel releases and
> iii)
On 11/11/20 12:02 PM, Toke Høiland-Jørgensen wrote:
Alexei Starovoitov writes:
On Mon, Nov 09, 2020 at 09:09:44PM -0700, David Ahern wrote:
On 11/8/20 6:45 PM, Alexei Starovoitov wrote:
I don't understand why on one side you're pointing out existing quirkiness with
bpf usability while at the
On 11/11/2020 00:53, Alexei Starovoitov wrote:
> On Tue, Nov 10, 2020 at 12:47:28PM +, Edward Cree wrote:
>> But I think it illustrates why having to
>> interoperate with systems outside their control and mix-and-match
>> versioning of various components provides external discipline that
>>
Alexei Starovoitov writes:
> On Mon, Nov 09, 2020 at 09:09:44PM -0700, David Ahern wrote:
>> On 11/8/20 6:45 PM, Alexei Starovoitov wrote:
>> >
>> > I don't understand why on one side you're pointing out existing quirkiness
>> > with
>> > bpf usability while at the same time arguing to make it
On Tue, Nov 10, 2020 at 12:47:28PM +, Edward Cree wrote:
> On 05/11/2020 14:05, Jamal Hadi Salim wrote:
> > On 2020-11-04 10:19 p.m., David Ahern wrote:
> >
> > [..]
> >> Similarly, it is not realistic or user friendly to *require* general
> >> Linux users to constantly chase latest versions of
On Mon, Nov 09, 2020 at 09:09:44PM -0700, David Ahern wrote:
> On 11/8/20 6:45 PM, Alexei Starovoitov wrote:
> >
> > I don't understand why on one side you're pointing out existing quirkiness
> > with
> > bpf usability while at the same time arguing to make it _less_ user friendly
>
> I believe
On 05/11/2020 14:05, Jamal Hadi Salim wrote:
> On 2020-11-04 10:19 p.m., David Ahern wrote:
>
> [..]
>> Similarly, it is not realistic or user friendly to *require* general
>> Linux users to constantly chase latest versions of llvm, clang, dwarves,
>> bcc, bpftool, libbpf, (I am sure I am missing m
On 11/8/20 6:45 PM, Alexei Starovoitov wrote:
>
> I don't understand why on one side you're pointing out existing quirkiness
> with
> bpf usability while at the same time arguing to make it _less_ user friendly
I believe you have confused my comments with others. My comments have
focused on one
On Fri, Nov 06, 2020 at 04:38:13PM -0700, David Ahern wrote:
> On 11/6/20 4:25 PM, Stephen Hemminger wrote:
> >>
> >> I think bumping the minimal version of libbpf with every iproute2 release
> >> is necessary as well.
> >> Today iproute2-next should require 0.2.0. The cycle after it should be
> >
On Fri, Nov 6, 2020 at 4:41 PM Stephen Hemminger
wrote:
>
> On Fri, 6 Nov 2020 15:30:38 -0800
> Andrii Nakryiko wrote:
>
> > On Fri, Nov 6, 2020 at 3:25 PM Stephen Hemminger
> > wrote:
> > >
> > > On Fri, 6 Nov 2020 13:04:16 -0800
> > > Alexei Starovoitov wrote:
> > >
> > > > On Fri, Nov 6, 202
On Fri, 6 Nov 2020 15:30:38 -0800
Andrii Nakryiko wrote:
> On Fri, Nov 6, 2020 at 3:25 PM Stephen Hemminger
> wrote:
> >
> > On Fri, 6 Nov 2020 13:04:16 -0800
> > Alexei Starovoitov wrote:
> >
> > > On Fri, Nov 6, 2020 at 12:58 PM Andrii Nakryiko
> > > wrote:
> > > >
> > > > On Fri, Nov 6,
On 11/6/20 4:25 PM, Stephen Hemminger wrote:
>>
>> I think bumping the minimal version of libbpf with every iproute2 release
>> is necessary as well.
>> Today iproute2-next should require 0.2.0. The cycle after it should be 0.3.0
>> and so on.
>> This way at least some correlation between iproute2
On Fri, Nov 6, 2020 at 3:25 PM Stephen Hemminger
wrote:
>
> On Fri, 6 Nov 2020 13:04:16 -0800
> Alexei Starovoitov wrote:
>
> > On Fri, Nov 6, 2020 at 12:58 PM Andrii Nakryiko
> > wrote:
> > >
> > > On Fri, Nov 6, 2020 at 12:44 AM Jiri Benc wrote:
> > > >
> > > > On Thu, 5 Nov 2020 12:19:00 -08
On Fri, 6 Nov 2020 13:04:16 -0800
Alexei Starovoitov wrote:
> On Fri, Nov 6, 2020 at 12:58 PM Andrii Nakryiko
> wrote:
> >
> > On Fri, Nov 6, 2020 at 12:44 AM Jiri Benc wrote:
> > >
> > > On Thu, 5 Nov 2020 12:19:00 -0800, Andrii Nakryiko wrote:
> > > > I'll just quote myself here for your
On Fri, Nov 6, 2020 at 7:27 AM Jamal Hadi Salim wrote:
>
> On 2020-11-05 4:01 p.m., Andrii Nakryiko wrote:
> > On Thu, Nov 5, 2020 at 6:05 AM Jamal Hadi Salim wrote:
> >>
> >> On 2020-11-04 10:19 p.m., David Ahern wrote:
> >>
> >> [..]
>
> [..]
>
> >> 2cents feedback from a dabbler in ebpf on use
On Fri, Nov 6, 2020 at 1:00 AM Jiri Benc wrote:
>
> On Thu, 5 Nov 2020 12:45:39 -0800, Andrii Nakryiko wrote:
> > That's not true. If you need new functionality like BTF, CO-RE,
> > function-by-function verification, etc., then yes, you have to update
> > kernel, compiler, libbpf, sometimes pahole
On Fri, Nov 6, 2020 at 12:58 PM Andrii Nakryiko
wrote:
>
> On Fri, Nov 6, 2020 at 12:44 AM Jiri Benc wrote:
> >
> > On Thu, 5 Nov 2020 12:19:00 -0800, Andrii Nakryiko wrote:
> > > I'll just quote myself here for your convenience.
> >
> > Sorry, I missed your original email for some reason.
> >
>
On Fri, Nov 6, 2020 at 12:44 AM Jiri Benc wrote:
>
> On Thu, 5 Nov 2020 12:19:00 -0800, Andrii Nakryiko wrote:
> > I'll just quote myself here for your convenience.
>
> Sorry, I missed your original email for some reason.
>
> > Submodule is a way that I know of to make this better for end users.
On 2020-11-05 4:01 p.m., Andrii Nakryiko wrote:
On Thu, Nov 5, 2020 at 6:05 AM Jamal Hadi Salim wrote:
On 2020-11-04 10:19 p.m., David Ahern wrote:
[..]
[..]
2cents feedback from a dabbler in ebpf on user experience:
What David described above *has held me back*.
Over time it seems thing
On Thu, 5 Nov 2020 12:45:39 -0800, Andrii Nakryiko wrote:
> That's not true. If you need new functionality like BTF, CO-RE,
> function-by-function verification, etc., then yes, you have to update
> kernel, compiler, libbpf, sometimes pahole. But if you have an BPF
> application that doesn't use and
On Thu, 5 Nov 2020 12:19:00 -0800, Andrii Nakryiko wrote:
> I'll just quote myself here for your convenience.
Sorry, I missed your original email for some reason.
> Submodule is a way that I know of to make this better for end users.
> If there are other ways to pull this off with shared libr
On Thu, Nov 5, 2020 at 6:05 AM Jamal Hadi Salim wrote:
>
> On 2020-11-04 10:19 p.m., David Ahern wrote:
>
> [..]
> >
> > User experience keeps getting brought up, but I also keep reading the
> > stance that BPF users can not expect a consistent experience unless they
> > are constantly chasing lat
On Wed, Nov 4, 2020 at 7:48 PM David Ahern wrote:
>
> On 11/4/20 1:43 PM, Andrii Nakryiko wrote:
> >
> > What users writing BPF programs can expect from iproute2 in terms of
> > available BPF features is what matters. And by not enforcing a
> > specific minimal libbpf version, iproute2 version doe
On Wed, Nov 4, 2020 at 7:19 PM David Ahern wrote:
>
> On 11/4/20 3:21 AM, Daniel Borkmann wrote:
> >
> >> Then libbpf release process can incorporate proper testing of libbpf
> >> and iproute2 combination.
> >> Or iproute2 should stay as-is with obsolete bpf support.
> >>
> >> Few years from now t
On Wed, Nov 4, 2020 at 3:05 PM Edward Cree wrote:
>
> On 04/11/2020 22:10, Alexei Starovoitov wrote:
> > On Wed, Nov 4, 2020 at 1:16 PM Edward Cree wrote:
> >> On 04/11/2020 03:11, Alexei Starovoitov wrote:
> >>> The user will do 'tc -V'. Does version mean anything from bpf loading pov?
> >>> It'
On Wed, Nov 4, 2020 at 2:24 PM Toke Høiland-Jørgensen wrote:
>
> Andrii Nakryiko writes:
>
> > Some of the most important APIs of libbpf are, arguably,
> > bpf_object__open() and bpf_object__load(). They accept a BPF ELF file,
> > do some preprocessing and in the end load BPF instructions into th
On 2020-11-04 10:19 p.m., David Ahern wrote:
[..]
User experience keeps getting brought up, but I also keep reading the
stance that BPF users can not expect a consistent experience unless they
are constantly chasing latest greatest versions of *ALL* S/W related to
BPF. That is not a realistic e
On 11/4/20 1:43 PM, Andrii Nakryiko wrote:
>
> What users writing BPF programs can expect from iproute2 in terms of
> available BPF features is what matters. And by not enforcing a
> specific minimal libbpf version, iproute2 version doesn't matter all
> that much, because libbpf version that iprou
On 11/4/20 3:21 AM, Daniel Borkmann wrote:
>
>> Then libbpf release process can incorporate proper testing of libbpf
>> and iproute2 combination.
>> Or iproute2 should stay as-is with obsolete bpf support.
>>
>> Few years from now the situation could be different and shared libbpf
>> would
>> be t
On 11/4/20 2:28 AM, Jiri Benc wrote:
> On Tue, 3 Nov 2020 18:45:59 -0800, Alexei Starovoitov wrote:
>> libbpf is the only library I know that is backward and forward compatible.
>
> This is great to hear. It means there will be no problem with iproute2
> using the system libbpf. As libbpf is both
On 04/11/2020 22:10, Alexei Starovoitov wrote:
> On Wed, Nov 4, 2020 at 1:16 PM Edward Cree wrote:
>> On 04/11/2020 03:11, Alexei Starovoitov wrote:
>>> The user will do 'tc -V'. Does version mean anything from bpf loading pov?
>>> It's not. The user will do "ldd `which tc`" and then what?
>> Is i
Alexei Starovoitov writes:
> On Wed, Nov 4, 2020 at 1:16 PM Edward Cree wrote:
>>
>> On 04/11/2020 03:11, Alexei Starovoitov wrote:
>> > The user will do 'tc -V'. Does version mean anything from bpf loading pov?
>> > It's not. The user will do "ldd `which tc`" and then what?
>> Is it beyond the
Andrii Nakryiko writes:
> Some of the most important APIs of libbpf are, arguably,
> bpf_object__open() and bpf_object__load(). They accept a BPF ELF file,
> do some preprocessing and in the end load BPF instructions into the
> kernel for verification. But while API doesn't change across libbpf
>
On Wed, Nov 4, 2020 at 1:16 PM Edward Cree wrote:
>
> On 04/11/2020 03:11, Alexei Starovoitov wrote:
> > The user will do 'tc -V'. Does version mean anything from bpf loading pov?
> > It's not. The user will do "ldd `which tc`" and then what?
> Is it beyond the wit of man for 'tc -V' to output som
On 04/11/2020 03:11, Alexei Starovoitov wrote:
> The user will do 'tc -V'. Does version mean anything from bpf loading pov?
> It's not. The user will do "ldd `which tc`" and then what?
Is it beyond the wit of man for 'tc -V' to output somethingabout
libbpf version?
Other libraries seem to solve th
On Wed, Nov 4, 2020 at 11:17 AM Jakub Kicinski wrote:
>
> On Wed, 4 Nov 2020 14:12:47 +0100 Daniel Borkmann wrote:
> > If we would have done lib/bpf.c as a dynamic library back then, we wouldn't
> > be
> > where we are today since users might be able to start consuming BPF
> > functionality
> >
On Wed, 4 Nov 2020 14:12:47 +0100 Daniel Borkmann wrote:
> If we would have done lib/bpf.c as a dynamic library back then, we wouldn't be
> where we are today since users might be able to start consuming BPF
> functionality
> just now, don't you agree? This was an explicit design choice back then
On 11/4/20 12:20 PM, Toke Høiland-Jørgensen wrote:
Daniel Borkmann writes:
Back in the days when developing lib/bpf.c, it was explicitly done as
built-in for iproute2 so that it doesn't take years for users to
actually get to the point where they can realistically make use of it.
If we were to
Daniel Borkmann writes:
> Back in the days when developing lib/bpf.c, it was explicitly done as
> built-in for iproute2 so that it doesn't take years for users to
> actually get to the point where they can realistically make use of it.
> If we were to extend the internal lib/bpf.c to similar feat
On 11/4/20 4:11 AM, Alexei Starovoitov wrote:
On Wed, Nov 04, 2020 at 10:17:30AM +0800, Hangbin Liu wrote:
On Tue, Nov 03, 2020 at 02:55:54PM -0800, Alexei Starovoitov wrote:
The scope of bpf in iproute2 is tiny - a few tc modules (and VRF but it
does not need libbpf) which is a small subset of
On Tue, 3 Nov 2020 19:11:45 -0800, Alexei Starovoitov wrote:
> When we release new version of libbpf it goes through rigorous testing.
> bpftool gets a lot of test coverage as well.
> iproute2 with shared libbpf will get nothing. It's the same random roll of
> dice.
"Random roll of dice" would be
On Tue, 3 Nov 2020 18:45:59 -0800, Alexei Starovoitov wrote:
> libbpf is the only library I know that is backward and forward compatible.
This is great to hear. It means there will be no problem with iproute2
using the system libbpf. As libbpf is both backward and forward
compatible, iproute2 will
On Wed, Nov 04, 2020 at 10:17:30AM +0800, Hangbin Liu wrote:
> On Tue, Nov 03, 2020 at 02:55:54PM -0800, Alexei Starovoitov wrote:
> > > The scope of bpf in iproute2 is tiny - a few tc modules (and VRF but it
> > > does not need libbpf) which is a small subset of the functionality and
> > > command
On Tue, Nov 03, 2020 at 06:40:44PM -0700, David Ahern wrote:
> On 11/3/20 3:55 PM, Alexei Starovoitov wrote:
> > The bpf support in "tc" command instead of being obviously old and obsolete
> > will be sort-of working with unpredictable delay between released kernel
> > and released iproute2 version
On Tue, Nov 03, 2020 at 02:55:54PM -0800, Alexei Starovoitov wrote:
> > The scope of bpf in iproute2 is tiny - a few tc modules (and VRF but it
> > does not need libbpf) which is a small subset of the functionality and
> > commands within the package.
>
> When Hangbin sent this patch set I got exc
On 11/3/20 3:55 PM, Alexei Starovoitov wrote:
> The bpf support in "tc" command instead of being obviously old and obsolete
> will be sort-of working with unpredictable delay between released kernel
> and released iproute2 version. The iproute2 release that suppose to match
> kernel
> release will
On Tue, Nov 03, 2020 at 03:32:55PM -0700, David Ahern wrote:
> On 11/3/20 10:47 AM, Alexei Starovoitov wrote:
> > since David is deaf to technical arguments,
> It is not that I am "deaf to technical arguments"; you do not like my
> response.
>
> The scope of bpf in iproute2 is tiny - a few tc modu
On 11/3/20 10:47 AM, Alexei Starovoitov wrote:
> since David is deaf to technical arguments,
It is not that I am "deaf to technical arguments"; you do not like my
response.
The scope of bpf in iproute2 is tiny - a few tc modules (and VRF but it
does not need libbpf) which is a small subset of the
On Tue, 3 Nov 2020 09:47:00 -0800
Alexei Starovoitov wrote:
> On Tue, Nov 3, 2020 at 9:36 AM David Ahern wrote:
> >
> > On 11/3/20 1:46 AM, Daniel Borkmann wrote:
> > > I thought last time this discussion came up there was consensus that the
> > > submodule could be an explicit opt in for the
On Tue, Nov 3, 2020 at 12:42 AM Jiri Benc wrote:
> sight, this sounds easier for the developers. Why bother with dynamic
> linking at all? Everything can be linked statically.
That's exactly what some companies do.
Linking everything statically provides stronger security.
On Tue, Nov 3, 2020 at 9:36 AM David Ahern wrote:
>
> On 11/3/20 1:46 AM, Daniel Borkmann wrote:
> > I thought last time this discussion came up there was consensus that the
> > submodule could be an explicit opt in for the configure script at least?
>
> I do not recall Stephen agreeing to that, a
On 11/3/20 1:42 AM, Jiri Benc wrote:
> And I'm convinced this is the way to go for libraries, too: put an
> emphasis on API stability. Make it easy to get consumed and updated
> under the hood. Everybody wins this way.
exactly. Libraries should export well thought out, easy to use, stable
APIs. Ma
On 11/3/20 1:46 AM, Daniel Borkmann wrote:
> I thought last time this discussion came up there was consensus that the
> submodule could be an explicit opt in for the configure script at least?
I do not recall Stephen agreeing to that, and I certainly did not.
On 11/3/20 7:58 AM, Andrii Nakryiko wrote:
On Mon, Nov 2, 2020 at 7:47 AM David Ahern wrote:
On 10/29/20 9:11 AM, Hangbin Liu wrote:
This series converts iproute2 to use libbpf for loading and attaching
BPF programs when it is available. This means that iproute2 will
correctly process BTF info
On Mon, 2 Nov 2020 22:58:06 -0800, Andrii Nakryiko wrote:
> But I don't think I got a real answer as to what's the exact reason
> against the submodule. Like what "inappropriate" even means in this
> case? Jesper's security argument so far was the only objective
> criteria, as far as I can tell.
I
On Mon, Nov 2, 2020 at 7:47 AM David Ahern wrote:
>
> On 10/29/20 9:11 AM, Hangbin Liu wrote:
> > This series converts iproute2 to use libbpf for loading and attaching
> > BPF programs when it is available. This means that iproute2 will
> > correctly process BTF information and support the new-sty
On 10/29/20 9:11 AM, Hangbin Liu wrote:
> This series converts iproute2 to use libbpf for loading and attaching
> BPF programs when it is available. This means that iproute2 will
> correctly process BTF information and support the new-style BTF-defined
> maps, while keeping compatibility with the o
This series converts iproute2 to use libbpf for loading and attaching
BPF programs when it is available. This means that iproute2 will
correctly process BTF information and support the new-style BTF-defined
maps, while keeping compatibility with the old internal map definition
syntax.
This is achi
64 matches
Mail list logo
