On 2021-12-01 11:14 a.m., 'Jason Gunthorpe' via linux-ntb wrote: > On Wed, Dec 01, 2021 at 06:35:35PM +0100, Thomas Gleixner wrote: >> On Wed, Dec 01 2021 at 09:00, Jason Gunthorpe wrote: >>> On Wed, Dec 01, 2021 at 11:16:47AM +0100, Thomas Gleixner wrote: >>>> Looking at the device slices as subdevices with their own struct device >>>> makes a lot of sense from the conceptual level. >>> >>> Except IMS is not just for subdevices, it should be usable for any >>> driver in any case as a general interrupt mechiansm, as you alluded to >>> below about ethernet queues. ntb seems to be the current example of >>> this need.. >> >> But NTB is operating through an abstraction layer and is not a direct >> PCIe device driver. > > I'm not sure exactly how NTB seems to be split between switchtec and > the ntb code, but since the ntbd code seems to be doing MMIO touches, > it feels like part of a PCIe driver? Eh, sort of. NTB has lots of layers. At the top you'll find ntb_netdev which is an network interface. Below that is ntb_transport() which is a generic queue pair. Below that is the hardware driver itself (ie switchtec) through the abstraction layer. The switchtec driver is split in two: the main driver which just allows for information and administration of the switch itself and switchtec_ntb which is the module that provides the NTB abstractions to twiddle its registers. ntb_transport() doesn't directly do MMIO touches (as it doesn't know what the underlying hardware registers are). Except for the memory windows which are usually setup to be a specific BAR (or parts of a BAR). ntb_transport will do MMIO writes to those specific BAR address which correspond to writing into buffers on the peer. Logan
