XDP: 1.5 years in production [pdf]
vger.kernel.org
XDP: 1.5 years in production [pdf]
1–10 of 15 posts
Re: XDP: 1.5 years in production [pdf]
#2These slides seem to be rather incomprehensible without the accompanying talk.
Edit: Oh boy. That's so obviously not a criticism of the talk.
Re: XDP: 1.5 years in production [pdf]
#3If anyone has any questions about XDP or eBBF in production, I'd be happy to answer. I've been working on an XDP deployment with Rust as the control plane language, and have found it to be an incredibly technology that makes high performance networking extremely accessible.
Also, Katran is very cool. Facebook is doing really cutting edge work in the networking space.
Re: XDP: 1.5 years in production [pdf]
#4These slides seem to be rather incomprehensible without the accompanying talk. Edit: Oh boy. That's so obviously not a criticism of the talk.
No video yet, but here you have the paper.
http://vger.kernel.org/lpc-networking2018.html#session-10
On the other hand, Cilium.io made a good summary of that. https://cilium.io/blog/2018/11/20/fb-bpf-firewall
Re: XDP: 1.5 years in production [pdf]
#5If anyone has any questions about XDP or eBBF in production, I'd be happy to answer. I've been working on an XDP deployment with Rust as the control plane language, and have found it to be an incredibly technology that makes high performance networking extremely accessible. Also, Katran is very cool. Facebook is doing really cutting edge work in the networking space.
can you give an ELI5 of the benefits of XDP over current technologies?
Re: XDP: 1.5 years in production [pdf]
#6If anyone has any questions about XDP or eBBF in production, I'd be happy to answer. I've been working on an XDP deployment with Rust as the control plane language, and have found it to be an incredibly technology that makes high performance networking extremely accessible. Also, Katran is very cool. Facebook is doing really cutting edge work in the networking space.
can you give an ELI5 of the benefits of XDP over current technologies?
eBPF programs are bytecode that runs on a virtual machine in the kernel. The programs are limited by number of instructions and computational complexity (they must halt). These programs can transfer data back to user space using maps, which are simple data structures for passing things like lists of ips, for example. These eBPF programs are attached to probes in the kernel where they can gather information at the probe point. XDP is essentially a probe before any of the networking stack has happened. An XDP eBPF program can read and manipulate raw packet data, allowing you to process the packet as fast as your network card will allow, before that data is ever seen by the slow kernel networking code.
Unlike other options like DPDK, eBPF programs are tightly integrated in the kernel. They allow you to write kernel code that the kernel can safely run. They are simple to write, easy to install (it's just a syscall) and there are tools in Rust and other languages (check out BCC) that allow you to compile to eBPF bytecode from various languages. You're also not just limited to networking. eBPF programs can hook in to many places in the kernel, and there are already efforts to build new system performance tools using eBPF.
Re: XDP: 1.5 years in production [pdf]
#7Earlier quoted context omitted.
can you give an ELI5 of the benefits of XDP over current technologies?
eBPF programs are bytecode that runs on a virtual machine in the kernel. The programs are limited by number of instructions and computational complexity (they must halt). These programs can transfer data back to user space using maps, which are simple data structures for passing things like lists of ips, for example. These eBPF programs are attached to probes in the kernel where they can gather information at the pro…
What are the downsides of eBPF(XDP)programs compared to the previous options (DPDK etc.)?
Do you consider eBPF(XDP) to be the clear next step in this space?
Re: XDP: 1.5 years in production [pdf]
#8If anyone has any questions about XDP or eBBF in production, I'd be happy to answer. I've been working on an XDP deployment with Rust as the control plane language, and have found it to be an incredibly technology that makes high performance networking extremely accessible. Also, Katran is very cool. Facebook is doing really cutting edge work in the networking space.
Have you thought of adding an eBPF backend for Rust?
I'm curious where you work. I've been doing eBPF in production for a while as well, but our control plane is Go / C.
Re: XDP: 1.5 years in production [pdf]
#9Earlier quoted context omitted.
eBPF programs are bytecode that runs on a virtual machine in the kernel. The programs are limited by number of instructions and computational complexity (they must halt). These programs can transfer data back to user space using maps, which are simple data structures for passing things like lists of ips, for example. These eBPF programs are attached to probes in the kernel where they can gather information at the pro…
What are the downsides of eBPF(XDP)programs compared to the previous options (DPDK etc.)? Do you consider eBPF(XDP) to be the clear next step in this space?
https://t.co/UjQE8Z6HlD
Check this out, it spells out why DPDK isn't a great solution.
The downsides to XDP is that it requires newer kernel releases, also XDP eBPF programs do not provide chaining and are limited in size (they can be chained, you just have to do it yourself).
Re: XDP: 1.5 years in production [pdf]
#10If anyone has any questions about XDP or eBBF in production, I'd be happy to answer. I've been working on an XDP deployment with Rust as the control plane language, and have found it to be an incredibly technology that makes high performance networking extremely accessible. Also, Katran is very cool. Facebook is doing really cutting edge work in the networking space.
Have you thought of adding an eBPF backend for Rust? I'm curious where you work. I've been doing eBPF in production for a while as well, but our control plane is Go / C.
It's already done. LLVM IR can be compiled to eBPF already, and Rust compiles to LLVM IR. It just took a little bit of effort to make it not totally hacky, but that code isn't OS.