On 4/24/2023 9:38 AM, zhenwei pi wrote:
From the point of my view, there are 3 cases:
1, Host/container scenario. For example, host kernel connects a virtio
target block service, maps it as a vdx(virtio-blk) device(used by
Map-Reduce service which needs a fast/large size disk). The host kernel
also connects a virtio target crypto service, maps it as virtio crypto
device(used by nginx to accelarate HTTPS). And so on.
+----------+ +----------+ +----------+
|Map-Reduce| | nginx | ... | processes|
+----------+ +----------+ +----------+
------------------------------------------------------------
Host | | |
Kernel +-------+ +-------+ +-------+
| ext4 | | LKCF | | HWRNG |
+-------+ +-------+ +-------+
| | |
+-------+ +-------+ +-------+
| vdx | |vCrypto| | vRNG |
+-------+ +-------+ +-------+
| | |
| +--------+ |
+---------->|TCP/RDMA|<------------+
+--------+
|
+------+
|NIC/IB|
+------+
| +-------------+
+--------------------->|virtio target|
+-------------+
2, Typical virtualization environment. The workloads run in a guest, and
QEMU handles virtio-pci(or MMIO), and forwards requests to target.
+----------+ +----------+ +----------+
|Map-Reduce| | nginx | ... | processes|
+----------+ +----------+ +----------+
------------------------------------------------------------
Guest | | |
Kernel +-------+ +-------+ +-------+
| ext4 | | LKCF | | HWRNG |
+-------+ +-------+ +-------+
| | |
+-------+ +-------+ +-------+
| vdx | |vCrypto| | vRNG |
+-------+ +-------+ +-------+
| | |
PCI --------------------------------------------------------
|
QEMU +--------------+
|virtio backend|
+--------------+
|
+------+
|NIC/IB|
+------+
| +-------------+
+--------------------->|virtio target|
+-------------+
Example #3 enables to implement virtio backend over fabrics initiator in
the user space, which is also a good use case.
It can be also be done in non native virtio backend.
More below.
3, SmartNIC/DPU/vDPA environment. It's possible to convert virtio-pci
request to virtio-of request by hardware, and forward request to virtio
target directly.
+----------+ +----------+ +----------+
|Map-Reduce| | nginx | ... | processes|
+----------+ +----------+ +----------+
------------------------------------------------------------
Host | | |
Kernel +-------+ +-------+ +-------+
| ext4 | | LKCF | | HWRNG |
+-------+ +-------+ +-------+
| | |
+-------+ +-------+ +-------+
| vdx | |vCrypto| | vRNG |
+-------+ +-------+ +-------+
| | |
PCI --------------------------------------------------------
|
SmartNIC +---------------+
|virtio HW queue|
+---------------+
|
+------+
|NIC/IB|
+------+
| +-------------+
+--------------------->|virtio target|
+-------------+
All 3 seems a valid use cases.
Use case 1 and 2 can be achieved directly without involving any
mediation layer or any other translation layer (for example virtio to nfs).
Many blk and file protocols outside of the virtio already exists which
achieve this. I don't see virtio being any different to support this in
native manner, mainly the blk, fs, crypto device.
use case #3 brings additional a benefits at the same time different
complexity but sure #3 is also a valid and common use case in our
experiences.
In my experience working with FC, iSCSI, FCoE, NVMe RDMA fabrics, iSER,
A virito fabrics needs a lot of work to reach the scale, resiliency and
lastly the security. (step by step...)
My humble suggestion is : pick one transport instead of all at once,
rdma being most performant probably the first candidate to see the perf
gain for use case #1 and #2 from remote system.
I briefly see your rdma command descriptor example, which is not aligned
to 16B. Perf wise it will be poor than nvme rdma fabrics.
For PCI transport for net, we intent to start the work to improve
descriptors, the transport binding for net device. From our research I
see that some abstract virtio descriptors are great today, but if you
want to get best out of the system (sw, hw, cpu), such abstraction is
not the best. Sharing of "id" all the way to target and bring back is an
example of such inefficiency in your example.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org