RE: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access

[Parav Pandit <parav@nvidia.com>]

> From: Parav Pandit
> Sent: Tuesday, June 20, 2023 10:12 AM
> 
> Michael,
> 
> > From: Parav Pandit <parav@nvidia.com>
> > Sent: Monday, June 19, 2023 2:07 PM
> > We don't need to do it now.
> >
> > > Current VF capability is kind of ok I guess ...
> > >
> > Already proposed one?
> >
> > > If you want admin command to query then it would need to map in PF
> > memory.
> > No need.
> > It is similar to rest of the configuration access commands.
> >
> > > I understand two concerns with this:
> > > - you worry that this forces ordering requirements - it's true and I
> > >   don't know of a good fix. So if possible use VF BAR by preference?
> > > - you worry about wasting physical memory space
> > >   this we can fix by sticking VF# in the kick.
> > >
> > > As an alternative, if we can make the new command able to
> > > communicate offset in PCI BAR or in VF BAR or both then I think
> > > that's also an acceptable
> >
> > A new command proposed was for VF BAR that member driver can ask to
> > its group owner driver (like rest of the config commands).
> >
> 
> Are you ok with the admin command to query the notification address of the
> member device bar?
> 
> I presented both the proposals.
> We need to conclude this now without keep flipping between two from version
> to version.
> 
> a. v3 with admin command
> pros:
> 1. self-contained via AQ for rest of the control path operations.
> 2. Can work with future siov device who may want to support legacy 3. Doesn't
> bake things in low level pci capabilities which is hard to get rid of 4. Able to add
> new command or new response if some device wants to support this on PF
> (very unlikely)
> 
Given that this has more pros and no objection to it, 
I will revise v7 today with query admin command like v3.

> b. and v6 with capability extension.
> Cons:
> 1. Does not have above advantages
> 
> Pros:
> 1. Uses existing PCI capability for the extension
> 
> 
> > A future command can tell for the PF BAR if needed and some device
> > wants to do such extra implementation.
> >
> > > compromize:
> > > drivers that have trouble mapping VF BAR after querying PF can just
> > > map PF BAR. WDYT?
> >
> > PF BAR for notification can be done later when there is some device
> > who really have the limitation and wants to do that.
> > We don't see that additional need as driver notifications are present
> > on the VF already as listed in the alternative.