LWN: Comments on "Debating the value of XDP"

Debating the value of XDP

ksandstr — Fri, 09 Dec 2016 18:19:23 +0000

>This all starts to look like GPU shader programs at some point 8-)

It's looking like mid-to-late nineties Direct3D right now. Predicting from that, it seems unlikely that current XDP programs will ever be translated into bytecoded hardware-supported mysteriously zomgfast[0] acceleration primitives on networking hardware. As such, they're strictly inferior to models like "a compiled C program executing in kernel mode" or, in the absence of a magical in-kernel compiler infrastructure, any fixed-function acceleration pipeline at all.

[0] and not just "0.7 GHz ARM SOC w/ OpenCL, on a PCIe board": just another channel processor with a proprietary interface

Debating the value of XDP

raven667 — Thu, 08 Dec 2016 22:40:27 +0000

If you are going down the eBPF path, why not go all the way and replace all of the hand-optimized C network stack with a eBPF (or similar) VM running in kernel or in userspace that is machine optimized? You can expose some efficient datastructures to it which may be hand-optimized for state tracking when needed. This all starts to look like GPU shader programs at some point 8-)

Debating the value of XDP

Tara_Li — Thu, 08 Dec 2016 16:32:00 +0000

As XDP programs gain functionality, they will need access to increasingly sophisticated information from the rest of the networking stack.

This looks like the root of the problem here - the fear of creeping featuritis. XDP looks to be intended for a very limited set of issues where the slowdown on processing the rest of the packets is made up for by getting rid of some fraction quickly, hopefully leaving more time for the rest of the packets to get handled more thoroughly. But, if XDP gains more and more functionality, and handles more and more of the packets, at some point it no longer is the "fast path", but becomes the default "slow" path, vs. the old default "even slower path" (which is now only "even slower" because XDP has taken on so much, it's taking as long as the old default did). And yet, each project thinks that its particular class of problem packets should be taken care of first, meaning that small patches to add this new tiny bit of functionality get submitted to add something they need, while gradually slowing down ALL of the packets taking the so-called "fast path". It sounds like a good idea, but can any developer actually say that they believe that if something like this is implemented, it won't develop creeping featuritis?