From: Daniel Borkmann <daniel@iogearbox.net>
To: Jakub Kicinski <kubakici@wp.pl>
Cc: xdp-newbies@vger.kernel.org, ast@fb.com
Subject: Re: XDP/BPF C and python libraries?
Date: Fri, 21 Jul 2017 12:22:14 +0200 [thread overview]
Message-ID: <5971D5D6.8010300@iogearbox.net> (raw)
In-Reply-To: <20170720225308.14e2ac14@cakuba.netronome.com>
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
next prev parent reply other threads:[~2017-07-21 10:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 5:53 XDP/BPF C and python libraries? Jakub Kicinski
2017-07-21 10:22 ` Daniel Borkmann [this message]
2017-07-21 22:37 ` Jakub Kicinski
2017-07-22 7:20 ` Jakub Kicinski
2017-07-23 5:35 ` Y Song
2017-07-23 23:54 ` Jakub Kicinski
2017-07-24 0:27 ` David Ahern
2017-07-24 1:00 ` Jakub Kicinski
2017-08-04 22:20 ` David Ahern
2017-08-05 16:40 ` Jakub Kicinski
2017-08-05 19:59 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5971D5D6.8010300@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=ast@fb.com \
--cc=kubakici@wp.pl \
--cc=xdp-newbies@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.