RE: [virtio-dev] Request for a new device number for a virtio-audio device.

[Anton Yakovlev <Anton.Yakovlev@opensynergy.com>]

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

And the only source of information in such case is to take a look into already existed implementations?


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

Personally, I'm not a big fan of, because:

1. It makes overall logic more complex: you need to serialize access to the queue on driver side and dispatch messages (find out recepient, serialize access etc) on device side. With separated queues you have only one producer and consumer, and they both knows ahead how to handle buffers.
2. It requires to define message header for buffer transfers. With separated queues you just put into descriptors a pointer to the buffer and its length.

The simpler the better. And with multiplexing basically you have no pros except having one queue. Why separated queues are undesirable?


--
Anton Yakovlev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

www.opensynergy.com

Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>
COQOS Hypervisor certified by TÜV SÜD
                [COQOS Hypervisor certified by TÜV SÜD]

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org