So I hear there is a desire to do this. So I think we should list the
use-cases for this first because that would lead to different design
choices.. For example one use-case is just to send read/write/flush
to userspace, another may want to passthru nvme commands to userspace
and there may be others...
(resending my reply without truncating the Cc-list)
Hi Sagi,
Haven't these use cases already been mentioned in the email at the start
of this thread? The use cases I am aware of are implementing
cloud-specific block storage functionality and also block storage in
user space for Android. Having to parse NVMe commands and PRP or SGL
lists would be an unnecessary source of complexity and overhead for
these use cases. My understanding is that what is needed for these use
cases is something that is close to the block layer request interface
(REQ_OP_* + request flags + data buffer).
pasting my response here as well:
Well, I can absolutely think of a use-case that will want raw nvme
commands and leverage vendor specific opcodes for applications like
computational storage or what not...
I would say that all the complexity of handling nvme commands in
userspace would be handle in a properly layered core stack with
pluggable backends that can see a simplified interface if they want, or
see a full passthru command.
