XDP/BPF C and python libraries?

XDP/BPF C and python libraries?

[Jakub Kicinski]

Hi!

I've been writing various cli programs and little tools to play with
XDP and maps lately (testing NFP map offload).  I have a simple CLI
for loading programs, setting XDP up and interacting with maps.  It's
based on libbpf from tools/ and the loader from samples/bpf.  I wonder
how do others perform basic map interactions?  Perhaps I'm approaching
the problem from the wrong side?  Is anyone working on command line
interface for simple update/dump/delete operations?

I think it's recommended to use bpffs, are there any tools for
interacting with it?

Are there any Python libraries which could take care of parsing ELF
files and poking maps?  My understanding is that BCC is not really the
tool for the job, because it's too high-level.  I don't want to compile
programs each time I want to load them.

On the kernel sources - I'm pretty sure this was discussed on netdev
but I forgot the conclusion :( - is it possible to move
samples/bpf/bpf_load.c in some form to libbpf?

Re: XDP/BPF C and python libraries?

[Daniel Borkmann]

Hi Jakub,

On 07/21/2017 07:53 AM, Jakub Kicinski wrote:
[...]
> I've been writing various cli programs and little tools to play with
> XDP and maps lately (testing NFP map offload).  I have a simple CLI
> for loading programs, setting XDP up and interacting with maps.  It's
> based on libbpf from tools/ and the loader from samples/bpf.  I wonder
> how do others perform basic map interactions?  Perhaps I'm approaching
> the problem from the wrong side?  Is anyone working on command line
> interface for simple update/dump/delete operations?

There is a small debugging tool in golang at [1] for inspection
(but e.g. main integration and interaction is done from orchestrator
side in case of cilium).

> I think it's recommended to use bpffs, are there any tools for
> interacting with it?

Only to name a few examples, cilium and the iproute2's BPF ELF
loader interact with it, and I think recently also bcc got support
for bpffs. From library side kernel's libbpf supports pinning into
bpffs as well. We could probably have a small tool utilizing libbpf
that sits under kernel tools/, though.

> Are there any Python libraries which could take care of parsing ELF
> files and poking maps?  My understanding is that BCC is not really the
> tool for the job, because it's too high-level.  I don't want to compile
> programs each time I want to load them.
>
> On the kernel sources - I'm pretty sure this was discussed on netdev
> but I forgot the conclusion :( - is it possible to move
> samples/bpf/bpf_load.c in some form to libbpf?

Yep, that would be great if you have some patches! We should
unify loader code where possible, so that both samples and
selftests only use libbpf eventually. Also some of the sample
programs should move to tools/testing/selftests/bpf/, so they
can then be run on both, kbuild bot as well as linaro's kernel
test framework to check for potential regressions.

Generally speaking, if you have some small, useful and generic
tools that neither fit into iproute2 nor samples / selftests,
then feel free to rename tools/net/ into tools/bpf/ (since all of
there is BPF anyway right now) and add them into that location
for general use.

Thanks,
Daniel

   [1] https://github.com/cilium/bpf-map

Re: XDP/BPF C and python libraries?

[Jakub Kicinski]

On Fri, 21 Jul 2017 12:22:14 +0200, Daniel Borkmann wrote:
> Hi Jakub,
> 
> On 07/21/2017 07:53 AM, Jakub Kicinski wrote:
> [...]
> > I've been writing various cli programs and little tools to play with
> > XDP and maps lately (testing NFP map offload).  I have a simple CLI
> > for loading programs, setting XDP up and interacting with maps.  It's
> > based on libbpf from tools/ and the loader from samples/bpf.  I wonder
> > how do others perform basic map interactions?  Perhaps I'm approaching
> > the problem from the wrong side?  Is anyone working on command line
> > interface for simple update/dump/delete operations?  
> 
> There is a small debugging tool in golang at [1] for inspection
> (but e.g. main integration and interaction is done from orchestrator
> side in case of cilium).

Thanks that's exactly the sort of functionality I had in mind.

> > I think it's recommended to use bpffs, are there any tools for
> > interacting with it?  
> 
> Only to name a few examples, cilium and the iproute2's BPF ELF
> loader interact with it, and I think recently also bcc got support
> for bpffs. From library side kernel's libbpf supports pinning into
> bpffs as well. We could probably have a small tool utilizing libbpf
> that sits under kernel tools/, though.

Upon further reflection it dawned on me that I should probably build on
top of Martin's work and utilize the prog/map ids.  Martin, do you have
any code (or plans to produce code :)) for listing/interrogating/
prodding programs and maps via the new ABI?

> > Are there any Python libraries which could take care of parsing ELF
> > files and poking maps?  My understanding is that BCC is not really the
> > tool for the job, because it's too high-level.  I don't want to compile
> > programs each time I want to load them.
> >
> > On the kernel sources - I'm pretty sure this was discussed on netdev
> > but I forgot the conclusion :( - is it possible to move
> > samples/bpf/bpf_load.c in some form to libbpf?  
> 
> Yep, that would be great if you have some patches! We should
> unify loader code where possible, so that both samples and
> selftests only use libbpf eventually. Also some of the sample
> programs should move to tools/testing/selftests/bpf/, so they
> can then be run on both, kbuild bot as well as linaro's kernel
> test framework to check for potential regressions.
> 
> Generally speaking, if you have some small, useful and generic
> tools that neither fit into iproute2 nor samples / selftests,
> then feel free to rename tools/net/ into tools/bpf/ (since all of
> there is BPF anyway right now) and add them into that location
> for general use.

If I have anything useful I will definitely share :)

Thanks!

Re: XDP/BPF C and python libraries?

[Jakub Kicinski]

On Fri, 21 Jul 2017 15:37:43 -0700, Jakub Kicinski wrote:
> On Fri, 21 Jul 2017 12:22:14 +0200, Daniel Borkmann wrote:
> > Hi Jakub,
> > 
> > On 07/21/2017 07:53 AM, Jakub Kicinski wrote:
> > > I think it's recommended to use bpffs, are there any tools for
> > > interacting with it?    
> > 
> > Only to name a few examples, cilium and the iproute2's BPF ELF
> > loader interact with it, and I think recently also bcc got support
> > for bpffs. From library side kernel's libbpf supports pinning into
> > bpffs as well. We could probably have a small tool utilizing libbpf
> > that sits under kernel tools/, though.  
> 
> Upon further reflection it dawned on me that I should probably build on
> top of Martin's work and utilize the prog/map ids.  Martin, do you have
> any code (or plans to produce code :)) for listing/interrogating/
> prodding programs and maps via the new ABI?

