Is eBPF directly able to perform simple modifications of the data or only analyze and customize forwarding? E.g. if I had a custom packet encapsulation format I wanted to remap into another encapsulation format of a similar type I'm pretty sure I can use XDP to forward packets that match a userspace program which can then zero-copy modify the contents but at that point it seems to have lost a lot of the luster compared to a kernel module as I'm hopping back and forth between kernelspace and userspace. I'm not sure if that is a limitation of just reading about XDP a lot because dropping packets/load balancing is more popular and I just need to look elsewhere in eBPF or if it's actually a limitation of eBPF itself.
Yes you can do modifications. (simple and not so simple!). For encapsulation you may want to look into lightweight tunnels. General transformation also often happens in the tc subsystem. The available documentation isn't that great yet, but there's good links in the OP about this.
We use XDP for our UDP forwarding data path, encapsulating and decapsulating packets along the way in a custom frame:
Do you ever worry about issues with your hosting company? Like missing out on router optimizations and the like on the underlying network because of your bespoke framing?
Well, I wasn't a minute ago.
Well I guess we’ve proven I’m not the only one susceptible to “OSI model error Eldritch Dread”
Honestly though it's all a moot point for us, since no matter how we encapsulate, all our server-server traffic (TCP, UDP, or otherwise) is over WireGuard, which is itself UDP.
I was just experimenting with eBPF and ran into a limitation:
Is there a way to load the source IP into a register when working in userspace? When I SO_ATTACH_BPF to a SOCK_DGRAM it only makes the udp header accessible, per https://github.com/danielrh/bpf_buffer_per_source/blob/main/...
I would love to be able to run logic based on both IP and port rather than being limited to port alone. Yet it's not worth the inconvenience/danger of running as root to operate with RAW sockets.
While I don't knwo the actual answer, a good place to look may be one of the eBPF load balancers like "Katran" from Facebook. I imagine it's needing to do that sort of thing. But no idea if it's attaching at the same level. I haven't really explained eBPF outside of tracing.
Katran is XDP. The XDP eBPF hooks get packets before they hit the TCP/IP stack --- you can use XDP to route packets without ever creating skbuffs for them. The previous commenter is explicitly trying to use socket eBPF code, because they don't want their code to have to run as root. Katran won't be helpful for them.
Does anyone have experience with eBPF on aarch64? How well is it supported? On what kernel revisions was it phased in and well tested there?
It's as well supported as x86 these days. It's was phased in somewhere around 2014.
Based on the hype around eBPF, you'd think it was a new JS framework. I suspect that it's hype will dwindle as people realize that it's mostly invisible to them. Just pay for <random monitoring solution> and it'll plug into eBPF, without you having to say the words e, b, or even pf.
What if I also do networking on my computer? Will my monitoring solution magically do packet manipulation without my input?
eBPF is not just for monitoring.
There's no programming environment you can't say this about.
eBPF has basically democratized the performance that used to be reserved for DPDK applications and other weird user space things. It's a big deal.