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

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

Max Gurtovoy <mgurtovoy@nvidia.com> writes:

> On 08/03/2023 14:08, Jiri Pirko wrote:
>> Wed, Mar 08, 2023 at 12:50:48PM CET, mst@redhat.com wrote:
>>> On Wed, Mar 08, 2023 at 11:05:00AM +0100, Jiri Pirko wrote:
>>>> Tue, Mar 07, 2023 at 05:30:18PM CET, mst@redhat.com wrote:
>>>>> On Tue, Mar 07, 2023 at 08:36:41AM +0100, Jiri Pirko wrote:
>>>>>> Hmm, if not for now, the future exension would not be so simple, I fear.
>>>>>
>>>>> Without knowing what it is I can't say.
>>>>
>>>> Yep, so basically you say, for other things if they appear,
>>>> let's introduce another queue type? If yes, sounds fair to me.
>>>
>>> Yes. For example I find it likely that live migration/failover support
>>> will require a queue where driver pre-adds buffers and then device
>>> supplies information as state changes.
>> 
>> I see. So there would be a queue called for example "child state virtqueue"
>> or something like that for the sole purpose of getting the state of VF?
>> Hmm, wouldn't it make more sense to have this done as a part of "group
>> administrarion queue"? I mean, there is already notion of addresing
>> child/VF here. So from my perspective, it is just another "group
>> administration" command.
>
> For sure VF Live Migration, MSIX config of VF, VF feature bits config 
> and others should be admin commands on admin vq.
> I don't see any reason introducing another type of admin-like vq.
> Also we don't need to have multiple admin vqs. This AQ is not aimed for 
> performance.

In support of live migration, might we end up moving large amounts of
device state through the admin queue?

If so, that would seem to have some performance requirements, though I
don't know if it would justify multiple admin queues.
-- 
Tonight I think I'll walk alone, I'll find my soul as I go home.