Hi David, On Wed, Oct 21, 2015 at 6:24 AM, David Marchand <david.marchand at 6wind.com> wrote:
> Hello Alejandro, > > On Fri, Oct 16, 2015 at 12:45 PM, Alejandro.Lucero < > alejandro.lucero at netronome.com> wrote: > >> From: "Alejandro.Lucero" <alejandro.lucero at netronome.com> >> >> This patch adds a new UIO kernel driver for supporting PCI VFs with >> Netronome >> nfp6000 card. Future PCI PF support will be based on changes to this >> module. >> >> Signed-off-by: Alejandro.Lucero <alejandro.lucero at netronome.com> >> Signed-off-by: Rolf.Neugebauer <rolf.neugebauer at netronome.com> >> > > Please, can you elaborate on the need for (yet another) uio driver, rather > than make igb_uio work with your hardware ? > > We have two different needs not covered by igb_uio: - pci mask needs to be 40 bits instead of 64 - some old kernel have buggy IOMMU with devices with pci masks as those 40 bits. This can be fixed just using kernel DMA API for a harmless dma memory allocation. We have such a allocation along with the release in our nfp_uio driver. I thought to modify igb_uio adding a kernel param for setting another pci mask than igb default one, but this is to leave to the user the right initialisation. But there is another more important reason for having a different driver: future PF support. Our device is programmable with processing units and functional units being configured by firmware code. Every part of the chip is addressable from the host which is possible through a BSP kernel driver. Device PCI BARs are not the same than network device (PF or VF) PCI BARs: the latter is a subregion of the former. VFs subregions are easy to get thanks to SRIOV. But in order to get the right subregions sizes and addresses for the PF, special firmware symbols are needed. User space programs can use the BSP through specific libraries but that requires support from the BSP, or from another driver doing the same. So nfp_uio will likely add that support. I have been looking at the possibility of getting rid of nfp_uio. The fact is our PMD can work without it, both for the PF and VF (not the PMD version already submitted but one under development). The PF support requires not using UIO at all, because the device is attached to the BSP driver. The only problem with this approach is we do not have support for interrupts, what is not critical (I can see other PMDs not having support for Link Status Changes) but we do not like it as programs can register callbacks for these interrupts which would not work at all. Interrupt support could be implemented in the BSP, doing the same UIO or VFIO do, but this will require (minor) changes to DPDK for having another intr_handle (not UIO, not VFIO). I do not know if other PMDs could also make use of such a change but I guess that would help to accept those changes. Therefore, the easiest thing to do is to implement the PF support in the nfp_uio by now. I hope this explanation can help to justify nfp_uio. Thanks > Thanks. > > -- > David Marchand >