The XDP code is really new and will take time to fully test, but I wanted to bookmark this now so I don't forget.

Basically, the current XDP implementation is binding to all network device queues where each socket + queue gets their own separate thread. This is good in the sense that the load will be spread across all threads fairly evenly due to receive side scaling, but it has a downside, in that, though we poll, giving every thread a wait point where it can schedule other CPU work, in a regular case with hundreds or thousands of connections, these threads will all be active constantly, potentially starving other threads for long (seconds) periods of time. This is probably ok for eg. the HTTP admin service, but would be bad for the QCMP task as it would skew measurements unpredictably. The QCMP code is fairly simple, so it could just be moved to run entirely in the eBPF program we use to route packets, but that would make the fairly simple program more complicated, so we could just move it to be processed in the same I/O loop as the regular client/server packets since it's just handling packets sent to a specific port.