[virtio-dev] Re: [PATCH v8 4/9] admin: introduce virtio admin virtqueues

[Cornelia Huck <cohuck@redhat.com>]

On Tue, Nov 22 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Tue, Nov 22, 2022 at 02:14:23PM +0100, Cornelia Huck wrote:
>> On Sun, Nov 20 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> > +Administration virtqueues exists for a certain owner device if
>> > +VIRTIO_F_ADMIN_VQ feature has been negotiated. The index of the
>> > +first administration virtqueue and their number is exposed by the
>> > +owner device in a transport specific manner.
>> 
>> (Do we always expect admin virtqueues to use a range of indices, i.e. no
>> holes? That seems a bit limiting.)
>
> For the device?
> I frankly feel it's enough, yea.

About how many admin virtqueues per device are we thinking for current
use cases, anyway? If it's usually just one or two, the range would not
really be limiting.

>
>> What about
>> 
>> "If VIRTIO_F_ADMIN_VQ has been negotiated, an owner device exposes one
>> or more adminstration virtqueues. The number and locations of the
>> administration virtqueues is exposed by the owner device in a transport
>> specific manner."
>
>
>
>
>> > +
>> > +The driver submits commands by queueing them to an arbitrary
>> > +administration virtqueue, and they are processed by the
>> > +device in the order in which they are queued. It is the
>> > +responsibility of the driver to ensure ordering for commands
>> > +placed on different administration virtqueues, because they will
>> > +be executed with no order constraints.
>> 
>> Are all admin vqs supposed to be equal? Could a device expose e.g. a
>> high prio admin vq and a normal prio admin vq?
>
>
> ATM yes, for priority we'll need a separate capability. Work on top?

Ok, if we don't need it now, we can add it later.


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