On Thu, May 09, 2019 at 02:27:10PM +0200, Gerd Hoffmann wrote:
> > For the sake of the specification I think we need to focus on is how to
> > transport these streams and how to share a configuration for each one.
>
> I think we need at least three virt queues. One control queue for
> commands (query capabilities, set configuration, start/stop streams,
> volume control, ...). One queue for input streams. One queue for
> output streams.
>
> If we want allow for multiple inputs/outputs we have basically two
> options: (a) one queue per stream, or (b) use a small header for each
> data packet, telling what stream it belongs to.
>
> Maybe a small header is a good idea anyway, for timestamps.
I agree with the 3 virtqueue layout.
Multiplexing streams over a single input/output virtqueue pair has pros
and cons. Overall I think it's a good fit though:
+ Number of streams can change at runtime (virtqueues are static!)
+ Easy to handle multiple inputs/outputs
+ Ability to synchronize streams, including transferring buffers for
multiple streams in a single message with a single timestamp
- Virtqueue must be sized to handle maximum simultaneous streams without
running out of descriptors
- Extra latency (jitter) and locking requirements due to sharing
virtqueues between streams even if they are processed on different
vCPUs
Stefan
