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

[äèä <houyingle@sudoinfotech.com>]

Wed, 18 Jan 2023 09:14:41 -0500, Stefan wrote:

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



During the DPU chip design process, "Fabrics connect" commands are not supported on standard nvme-pci devices,
but I can be delivered to remote storage at the back-end of the nvme-pci device.

In the case of a virtio-blk device, I am not clear how the back-end of virtio-blk connects to remote storage.Although
NVIDIA claims to support virtio-blk SNAP (Software-defined Network Accelerated Processing), their implementation
is not expected to be an open source standard, other vendors may have developed based on proprietary specifications.



All of this is from a hardware offloading perspective. There are two solutions to the problem I'm facing:
1) virtio combines nvme, add a new virtio-nvme device.
2) virtio-blk Adds Fabrics related commands to enable virtio-blk to support Virtio-blk-of (over Fabric).