* Re: [PATCH net-next v2 0/2] sfc: Add EF100 BAR config support [not found] <165719918216.28149.7678451615870416505.stgit@palantir17.mph.net> @ 2022-07-07 15:55 ` Bjorn Helgaas [not found] ` <Yswn7p+OWODbT7AR@gmail.com> 0 siblings, 1 reply; 3+ messages in thread From: Bjorn Helgaas @ 2022-07-07 15:55 UTC (permalink / raw) To: Martin Habets Cc: netdev, virtualization, ecree.xilinx, edumazet, linux-pci, kuba, pabeni, davem On Thu, Jul 07, 2022 at 02:07:07PM +0100, Martin Habets wrote: > The EF100 NICs allow for different register layouts of a PCI memory BAR. > This series provides the framework to switch this layout at runtime. > > Subsequent patch series will use this to add support for vDPA. Normally drivers rely on the PCI Vendor and Device ID to learn the number of BARs and their layouts. I guess this series implies that doesn't work on this device? And the user needs to manually specify what kind of device this is? I'm confused about how this is supposed to work. What if the driver is built-in and claims a device before the user can specify the register layout? What if the user specifies the wrong layout and the driver writes to the wrong registers? > --- > > Martin Habets (2): > sfc: Add EF100 BAR config support > sfc: Implement change of BAR configuration > > > drivers/net/ethernet/sfc/ef100_nic.c | 80 ++++++++++++++++++++++++++++++++++ > drivers/net/ethernet/sfc/ef100_nic.h | 6 +++ > 2 files changed, 86 insertions(+) > > -- > Martin Habets <habetsm.xilinx@gmail.com> > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <Yswn7p+OWODbT7AR@gmail.com>]
* Re: [PATCH net-next v2 0/2] sfc: Add EF100 BAR config support [not found] ` <Yswn7p+OWODbT7AR@gmail.com> @ 2022-07-11 22:00 ` Bjorn Helgaas [not found] ` <20220711114806.2724b349@kernel.org> 1 sibling, 0 replies; 3+ messages in thread From: Bjorn Helgaas @ 2022-07-11 22:00 UTC (permalink / raw) To: davem, kuba, pabeni, edumazet, netdev, ecree.xilinx, linux-pci, virtualization On Mon, Jul 11, 2022 at 02:38:54PM +0100, Martin Habets wrote: > On Thu, Jul 07, 2022 at 10:55:00AM -0500, Bjorn Helgaas wrote: > > On Thu, Jul 07, 2022 at 02:07:07PM +0100, Martin Habets wrote: > > > The EF100 NICs allow for different register layouts of a PCI memory BAR. > > > This series provides the framework to switch this layout at runtime. > > > > > > Subsequent patch series will use this to add support for vDPA. > > > > Normally drivers rely on the PCI Vendor and Device ID to learn the > > number of BARs and their layouts. I guess this series implies that > > doesn't work on this device? And the user needs to manually specify > > what kind of device this is? > > When a new PCI device is added (like a VF) it always starts of with > the register layout for an EF100 network device. This is hardcoded, > i.e. it cannot be customised. > The layout can be changed after bootup, and only after the sfc driver has > bound to the device. > The PCI Vendor and Device ID do not change when the layout is changed. > > For vDPA specifically we return the Xilinx PCI Vendor and our device ID > to the vDPA framework via struct vdpa_config_opts. > > > I'm confused about how this is supposed to work. What if the driver > > is built-in and claims a device before the user can specify the > > register layout? > > The bar_config file will only exist once the sfc driver has bound to > the device. So in fact we count on that driver getting loaded. > When a new value is written to bar_config it is the sfc driver that > instructs the NIC to change the register layout. > > > What if the user specifies the wrong layout and the > > driver writes to the wrong registers? > > We have specific hardware and driver requirements for this sort of > situation. For example, the register layouts must have some common > registers (to ensure some compatibility). Obviously we have to deal with the hardware as it exists, but it seems like a hardware design problem that you can change the register layout but the change is not detectable via those common registers. Anyway, it seems weird to me, but doesn't affect the PCI core and I won't stand in your way ;) > A layout that is too different will require a separate device ID. > A driver that writes to the wrong register is a bug. > > Maybe the name "bar_config" is causing most of the confusion here. > Internally we also talk about "function profiles" or "personalities", > but we thought such a name would be too vague. > > Martin > > > > --- > > > > > > Martin Habets (2): > > > sfc: Add EF100 BAR config support > > > sfc: Implement change of BAR configuration > > > > > > > > > drivers/net/ethernet/sfc/ef100_nic.c | 80 ++++++++++++++++++++++++++++++++++ > > > drivers/net/ethernet/sfc/ef100_nic.h | 6 +++ > > > 2 files changed, 86 insertions(+) > > > > > > -- > > > Martin Habets <habetsm.xilinx@gmail.com> _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <20220711114806.2724b349@kernel.org>]
[parent not found: <Ys6E4fvoufokIFqk@gmail.com>]
[parent not found: <20220713114804.11c7517e@kernel.org>]
[parent not found: <Ys/+vCNAfh/AKuJv@gmail.com>]
[parent not found: <20220714090500.356846ea@kernel.org>]
* Re: [PATCH net-next v2 0/2] sfc: Add EF100 BAR config support [not found] ` <20220714090500.356846ea@kernel.org> @ 2022-08-03 7:57 ` Jason Wang 0 siblings, 0 replies; 3+ messages in thread From: Jason Wang @ 2022-08-03 7:57 UTC (permalink / raw) To: Jakub Kicinski Cc: mst, netdev, virtualization, ecree.xilinx, Eric Dumazet, Bjorn Helgaas, linux-pci, Martin Habets, Paolo Abeni, davem On Fri, Jul 15, 2022 at 12:05 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Thu, 14 Jul 2022 12:32:12 +0100 Martin Habets wrote: > > > Okay. Indeed, we could easily bolt something onto devlink, I'd think > > > but I don't know the space enough to push for one solution over > > > another. > > > > > > Please try to document the problem and the solution... somewhere, tho. > > > Otherwise the chances that the next vendor with this problem follows > > > the same approach fall from low to none. > > > > Yeah, good point. The obvious thing would be to create a > > Documentation/networking/device_drivers/ethernet/sfc/sfc/rst > > Is that generic enough for other vendors to find out, or there a better place? > > Documentation/vdpa.rst ? I don't see any kernel level notes on > implementing vDPA perhaps virt folks can suggest something. Not sure, since it's not a vDPA general thing but a vendor/parent specific thing. Or maybe Documentation/vdpa/sfc ? Thanks > I don't think people would be looking into driver-specific docs > when trying to implement an interface, so sfc is not a great option > IMHO. > > > I can do a follow-up patch for this. > > Let's make it part of the same series. > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-08-03 7:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <165719918216.28149.7678451615870416505.stgit@palantir17.mph.net>
2022-07-07 15:55 ` [PATCH net-next v2 0/2] sfc: Add EF100 BAR config support Bjorn Helgaas
[not found] ` <Yswn7p+OWODbT7AR@gmail.com>
2022-07-11 22:00 ` Bjorn Helgaas
[not found] ` <20220711114806.2724b349@kernel.org>
[not found] ` <Ys6E4fvoufokIFqk@gmail.com>
[not found] ` <20220713114804.11c7517e@kernel.org>
[not found] ` <Ys/+vCNAfh/AKuJv@gmail.com>
[not found] ` <20220714090500.356846ea@kernel.org>
2022-08-03 7:57 ` Jason Wang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox