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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

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


Subject: Re: [RFC PATCH] Introduce admin virtqueue as a new transport


On Wed, Aug 04, 2021 at 04:39:24PM +0800, Jason Wang wrote:
> å 2021/8/4 äå2:39, Stefan Hajnoczi åé:
> > On Wed, Aug 04, 2021 at 11:01:39AM +0800, Jason Wang wrote:
> > > å 2021/8/3 äå10:51, Stefan Hajnoczi åé:
> > > > On Tue, Aug 03, 2021 at 11:20:06AM +0800, Jason Wang wrote:
> > > > > +\subsection{Admin Virtqueue Capabilities}\label{sec:Virtio Transport Options / Virtio Over Admin Virtqueue / Admin Virtqueue Capabilities}
> > > > > +
> > > > > +The capabilites that are supported by the admin virtqueue could be
> > > > > +fetched through the following commands:
> > > > > +
> > > > > +\begin{lstlisting}
> > > > > +#define VIRTIO_ADMIN_CTRL_CAP    0
> > > > > + #define VIRTIO_ADMIN_CTRL_CAP_GET        0
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +The VIRTIO_ADMIN_CTRL_CAP_GET is used to get the capabilites that are
> > > > > +supported by the admin virtqueue through a u64 which is a bit mask of
> > > > > +the capabilies in command-in-data. There's no command-out-data.
> > > > I'm not sure what this paragraph is describing. Is VIRTIO_ADMIN_CTRL_CAP
> > > > a struct virtio_admin_ctrl::command value?
> > > 
> > > VIRTIO_ADMIN_CTRL_CAP is the class, VIRTIO_ADMIN_CTRL_CAP_GET is the
> > > command.
> > Okay. I found the admin virtqueue command descriptions hard to read, not
> > just because the class/command definitions weren't obvious to me, but
> > also because the command/response layout is described in English instead
> > of a table or C-like notation.
> > 
> > I think something like this would make the commands easier to
> > understand:
> > 
> >    Capabilities supported by the admin virtqueue are fetched as follows:
> > 
> >    Driver->Device:
> >    Field       Value                          Type
> >    -----------------------------------------------
> >    device_id   0                              u64
> >    class       VIRTIO_ADMIN_CTRL_CAP (0)      u16
> >    command     VIRTIO_ADMIN_CTRL_CAP_GET (0)  u16
> > 
> >    Device->Driver:
> >    Field         Value                        Type
> >    -----------------------------------------------
> >    ack           VIRTIO_ADMIN_OK (0)          u8
> >    capabilities  <supported capability bits>  u64
> 
> 
> I just follows styles that is used in virtio-net control vq:
> 
> 
> \begin{lstlisting}
> #define VIRTIO_NET_CTRL_MQÂÂÂ 4
> Â#define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SETÂÂÂÂÂÂÂ 0 (for automatic receive
> steering)
> Â#define VIRTIO_NET_CTRL_MQ_RSS_CONFIGÂÂÂÂÂÂÂÂÂ 1 (for configurable receive
> steering)
> Â#define VIRTIO_NET_CTRL_MQ_HASH_CONFIGÂÂÂÂÂÂÂÂ 2 (for configurable hash
> calculation)
> \end{lstlisting}
> 
> ...
> 
> Do you suggest to change that as well?

My preference is to change it because I think describing inputs/outputs
in English makes it hard to understand the exact binary layout.

> 
> 
> > 
> > > > Another question: I wonder why there is an admin virtqueue feature bit
> > > > instead of a new VIRTIO device ID for the management device? Does this
> > > > mean regular virtio-net, virtio-blk, etc devices can have an admin queue
> > > > in addition to their normal role?
> > > 
> > > I think so, I just follow the normal networking PF role which is usually a
> > > network device which allows some kind of remote management.
> > > 
> > > But it doesn't forbid us to create the management device.
> > > 
> > > I think it's better to not mandate the management device for now, or is
> > > there any reason for doing that?
> > Since the admin virtqueue is generic infrastructure (not specific to
> > vdev management) I think it makes sense to use a feature bit and not a
> > separate management device. This wasn't obvious to me from this
> > document, maybe the text can be tweaked to clearly separate the
> > (generic) admin virtqueue from vdev management.
> 
> 
> Maybe adding a device normative like
> 
> "
> 
> The management device MUST offer the admin virtqueue is a device specific
> virtqueue.
> 
> "

Yes, with
s/is/as/

Attachment: signature.asc
Description: PGP signature



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