ooh no more DPDK, this will make it a lot easier. I just started working with trex but it's all really complicated. Going to give this a try
The difference I was getting at vs DPDK is that the kernel NIC driver/NAPI/XDP path is still involvd. With DPDK the userspace PMD is effectively driving the NIC and accessing the queues directly.
either way, it's great and everyone should use it :) that is assuming they have a use case for it. The use-cases are perhaps somewhat limited as it also bypasses the kernel tcp-ip stack, so you gotta do a lot yourself.
Disclosure: Ostinato creator here.
I need to check about the af_xdp ecosystem around fragmentation/reassembly in UDP too, every time I needed something there DPDK had it, often with an offload path.
Some silly stuff in DPDK are very useful for testing too (in-memory devices).
Also I'm not clear on the virtualization story on af_xdp, with dpdk I got something working at full blast 400G in VMs with little (but finnicky) work.
A lot of the socket featureset of io_uring seems available in AF_XDP https://docs.kernel.org/networking/af_xdp.html which shows lots of progress since I looked last.
To get an idea of what DPDK gives low-level access to there is the overview https://doc.dpdk.org/guides/nics/features.html and my "favorite annual terabit read" https://doc.dpdk.org/guides/nics/mlx5.html#mlx5-net-features for NVIDIA NICs. Broadcom has some fun stuff too. The first time you hit top RX speed (2x400G my latest) with only one busy core (yay DMA engines) is always a thrill.