On 20/12/01 01:08PM, Toke Høiland-Jørgensen wrote: > "Brian G. Merrell" <brian.g.merrell@xxxxxxxxx> writes: > > > Hi all, > > > > tl;dr: What does the future look like for Go programs orchestrating > > multiple, chained eBPF network functions? Is it worth considering doing > > the orchestration from C++ (or Rust) instead of Go? I'm hoping the > > Cilium and/or Katran folks (and any other interested people) can weigh > > in! > > Thank you for bringing this up! Adding a few people (and bpf@vger) to Cc > to widen the discussion a bit. > [snip] > > As I see it there are basically four paths to widen the language support > for libxdp/multiprog: Thanks for enumerating these paths; I think they are all feasible. It's just a matter of weighing trade-offs, naturally. > > 1. Regular language bindings for the C libxdp. I gather this is somewhat > cumbersome in Go, though, as evidenced by the existence of a > native-go BPF library. "Cumbersome" is a nice, succinct way to put it. While we could hack something together for POC code (if we get to that point before a better option is available), I don't think this is the right answer for Go applications in general (based on personal experience, documented experiences from other projects, and apparently lack of interest in cgo from the Go team--anyone curious about details need only search the web). > > 2. Reimplement the libxdp functionality in each language. Libxdp really > implements a "protocol" for how to cooperatively build a multiprog > dispatcher from component programs, including atomic replace etc. > This could be re-implemented by other libraries / in other languages > as well, and if people want to go this route I'm happy to write up a > formal specification if that's helpful. I'm not aware of any efforts > in this direction thus far, though. With a small edge over option #4, I think this is the best of the options. The downside is that it is not part of the xdp project, so the developers of the Go implementation will obviously be responsible for all of the initial and continuing overhead of a full reimplementation. Toke, you probably see that as an upside :). Regardless, I think that libxdp is not so large to make this overly burdensome. Could you please write up that format specification and we will start running with it? > > 3. Make xdp-loader explicitly support the fork/exec use case you're > describing above. Nothing says this has to lose any information > compared to the library, we just have to design for it (JSON output > and the ability to pass a BPF object file as an fd on exit would be > the main things missing here, I think). I certainly wouldn't object > to including this in xdp-loader. There is some temptation in asking for this approach because it becomes part of the xdp project. I just can't help but think it will be a constant struggle to keep the same level of flexibility and control with this approach versus access to a full library. I will admit that I am moderately ignorant about exactly what challenges we might face because I'm still learning more about bpf, xdp, and libxdp every day; I am definitely open to being convinced that my concerns are wrong. > > 4. Implement an "xdpd" daemon that exposes an IPC interface (say, a > socket) and does all the stuff libxdp currently does in application > context. Each language then just has to talk to the daemon which is > less complex than the full libxdp re-implementation. This option very tempting. I understand your hesitancy to add another dependency for running XDP--if it wasn't for that, I may have pushed harder for this approach. I do like the idea of the xdpd daemon being part of the xdp project and providing a language agnostic interface to the library. There will still need to be a new Go project written to interface with the daemon. This seems like quite a bit less work than a reimplementation, but combined with the downside of adding another dependency, I think we can pass on this option--unless you really have a change of heart :) > > I've been resisting the daemon approach because I don't like introducing > another dependency for running XDP. But my main concern is that we end > up with something that is compatible across environments and > implementations, so applications that use XDP don't have to deal with > multiple incompatible ways of loading their programs. > > So any feedback anyone has as to which approach(es) would/would not work > for you would be welcome (speaking to everyone here)! Yes, please, if anyone has additional thoughts please weigh in, but I think my team is ready to commit to option #2. Any concerns about my assessment and request? Thanks, Brian
|