On 3/13/22 14:15, Sagi Grimberg wrote:
We don't want to re-use tcmu's interface.
Bodo has been looking into on a new interface to avoid issues tcmu has
and to improve performance. If it's allowed to add a tcmu like backend to
nvmet then it would be great because lio was not really made with mq and
perf in mind so it already starts with issues. I just started doing the
basics like removing locks from the main lio IO path but it seems like
there is just so much work.
Good to know...
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).
Thanks,
Bart.
