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

From: Sagi Grimberg <sagi@grimberg.me>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Hannes Reinecke <hare@suse.de>,
	Bart Van Assche <bvanassche@acm.org>,
	Mike Christie <michael.christie@oracle.com>,
	lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] block drivers in user space
Date: Thu, 24 Mar 2022 19:05:48 +0200	[thread overview]
Message-ID: <692ef2af-240e-9682-5530-5d55e49797d5@grimberg.me> (raw)
In-Reply-To: <87bkxwqwvn.fsf@collabora.com>

>>> 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.