[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access
> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]