On Tue, Jun 21, 2022 at 12:41:35PM -0700, Dan Williams wrote: > Lukas Wunner wrote: > > On Tue, Jun 21, 2022 at 12:10:03PM -0700, Dan Williams wrote: > > > It is really the interrupt setup that makes this an awkward fit all > > > around. The PCI core knows how to handle capabilities with interrupts, > > > but only for PCIe port services. DOE is both a PCIe port service *and* > > > and "endpoint service" like VPD (pci_vpd_init()). The more I think about > > > this the closer I get to the recommendation from Lukas which is that > > > DOE is more like pci_vpd_init() than pci_aer_init(), or a custom > > > enabling per driver. > > > > > > If the DOE enumeration moves to a sub-function of > > > pci_init_capabilities() then the cxl_pci and/or cxl_port drivers just > > > look those up and use them. The DOE instances would remain in polled > > > mode unless and until a PCI driver added interrupt support late. In > > > other words, DOE can follow the VPD init model as long as interrupts are > > > not involved, and if interrupts are desired it requires late allocation > > > of IRQ vectors. > > > > Thomas Gleixner has been working on dynamic allocation of MSI-X vectors. > > We should probably just build on that and let the PCI core allocate > > vectors for DOE mailboxes independently from drivers. > > > > To conserve vectors, I'd delay allocation for a DOE mailbox until > > it is first used. There may be mailboxes that are never used. > > > > DOE requires MSI-X or MSI. We could probably leave MSI unsupported > > until a device with broken MSI-X support shows up. I envision that > > with MSI, the onus is on the driver to allocate vectors for mailboxes > > it intends to use and it would then have to "donate" those vectors > > to the PCI core via a library function. > > > > As for portdrv, that's a driver but Bjorn has expressed a desire > > for a long time to move its functionality into the PCI core. > > It shouldn't be allowed to unbind portdrv via sysfs and thus break > > DPC etc, as is currently possible. > > > > The question with regards to this series is, do we get *something* > > merged and perfect it over time once it's in the tree, or do we > > keep iterating on the mailing list. That is what I was going for by allocating the vectors in the CXL driver where they happen to be used right now. But I mentioned in the commit message that I don't think that is where they should live long term. > > I deliberately only provided > > a single, comprehensive review and then stayed mum because I feel > > bad for Ira having to keep reacting to more and more feedback > > despite being at v11 already (or v12? I've lost count). > > Particularly because I suspect (I might be mistaken) that Ira's > > natural habitat is actually CXL not PCI, so it might be a burden for him. I'm always willing to learn more (PCI) but yes CXL is my focus. I've never modified the PCI layers so I am out of my element there. > > I'd be fine to implement suggestions I've made myself after Ira's > > series lands. No need for him to keep iterating ad infinitum. > > Yeah, sounds good. If the dynamic IRQ allocation support is on its way > then lets leave interrupt support out of the current DOE series and just > focus on getting polled mode going with the enumeration coming from the > PCI core. I've taken some time to look at the dynamic allocation stuff but I've not internalized it nor figured out how to integrate it into the PCI/CXL layers. > That seems the shortest path to get something landed and > enables incremental improvement. Then the messiness of DOE interrupt > allocation and pcie_port_drv reworks can be saved for PCI core folks. Yes I think getting rid of the IRQ stuff for this round would help. There has been a lot of discussion around it and I'm still not fully happy with it where it stands. So I'll split it out for now. If someone wants to pick it up that would be great or I can work on a more central place. Ira