I put together this very simple tool with iproute2-like syntax:

https://github.com/Netronome/bpf-tool

These are available subcommands:

bpf prog show

bpf map show
bpf map dump   id MAP_ID
bpf map update id MAP_ID key BYTES value BYTES
bpf map lookup id MAP_ID key BYTES
bpf map delete id MAP_ID key BYTES

The plan is to add support for substituting "id MAP_ID" with "pinned
PATH".

I probably have a need to poke maps more randomly than people would
usually do, but I certainly enjoy the freedom of being able to load the
xdp kernel samples with iproute2 and then observe the values from CLI :)

I wonder what others think.  Or maybe someone else has a similar tool,
but just haven't responded yet?

One thing which is not clear to me is how to get the association
between programs and maps?  Would we need to extend
BPF_OBJ_GET_INFO_BY_FD to provide this info?

Re: XDP/BPF C and python libraries?

[Y Song]

cc'ing iovisor/bcc dev alias

Jakub,

I think this (bpf prog/map introspection) is a great idea.
I am cc'ing iovisor/bcc alias so maybe similar functionality
can be implemented in bcc as well.

Thanks,

Yonghong


On Sat, Jul 22, 2017 at 12:20 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Fri, 21 Jul 2017 15:37:43 -0700, Jakub Kicinski wrote:
>> On Fri, 21 Jul 2017 12:22:14 +0200, Daniel Borkmann wrote:
>> > Hi Jakub,
>> >
>> > On 07/21/2017 07:53 AM, Jakub Kicinski wrote:
>> > > I think it's recommended to use bpffs, are there any tools for
>> > > interacting with it?
>> >
>> > Only to name a few examples, cilium and the iproute2's BPF ELF
>> > loader interact with it, and I think recently also bcc got support
>> > for bpffs. From library side kernel's libbpf supports pinning into
>> > bpffs as well. We could probably have a small tool utilizing libbpf
>> > that sits under kernel tools/, though.
>>
>> Upon further reflection it dawned on me that I should probably build on
>> top of Martin's work and utilize the prog/map ids.  Martin, do you have
>> any code (or plans to produce code :)) for listing/interrogating/
>> prodding programs and maps via the new ABI?
>
> I put together this very simple tool with iproute2-like syntax:
>
> https://github.com/Netronome/bpf-tool
>
> These are available subcommands:
>
> bpf prog show
>
> bpf map show
> bpf map dump   id MAP_ID
> bpf map update id MAP_ID key BYTES value BYTES
> bpf map lookup id MAP_ID key BYTES
> bpf map delete id MAP_ID key BYTES
>
> The plan is to add support for substituting "id MAP_ID" with "pinned
> PATH".
>
> I probably have a need to poke maps more randomly than people would
> usually do, but I certainly enjoy the freedom of being able to load the
> xdp kernel samples with iproute2 and then observe the values from CLI :)
>
> I wonder what others think.  Or maybe someone else has a similar tool,
> but just haven't responded yet?
>
> One thing which is not clear to me is how to get the association
> between programs and maps?  Would we need to extend
> BPF_OBJ_GET_INFO_BY_FD to provide this info?

