>
From: Michael S. Tsirkin <>
> 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?
