It's certainly true that the polled-mode driver model doesn't interact well when the application needs to use other APIs that don't provide a polled mode. However, SPDK can be used in conjunction with a polled user-mode network stack so that a storage application can operate fully in user mode without any user-to-kernel context switches or hardware interrupts.
It's definitely not a drop-in replacement for a kernel storage stack in the general case, but rather an optimization for specific applications (e.g. storage appliances) that can be structured to take advantage of the polled/no-interrupts model.
Thank you. That's kind of the point I was trying to make. For a storage appliance - and that's the most common deployment model for the software I work on - it's great. I just don't want to see every "full stack" halfwit trying to use a specialized tool for general-purpose stuff. That often ends up wasting everyone's time - especially that of the people providing the tool.
That said, there are cases where it would make sense in a multicore environment to pin one core to storage polling, and another to network polling.
You will then, of course, have contention in transitioning data between the two, but there are existing and useful models for eliding much of the locking load there.
It's definitely not a drop-in replacement for a kernel storage stack in the general case, but rather an optimization for specific applications (e.g. storage appliances) that can be structured to take advantage of the polled/no-interrupts model.