Sagi Grimberg <sagi@xxxxxxxxxxx> writes: >> 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?
