virtio — archive

[PATCH v10 00/10] Introduce device group and device management

From: Parav Pandit <[email protected]>
To: [email protected]
Date: Thu, 09 Mar 2023 16:54:00 -0000

> From: Michael S. Tsirkin <[email protected]> > Sent: Thursday, March 9, 2023 9:43 AM > > > > > Ok. so there may be some use case for transport VQ. > > Worth to mention in the cover letter and things will be fine. > > Actual review of the transport VQ and its use will be in the respective > patchset. > > > > > > 2. Having the infrastructure to support multiple AQ is also good. > > > > The extra cost of this infra is only one read-only field = aq > > > > count as Michael > > > proposed. > > > > > > > > 3. Ability to send multiple outstanding commands and execute them > > > > out of > > > order by device is/should be supported as long as IN_ORDER is not > negotiated. > > > > Should it be relaxed for AQ that even if IN_ORDER is negotiated, > > > > AQ by > > > default can be out of order queue? > > > > > > I feel there's no need: driver can just avoid negotiating IN_ORDER. > > I didn't understand the "no need" part. > > Do you mean to make use of out-of-order AQ commands, driver should skip > IN_ORDER negotiation for the data path queues? > > If yes, it may not be a big loss for the PF. > > > > I am considering that since AQ is so fresh, it can keep itself detached from > the IN_ORDER from the beginning. > > This way AQ and data path queues stay on their own course. > > You can make this claim for different types of data queues too. Those queues are already defined. Without any new feature bit, not sure how can it change. > I'd rather try to solve it for all queues than special-case AQ. > AQ is newly introduce which has chance of not follow the same limitations as existing queues. Keeping my inputs aside for moment, what do you propose for v11?