I don't think there is a ton of overlap. tokio is appropriate for general userspace apps, ranging anywhere from a CLI, GUI, API or web app. DPDK and SPDK are specialized fast paths for building network data paths and storage solutions that come with tradeoffs: DPDK uses poll mode drivers, outside of the operating system, which have various implications including busy waiting and taking over the interface. That is why DPDK is fast, no kernel/userspace context switching and copies, and the drivers are tuned for the polling model. But it's not a general purpose building block.
Fwiw with ef_vi you have full control over the event queue - you don't need to busy-spin it, you can choose whatever strategy you prefer.
> tokio is appropriate for general userspace apps
Yep, and for those I wouldn't recommend it. But tokio is also widely used in performance-critical infrastructure and web services. For those I'd say it can definitely be worth taking a second look at kernel bypass.
ef_vi is a solarflare proprietary feature which is now a support product, AMD moved on to Pensando. Once you move away from busy poll, you rapidly lost grounds to use DPDK. The PMD is a deliberate design to elide latency and lower interconnect taxes like PCIe traffic and cache/memory bandwidth by batching queue maintenance, that is the bargain made with a PMD. The field opens to OS native fast paths which have fewer downsides outside of that niche. Application developers are rarely concerned with this because it's far from where the bottleneck is for them.. a web service is rarely primarily a data mover, while a proxy is. Tokio has more in common with Golang than something like DPDK.
I don't think there is a ton of overlap. tokio is appropriate for general userspace apps, ranging anywhere from a CLI, GUI, API or web app. DPDK and SPDK are specialized fast paths for building network data paths and storage solutions that come with tradeoffs: DPDK uses poll mode drivers, outside of the operating system, which have various implications including busy waiting and taking over the interface. That is why DPDK is fast, no kernel/userspace context switching and copies, and the drivers are tuned for the polling model. But it's not a general purpose building block.
Fwiw with ef_vi you have full control over the event queue - you don't need to busy-spin it, you can choose whatever strategy you prefer.
> tokio is appropriate for general userspace apps
Yep, and for those I wouldn't recommend it. But tokio is also widely used in performance-critical infrastructure and web services. For those I'd say it can definitely be worth taking a second look at kernel bypass.
ef_vi is a solarflare proprietary feature which is now a support product, AMD moved on to Pensando. Once you move away from busy poll, you rapidly lost grounds to use DPDK. The PMD is a deliberate design to elide latency and lower interconnect taxes like PCIe traffic and cache/memory bandwidth by batching queue maintenance, that is the bargain made with a PMD. The field opens to OS native fast paths which have fewer downsides outside of that niche. Application developers are rarely concerned with this because it's far from where the bottleneck is for them.. a web service is rarely primarily a data mover, while a proxy is. Tokio has more in common with Golang than something like DPDK.
Do you have any resources worth referencing on this? I assume this isn't something that works with tokio more of a replace tokio?