[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]