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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 23, 2022 at 10:30:25AM +0100, Cornelia Huck wrote:
> 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.

I think it's one or two for now, yes. E.g. we could use
one for SRIOV and one for the (TBD) SIOV.


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