Re: [virtio-comment] About adding a new device type virtio-nvme

[Stefan Hajnoczi <stefanha@redhat.com>]

On Thu, Jan 19, 2023 at 11:40:02AM +0800, Jason Wang wrote:
> 
> å 2023/1/18 22:14, Stefan Hajnoczi åé:
> > On Wed, Jan 18, 2023 at 10:15:12AM +0800, äèä wrote:
> > > On Tue, 17 Jan 2023 10:34:09 -0500, Stefan wrote:
> > > > On Tue, Jan 17, 2023 at 05:41:57PM +0800, äèä wrote:
> > > > > On Tue, 17 Jan 2023 09:32:05 +0100ïDavid wroteï
> > > > > > On 17.01.23 03:04, äèä wrote:
> > > > The two diagrams are quite similar. Did you want to highlight a
> > > > difference between the two approaches in the diagram?
> > > The biggest difference is the VFIO and vDPA frameworks. The vDPA (virtio data path acceleration) kernel framework
> > > is a pillar in productizing the end-to-end vDPA solution and it enables NIC vendors to integrate their vDPA NIC kernel
> > > drivers into the framework as part of their productization efforts.
> > > Detailed information referenceïhttps://www.redhat.com/en/blog/introduction-vdpa-kernel-framework
> > For the sake of the argument, let's assume VFIO can't be used in your
> > situation so vDPA is required. The part I don't understand is which
> > specific NVMe features you need that virtio-blk lacks?
> 
> 
> I can think one:
> 
> Avoid guest application migration from NVMe to virtio-blk?

To get the best fidelity in that situation NVMe PCI would be the natural
choice. For example, if the application is SPDK then it won't just work
with virtio-nvme because it has a userspace NVMe PCI driver.

There might be applications that break when moving from NVMe to
virtio-blk but don't depend on NVMe PCI, but it seems like a very niche
case.

Most applications don't use NVMe directly or if they do, then they speak
NVMe PCI or NVME over TCP directly, so they won't work with virtio-nvme.

Stefan

Attachment: signature.asc
Description: PGP signature