OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage


On Fri, Oct 27, 2023 at 03:37:20PM +0200, Cornelia Huck wrote:
> >> > Out of 19 devices, 6 devices already has cvq.
> >> > Out of remaining 13 devices, 12 devices have fixed number of queues as they
> >> small enough in functionality that won't need a scale and dynamism either.
> >> > So for dynamic resource management reusing the existing cvq is more
> >> efficient for the devices.
> >> 
> >> They have a device-specific cvq, which is used in a device-specific way for
> >> device-specific purposes. I don't see how turning them into frankencvqs is
> >> "efficient".
> > Sure, they are device specific, but we can define generic set of commands in basic facilities, which each device type can send via their cvq.
> > It is only matter of drafting it.
> 
> Nope, it's also a matter of implementing it, and wedging in something
> sidewards does not sound like a good design to me.

Yep. The issue is that it's a generic thing and belongs in a
generic section. Then having a device specific mechanism
to trigger this just makes a smoothie out of our layering structure.
Which if done for a good reason could be tolerated, but there's
no good reason here that I see.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]