From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Parav Pandit Subject: RE: [PATCH v2 1/4] Add virtio Admin Virtqueue Date: Thu, 27 Jan 2022 03:55:05 +0000 Message-ID: References: <20220124093918.34371-1-mgurtovoy@nvidia.com> <20220124093918.34371-2-mgurtovoy@nvidia.com> <20220126093659-mutt-send-email-mst@kernel.org> In-Reply-To: <20220126093659-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: "Michael S. Tsirkin" , Max Gurtovoy Cc: "virtio-comment@lists.oasis-open.org" , "cohuck@redhat.com" , "virtio-dev@lists.oasis-open.org" , "jasowang@redhat.com" , Shahaf Shuler , Oren Duer , "stefanha@redhat.com" List-ID: > From: Michael S. Tsirkin > Sent: Wednesday, January 26, 2022 8:11 PM >=20 > On Mon, Jan 24, 2022 at 11:39:15AM +0200, Max Gurtovoy wrote: > > +Regardless of device offering VIRTIO_F_IN_ORDER, admin queue command > > +buffers are used by the device in out of order manner. >=20 > Instead of special-casing AQ I'd like to see a generic capability address= ing this > need. For example, TX for virtio net might benefit from this too. And I'd= like to > mention, again, VIRTIO_F_PARTIAL_ORDER proposal as one, arguably cleaner > and more generic way to address this. > And if that's not adequate I'd like to address that as part of the > PARTIAL_ORDER proposal, this kind of per-queue in order was definitely on > the radar as it was formulated. As we dropped other less important items from this proposal because it was = too big. I am going to keep the PARTIAL_ORDER also out of this one. It falls in same= bucket. So AQ follows same ordering rules as other queues. Are you ok with this in v3?