Re: [virtio-comment] Re: [virtio] RE: [virtio-comment] proposal: use admin command (and aq) of the device to query config space

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Aug 02, 2023 at 11:44:46AM +0000, Parav Pandit wrote:
> 
> 
> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> > open.org> On Behalf Of Michael S. Tsirkin
> > Sent: Wednesday, August 2, 2023 5:09 PM
> 
> 
> > > Sure, device config is the real pain point we are trying to solve first.
> > >
> > > Using cvq for those devices who has it seems the most optimal approach.
> > > If we liberate ourselves from single monolithic config space structure and
> > move to query device capabilities, resources, configuration, at functionality
> > level, life is lot easier.
> > > What are your thoughts?
> > 
> > Splitting transport and device config is exactly what I'm talking about.
> > I agree transport should probably be split further - it only made sense for legacy
> > so we don't need to spend specification effort on legacy.
> > splitting device config would require changes to all devices - I don't see how it's
> > worth the effort.
> 
> Maybe I was not clear in my idea.
> We have canned ourselves as config means _one_ structure.
> Due to this thought process, all these transport and things muddy the view.
> 
> If one think of functionality-based config, there is no one structure, hence no need to limit ourselves to it.
> Taking concrete example,
> 
> We have separate commands for,
> a. RSS config
> b. filters
> c. notification coalescing
> 
> When you have matching get command, then each functionality grows by their own get command and no need to put in single box of single config structure.
> 
> Every device will be able to grow to dynamic need as/if it arise.
> 
> 
> 
> 

There's one thing to say about putting everything in one place,
and that is that one can then find everything in one place.
For example, at the moment we actually do have a problem with cvq,
and the problem is that it sets internal device state
that is not observable (unlike original pre-1.0 config
space which was writeable).


By the way there's a pci express ECN for relaxed ordering or something
like this. I am yet to look at it, I wonder whether it can be
used to avoid the issues we have with MMIO in a way
that is easier to use than DMA.


-- 
MST