Re: XDP/BPF C and python libraries?

[Jakub Kicinski]

On Sat, 22 Jul 2017 00:20:50 -0700, Jakub Kicinski wrote:
> One thing which is not clear to me is how to get the association
> between programs and maps?  Would we need to extend
> BPF_OBJ_GET_INFO_BY_FD to provide this info?

Another thing that I can't find a way of doing is telling whether BPF fs
file is representing a map or a program.  Is there a way to do this
today?

Re: XDP/BPF C and python libraries?

[David Ahern]

On 7/23/17 5:54 PM, Jakub Kicinski wrote:
> On Sat, 22 Jul 2017 00:20:50 -0700, Jakub Kicinski wrote:
>> One thing which is not clear to me is how to get the association
>> between programs and maps?  Would we need to extend
>> BPF_OBJ_GET_INFO_BY_FD to provide this info?
> 
> Another thing that I can't find a way of doing is telling whether BPF fs
> file is representing a map or a program.  Is there a way to do this
> today?
> 

Once you have the fd you should be able to look at /proc/pid/fd/%d

I have been using this:

static int bpf_get_type(__u32 fd, __u32 pid, enum bpf_type *type)
{
        char file[PATH_MAX];
        char buf[512];
        ssize_t n;

        *type = BPF_TYPE_UNSPEC;

        snprintf(file, sizeof(file), "/proc/%d/fd/%d", pid, fd);

        n = readlink(file, buf, sizeof(buf));
        if (n < 0)
                return -1;

        if (strstr(buf, "bpf-prog"))
                *type = BPF_TYPE_PROG;
        else if (strstr(buf, "bpf-map"))
                *type = BPF_TYPE_MAP;

        return 0;
}

Re: XDP/BPF C and python libraries?

[Jakub Kicinski]

On Sun, 23 Jul 2017 18:27:14 -0600, David Ahern wrote:
> On 7/23/17 5:54 PM, Jakub Kicinski wrote:
> > On Sat, 22 Jul 2017 00:20:50 -0700, Jakub Kicinski wrote:  
> >> One thing which is not clear to me is how to get the association
> >> between programs and maps?  Would we need to extend
> >> BPF_OBJ_GET_INFO_BY_FD to provide this info?  
> > 
> > Another thing that I can't find a way of doing is telling whether BPF fs
> > file is representing a map or a program.  Is there a way to do this
> > today?
> >   
> 
> Once you have the fd you should be able to look at /proc/pid/fd/%d
> 
> I have been using this:
> 
> static int bpf_get_type(__u32 fd, __u32 pid, enum bpf_type *type)
> {
>         char file[PATH_MAX];
>         char buf[512];
>         ssize_t n;
> 
>         *type = BPF_TYPE_UNSPEC;
> 
>         snprintf(file, sizeof(file), "/proc/%d/fd/%d", pid, fd);
> 
>         n = readlink(file, buf, sizeof(buf));
>         if (n < 0)
>                 return -1;
> 
>         if (strstr(buf, "bpf-prog"))
>                 *type = BPF_TYPE_PROG;
>         else if (strstr(buf, "bpf-map"))
>                 *type = BPF_TYPE_MAP;
> 
>         return 0;
> }

