Feature parity with libbpf

[mejedi]

Hello from EMnify! Been a big fan of yours for a while :)

We are building proprietary networking components with golang and eBPF. Our setup is a bit hairy, as we have libbpf and cgo in the mix. Right now, we are considering a switch to cilium/ebpf.

I wonder if the project aims to be on par feature-wise with libbpf. How bumpy the transition is going to be? In particular:

• It would be very helpful if there was a human-readable document outlining what's supported and what's not.
  E.g. subprograms are supported (are they?), netlink program attachment APIs are deliberately NOT supported.

• Do I read CONTRIBUTING.md correctly: you will consider contributions for features that Cilium itself doesn't need?

[lmb]

Thanks for getting in touch!

I wonder if the project aims to be on par feature-wise with libbpf.

The way I'd phrase it would be: if a comparable libbpf feature exists we strive to be compatible with the implementation. It's not going to be 100% of course, for example CO-RE will behave differently.

Other than that, the features we have are driven by contributors. There is no policy that says we will support all APIs that libbpf version X has.

It would be very helpful if there was a human-readable document outlining what's supported and what's not.

That doesn't exist unfortunately, since keeping it up to date would be a lot of work. Just keeping track of what happens in libbpf is sometimes daunting. If you drop by slack we can discuss your needs and what's missing.

you will consider contributions for features that Cilium itself doesn't need?

Yes, of course! For example someone from Microsoft recently contributed support for overwritable perf buffers which aren't used by Cilium. The caveat of course is that new features should fit into the scope of the library and should not require taking on large external dependencies.