Juniper / ebplane

eBPF based dataplane prototypes
Apache License 2.0
23 stars 4 forks source link

Introduce cc_ebpf rule to compile and embed ebpf code. #18

Closed ccontavalli-j closed 5 years ago

ccontavalli-j commented 5 years ago

Before this change:

eBPF code could be compiled with a normal cc_library target with eBPF specific options. This, however, failed during the linking stage, as it could not create an AR file. Further, using the .o file was not really possible.

In this change:

Note that the test is still incomplete: there is no evidence that the eBPF code is actually compiled correctly.

The vision here is that: 1) We'll add more tests as we add code to actually load and verify the eBPF code. 2) eBPF has a lot of sharp edges. I exepct the cc_ebpf rule will be updated over time to include more compiler flags, and automated checks [1].

[1]: see for example https://github.com/cilium/cilium/blob/master/Documentation/bpf.rst, limits in instructions, constructs, and so on.

ccontavalli-j commented 5 years ago

The test is failing not because the new cc_ebpf rule is buggy, but because this is the first test added that is causing bazel to attempt to build libbpf / libelf in the cloud.

Their builds are far from hermetic at this point. I need to debug RBE, but it's entirely possible this won't work until I fix the toolchain situation.

ccontavalli-j commented 5 years ago

Also, compare the diffs with the embed branch, not master. This change is built on top of embed.

ccontavalli-j commented 5 years ago

I've looked more into the failure, and yes. This is the build not being hermetic. I have a few fixes in mind, but will require dedicated changes.

mhines99 commented 5 years ago

Can you add a readme on the overview of why this path is needed from ebpf

mhines99 commented 5 years ago

what do we need to do to get the rbe cloud build working?

ccontavalli-j commented 5 years ago

what do we need to do to get the rbe cloud build working?

The base image used by bazel invoked by cloudbuild is quite old. libstdc++ is too old, gcc is too old, ... We have two possibilities:

1) Use a different docker image for bazel. But bazel team does not provide a more up to date one, so we'd have to create one by copying what they do in their Dockerfile. This is probably < 1 hour of work, but it will create pain over time.

2) Use a self contained toolchain as part of the build, so regardless of where the build is run, we have a good compiler and base libraries. This is my preferred path, but it requires more work. I'm actually working on this ETA, a couple of dedicated days.

Can you add a readme on the overview of why this path is needed from ebpf

Done.