[virtio-dev] Re: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices

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

On Fri, Aug 04, 2023 at 02:12:41PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Friday, August 4, 2023 7:37 PM
> 
> > > True, for us, at this point we do not have plan to expose virtio switch device
> > because users are not blocked on it.
> > 
> > If someone does though I see no reason not to - we have a variety of devices,
> > switch would be just another one. The motivation would be the usual one for
> > virtio - so there's one generic driver.
> >
> Sure.
>  
> > > > Re:queues - it's not by chance that we have multiple admin queues.
> > > > So driver can dedicate one queue to filtering commands if that's
> > > > felt to be important.
> > > >
> > > Admin queue currently do not send non admin command of the device.
> > > Would you propose admin queue for something else also for rtc or console or
> > cryto device and indicate its role so device can understand what is coming to it.
> > 
> > Well, I guess this switch has group members as its "ports" so maybe that makes
> > it like an admin command. Again it's all up in the air too much to be able to
> > judge.
> 
> Flowvq is needed for non switch device too.
> It has advanced to design stage now, its sad that you are no following it.

Frankly I didn't even understand that's what this is talking about.

> Anyways, flow operations is not a admin command.
> I don't find admin queue suitable for self unless we modify its definitions a lot.


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