Max Gurtovoy <mgurto...@nvidia.com> writes: > On 08/03/2023 14:08, Jiri Pirko wrote: >> Wed, Mar 08, 2023 at 12:50:48PM CET, m...@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, m...@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. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