Great, that works!  Thanks!

Re: XDP/BPF C and python libraries?

[David Ahern]

On 7/22/17 1:20 AM, Jakub Kicinski wrote:
> I put together this very simple tool with iproute2-like syntax:
> 
> https://github.com/Netronome/bpf-tool
> 
> These are available subcommands:
> 

Looking to add my code that pretty-prints instructions, but having
trouble building the tool. What bpf headers should be installed? e.g.,
<bpf/bpf.h>. hunting and pecking now based on what is in the kernel tree.

Re: XDP/BPF C and python libraries?

[Jakub Kicinski]

On Fri, 4 Aug 2017 16:20:19 -0600, David Ahern wrote:
> On 7/22/17 1:20 AM, Jakub Kicinski wrote:
> > I put together this very simple tool with iproute2-like syntax:
> > 
> > https://github.com/Netronome/bpf-tool
> > 
> > These are available subcommands:
> >   
> 
> Looking to add my code that pretty-prints instructions, but having
> trouble building the tool. What bpf headers should be installed? e.g.,
> <bpf/bpf.h>. hunting and pecking now based on what is in the kernel tree.

Hmm..  Did you run make install_headers?  I think my commit message
diverged from what the Makefile does.  To keep things in line with
tools/lib/traceevent/Makefile I made it a separate target.

I just tested on fresh Fedora 26 w/ net-next:

$ git rev-parse HEAD
a54df682e559da9cf09b41779ee62bc9f11d3804
$ make headers_install INSTALL_HDR_PATH=/usr/
[...]
$ cd tools/lib/bpf/
$ make -j 6
Auto-detecting system features:
...                        libelf: [ on  ]
...                           bpf: [ on  ]

Warning: tools/include/uapi/linux/bpf.h differs from kernel
  CC       libbpf.o
  CC       bpf.o
  LD       libbpf-in.o
  LINK     libbpf.a
  LINK     libbpf.so
$ sudo make install prefix=/usr/
Password: 
Warning: tools/include/uapi/linux/bpf.h differs from kernel
  INSTALL  libbpf.a
  INSTALL  libbpf.so
$ sudo make install_headers
  INSTALL  headers
$ cd ../bpf-tool
$ make
gcc -std=gnu99 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow   -c -MMD -o bpf-map.o bpf-map.c
gcc -std=gnu99 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow   -c -MMD -o bpf-prog.o bpf-prog.c
gcc -std=gnu99 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow   -c -MMD -o bpf-common.o bpf-common.c
gcc -std=gnu99 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow   -c -MMD -o bpf-jit-disasm.o bpf-jit-disasm.c
gcc -std=gnu99 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow -o bpftool bpf.o bpf-map.o bpf-prog.o bpf-common.o bpf-jit-disasm.o -lelf -lbpf -lelf -lbfd -lopcodes
$ ./bpftool 
Usage: ./bpftool OBJECT { COMMAND | help }
       ./bpftool batch file FILE

       OBJECT := { program | map }

Re: XDP/BPF C and python libraries?

[David Ahern]

On 8/5/17 10:40 AM, Jakub Kicinski wrote:
> On Fri, 4 Aug 2017 16:20:19 -0600, David Ahern wrote:
>> On 7/22/17 1:20 AM, Jakub Kicinski wrote:
>>> I put together this very simple tool with iproute2-like syntax:
>>>
>>> https://github.com/Netronome/bpf-tool
>>>
>>> These are available subcommands:
>>>   
>>
>> Looking to add my code that pretty-prints instructions, but having
>> trouble building the tool. What bpf headers should be installed? e.g.,
>> <bpf/bpf.h>. hunting and pecking now based on what is in the kernel tree.
> 
> Hmm..  Did you run make install_headers?  I think my commit message
> diverged from what the Makefile does.  To keep things in line with
> tools/lib/traceevent/Makefile I made it a separate target.
> 
> I just tested on fresh Fedora 26 w/ net-next:

I'm on Debian jessie with net-next. I added EXTRA_CFLAGS to the Makefile
and pass in paths using it, so I have the tool compiled. make on jessie
was complaining about initializations as well.

And adding the pretty-print code was straightforward. I need to do some
cleanups before sending a patch.