virtio — archive

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

From: David Edmondson <[email protected]>
To: [email protected]
Date: Thu, 09 Mar 2023 14:03:00 -0000

Parav Pandit <[email protected]> writes: >> From: Jiri Pirko <[email protected]> >> Sent: Thursday, March 9, 2023 2:31 AM >> >> Wed, Mar 08, 2023 at 10:25:32PM CET, [email protected] wrote: >> > >> >> From: [email protected] >> >> <[email protected] 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.