* Arnd Bergmann via Stratos-dev stratos-dev@op-lists.linaro.org [2020-10-12 15:56:01]:
Yes, my rough idea would be to stay as close as possible to the existing virtio/virtqueue design, but replace the existing descriptors pointing to guest physical memory with TLV headers describing the data in the ring buffer itself. This might not actually be possible, but my hope is that we can get away with making the ring buffer large enough for all data that needs to be in flight at any time, require all data to be processed in order,
I had the impression that virtio allows out-of-order processing of requests i.e requests can be completed not strictly in FIFO order. I think your proposed virtqueue design should still allow that?
Also I think reserving 512kB of memory per virtqueue may not be acceptable in all cases. Some device virtqueue could be more busy than other at a given time - the busy virtqueue fills up fast and stalls for more memory to become available, while there is free memory available with other device virtqueues. A global (swiotlb) pool shared among multiple devices would allow for better sharing of available memory in that sense. For memory constrained configurations, a global shared pool may be desirable solution (vs dedicating per-virtqueue buffers of fixed size).