OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Re: [RFC PATCH v6] virtio-video: Add virtio video device specification


On Fri, Apr 28, 2023 at 5:55âPM Alexander Gordeev
<alexander.gordeev@opensynergy.com> wrote:
>
> On 28.04.23 06:02, Alexandre Courbot wrote:
> > This is going to be my last answer to this thread ; I don't think I
> > have more technical arguments to give than I already have and the
> > discussion is drifting into territory I am not interested in engaging.
> > At the end of the day it's up to the virtio folks to make a decision
> > about what the best course of action is. If we end up with
> > fragmentation, so be it, it will still be better than the current
> > situation anyway.
>
> I agree with the summary. I think we have discussed all the things in
> depth and even reached some understanding.
> Could you please at least share your feedback on my proposal for the
> QUEUE/DRAIN completion handling?

Well I've re-read your email once more and again I confirm, this is
exactly what virtio-v4l2 does. Here is the code that sends the dequeue
buffer event on the event queue after a buffer is dequeued on the
host: https://github.com/Gnurou/crosvm/blob/virtio-v4l2/devices/src/virtio/v4l2/worker.rs#L1114.

IOW, there are no VIDIOC_DQBUF or VIDIOC_DQEVENT (or any command that
can block) taking place between the guest and host, these are sent to
the guest as events.

And yes, this design simplifies things quite a bit vs. retaining
command descriptors until some operation completes. Beyond the
increased potential for deadlock, there is also added complexity as
the descriptors must eventually be returned to the guest, even if the
requested operation is interrupted. This increases the amount of state
on the host which must keep track of pending operations and cancel
some on occasion (which is pretty error-prone), whereas having all
commands complete without delay could theoretically let us function
even with a single command descriptor. Retaining the descriptors was
supposed to reduce host/guest traffic a bit, but at that level of
interaction (60 ops/second for a high framerate video) I don't think
it's worth the cost.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]