On Wed, May 15, 2019 at 06:30:45AM +0000, Anton Yakovlev wrote:
> >> So, our proposal is to support classic way of communications by default and introduce shared memory based approach as either non-standard extension or part of future VIRTIO device types. And switch to this mode where it's possible or make sense. Like, all modern type-2 hypervisors usually have no problems with sharing memory between guest and host, so why not provide to user high quality virtual audio device?
> >
> > virtqueues offer reliable delivery, so #2 isn't an issue.
> >
> > Real-time is achievable and can be done with low latency.  Make the
> > receiver a real-time thread that polls the vring periodically (based on
> > the latency/buffer size requirement).  The vring supports lock-free
> > access so this is perfect for real-time.
> >
> > When I say "receiver" I mean the driver's capture and device's playback
> > components.  Both of them have real-time requirements.
> >
> > Does this approach meet your requirements?
> 
> After careful consideration, I think polling mode should make it possible. Like, using dedicated "data" queue per stream in polling mode (multiplexing is not an option, since it reduces queue throughput in proportion to the number of multiplexed streams). How to describe it in specification?

Polling is an implementation detail for both drivers and devices.
Therefore it's not described explicitly in the specification.

By the way, virtqueue buffers can be completed out-of-order by the
device.  This means sharing a virtqueue between multiple streams does
not necessarily introduce any kind of waiting.

The only issue is the virtqueue size (e.g. 128 buffers) determines how
many buffers can be made available from the driver to the device at any
given time.  Some device implementations uses virtqueue sizes like 1024
so that this does not become a practical concern.  Does this change your
view on multiplexing streams?

Stefan