Re: [LSF/MM/BPF TOPIC] block drivers in user space

[Sagi Grimberg <sagi@grimberg.me>]

>>> FYI, I have absolutely no interest in supporting any userspace hooks
>>> in nvmet.
>>
>> Don't think we are discussing adding anything specific to nvmet, a
>> userspace backend will most likely sit behind a block device exported
>> via nvmet (at least from my perspective). Although I do see issues
>> with using the passthru interface...
>>
>>> If you want a userspace nvme implementation please use SPDK.
>>
>> The original use-case did not include nvmet, I may have stirred
>> the pot saying that we have nvmet loopback instead of a new kind
>> of device with a new set of tools.
>>
>> I don't think that spdk meets even the original android use-case.
>>
>> Not touching nvmet is fine, it just eliminates some of the possible
>> use-cases. Although personally I don't see a huge issue with adding
>> yet another backend to nvmet...
> 
> After discussing with google for the r/w/flush use-case (cloud, not
> android), they are interested in avoiding the source of complexity that
> arises from implementing the NVMe protocol in the interface.  Even if it
> is hidden behind a userspace library, it means converting block
> rq->nvme->block rq, which might have a performance impact?
> 
>  From your previous message, I think we can move forward with dissociating
> the original use case from nvme passthrough, and have the userspace hook
> as a block driver?

Yes, there is no desire to do that.