RE: [virtio-comment] Re: [virtio] [PATCH v10 04/10] admin: introduce virtio admin virtqueues

[David Edmondson <david.edmondson@oracle.com>]

Parav Pandit <parav@nvidia.com> writes:

>> From: Jiri Pirko <jiri@nvidia.com>
>> Sent: Thursday, March 9, 2023 2:31 AM
>> 
>> Wed, Mar 08, 2023 at 10:25:32PM CET, parav@nvidia.com wrote:
>> >
>> >> From: virtio-comment@lists.oasis-open.org
>> >> <virtio-comment@lists.oasis- open.org> On Behalf Of David Edmondson
>> >
>> >> In support of live migration, might we end up moving large amounts of
>> >> device state through the admin queue?
>> >>
>> >Correct.
>> >
>> >> If so, that would seem to have some performance requirements, though
>> >> I don't know if it would justify multiple admin queues.
>> >DMA of the data through the proposed AQ is supported.
>> >
>> >If I understood Max correctly when Max said " This AQ is not aimed for
>> >performance ", he means that AQ doesn't have performance requirements as
>> io/network queues to complete millions of ops/sec.
>> >
>> >it is several hundred to maybe (on the higher side) thousand ops/sec during
>> LM, provisioning use case.
>> 
>> But isn't it good to design it for performance from start? I mean, state transfer
>> of thousands of VFs at a time is definitelly performance related, isn't it?
>> 
> It is. Which part of the proposed AQ doesn't cover this aspect?
> The only issue that I see today is, that a given GET family of commands q contains the read-only and write-only descriptors which require multiple dma allocations on driver side.

I don't think that there is any assertion that the current proposal
doesn't cover this.

It was intended as an illustration to try and help determine whether
multiple AQs for a single device was a requirement given existing
anticipated usage, or a safeguard against potential future uses.
-- 
Up eighty flights of stairs to a basement flat.

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/