[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
Submitting just the PMD for integration makes sense. I will remove all the references to nfp_uio. My doubt is with documentation. Working with the NFP PMD will not be possible without nfp_uio. We could modify the documentation saying it is possible to use igb_uio, but this is not the right thing to do (pci mask will be wrong). So, would it be acceptable to submit a new PMD without any documentation by now? I prefer this for the sake of integration than giving wrong or incomplete documentation. Thanks On Wed, Oct 21, 2015 at 8:40 PM, Alejandro Lucero < alejandro.lucero at netronome.com> wrote: > > > On Wed, Oct 21, 2015 at 5:03 PM, Thomas Monjalon < > thomas.monjalon at 6wind.com> wrote: > >> 2015-10-21 16:57, Alejandro Lucero: >> > I understand interest for not having another UIO driver does exist. We >> > could maintain an external nfp_uio by now till either we get rid of it >> or >> > we definitely find out it is really needed. any chance to accept >> nfp_uio by >> > now? >> >> No, there are some work currently to get rid of igb_uio. >> So there are little chances to accept nfp_uio one day. >> Please take the first step of integrating your PMD without link interrupt. >> Later we'll be able to discuss how to mitigate the interrupt issue. >> > > Ok. I will create a new patchset version without nfp_uio. > > By the way, that work with igb_uio is about the patches to > pci_uio_generic? I thought there was some reticence from the maintainer for > adding pci bus master there. > > >
[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
On Wed, Oct 21, 2015 at 5:03 PM, Thomas Monjalon wrote: > 2015-10-21 16:57, Alejandro Lucero: > > I understand interest for not having another UIO driver does exist. We > > could maintain an external nfp_uio by now till either we get rid of it or > > we definitely find out it is really needed. any chance to accept nfp_uio > by > > now? > > No, there are some work currently to get rid of igb_uio. > So there are little chances to accept nfp_uio one day. > Please take the first step of integrating your PMD without link interrupt. > Later we'll be able to discuss how to mitigate the interrupt issue. > Ok. I will create a new patchset version without nfp_uio. By the way, that work with igb_uio is about the patches to pci_uio_generic? I thought there was some reticence from the maintainer for adding pci bus master there.
[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
2015-10-21 16:57, Alejandro Lucero: > I understand interest for not having another UIO driver does exist. We > could maintain an external nfp_uio by now till either we get rid of it or > we definitely find out it is really needed. any chance to accept nfp_uio by > now? No, there are some work currently to get rid of igb_uio. So there are little chances to accept nfp_uio one day. Please take the first step of integrating your PMD without link interrupt. Later we'll be able to discuss how to mitigate the interrupt issue.
[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
2015-10-21 15:39, Alejandro Lucero: > On Wed, Oct 21, 2015 at 6:24 AM, David Marchand > wrote: > > Please, can you elaborate on the need for (yet another) uio driver, rather > > than make igb_uio work with your hardware ? [...] > 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. We are going to have an external handler (used for mlx5): http://dpdk.org/ml/archives/dev/2015-October/024678.html Problem solved :) Is it possible to rework your PMD without nfp-uio? Thanks
[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
Wow! This is just what we (likely) need. We could have that support in our BSP but this is something yet to be approved. Setting per VF pci bus master and pci mask should also be added to BSP. Current PMD submitted would need nfp_uio by now for LSC interrupt support. As I said, this is not critical so NFP devices could be used with that limitation. My concern is tests without using nfp_uio have not been done, just some minor work for proof of concept. I understand interest for not having another UIO driver does exist. We could maintain an external nfp_uio by now till either we get rid of it or we definitely find out it is really needed. any chance to accept nfp_uio by now? Thanks On Wed, Oct 21, 2015 at 4:25 PM, Thomas Monjalon wrote: > 2015-10-21 15:39, Alejandro Lucero: > > On Wed, Oct 21, 2015 at 6:24 AM, David Marchand < > david.marchand at 6wind.com> > > wrote: > > > Please, can you elaborate on the need for (yet another) uio driver, > rather > > > than make igb_uio work with your hardware ? > [...] > > 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. > > We are going to have an external handler (used for mlx5): > http://dpdk.org/ml/archives/dev/2015-October/024678.html > Problem solved :) > > Is it possible to rework your PMD without nfp-uio? > > Thanks >
[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
Hi David, On Wed, Oct 21, 2015 at 6:24 AM, David Marchand wrote: > Hello Alejandro, > > On Fri, Oct 16, 2015 at 12:45 PM, Alejandro.Lucero < > alejandro.lucero at netronome.com> wrote: > >> From: "Alejandro.Lucero" >> >> 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 >> Signed-off-by: Rolf.Neugebauer >> > > 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 >
[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
Hello Alejandro, On Fri, Oct 16, 2015 at 12:45 PM, Alejandro.Lucero < alejandro.lucero at netronome.com> wrote: > From: "Alejandro.Lucero" > > 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 > Signed-off-by: Rolf.Neugebauer > Please, can you elaborate on the need for (yet another) uio driver, rather than make igb_uio work with your hardware ? Thanks. -- David Marchand
[dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
From: "Alejandro.Lucero"
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
Signed-off-by: Rolf.Neugebauer
---
lib/librte_eal/common/include/rte_pci.h |1 +
lib/librte_eal/linuxapp/Makefile |3 +
lib/librte_eal/linuxapp/eal/eal_pci.c |4 +
lib/librte_eal/linuxapp/eal/eal_pci_uio.c |2 +-
lib/librte_eal/linuxapp/nfp_uio/Makefile | 53 +++
lib/librte_eal/linuxapp/nfp_uio/nfp_uio.c | 497 +
lib/librte_ether/rte_ethdev.c |1 +
7 files changed, 560 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_eal/linuxapp/nfp_uio/Makefile
create mode 100644 lib/librte_eal/linuxapp/nfp_uio/nfp_uio.c
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 83e3c28..89baaf6 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -146,6 +146,7 @@ struct rte_devargs;
enum rte_kernel_driver {
RTE_KDRV_UNKNOWN = 0,
RTE_KDRV_IGB_UIO,
+ RTE_KDRV_NFP_UIO,
RTE_KDRV_VFIO,
RTE_KDRV_UIO_GENERIC,
RTE_KDRV_NIC_UIO,
diff --git a/lib/librte_eal/linuxapp/Makefile b/lib/librte_eal/linuxapp/Makefile
index d9c5233..f36dc4b 100644
--- a/lib/librte_eal/linuxapp/Makefile
+++ b/lib/librte_eal/linuxapp/Makefile
@@ -34,6 +34,9 @@ include $(RTE_SDK)/mk/rte.vars.mk
ifeq ($(CONFIG_RTE_EAL_IGB_UIO),y)
DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += igb_uio
endif
+ifeq ($(CONFIG_RTE_EAL_NFP_UIO),y)
+DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += nfp_uio
+endif
DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal
ifeq ($(CONFIG_RTE_KNI_KMOD),y)
DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += kni
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index bc5b5be..19a93fe 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -137,6 +137,7 @@ pci_map_device(struct rte_pci_device *dev)
#endif
break;
case RTE_KDRV_IGB_UIO:
+ case RTE_KDRV_NFP_UIO:
case RTE_KDRV_UIO_GENERIC:
/* map resources for devices that use uio */
ret = pci_uio_map_resource(dev);
@@ -161,6 +162,7 @@ pci_unmap_device(struct rte_pci_device *dev)
RTE_LOG(ERR, EAL, "Hotplug doesn't support vfio yet\n");
break;
case RTE_KDRV_IGB_UIO:
+ case RTE_KDRV_NFP_UIO:
case RTE_KDRV_UIO_GENERIC:
/* unmap resources for devices that use uio */
pci_uio_unmap_resource(dev);
@@ -357,6 +359,8 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
dev->kdrv = RTE_KDRV_VFIO;
else if (!strcmp(driver, "igb_uio"))
dev->kdrv = RTE_KDRV_IGB_UIO;
+ else if (!strcmp(driver, "nfp_uio"))
+ dev->kdrv = RTE_KDRV_NFP_UIO;
else if (!strcmp(driver, "uio_pci_generic"))
dev->kdrv = RTE_KDRV_UIO_GENERIC;
else
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index ac50e13..29ec9cb 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -270,7 +270,7 @@ pci_uio_alloc_resource(struct rte_pci_device *dev,
goto error;
}
- if (dev->kdrv == RTE_KDRV_IGB_UIO)
+ if (dev->kdrv == RTE_KDRV_IGB_UIO || dev->kdrv == RTE_KDRV_NFP_UIO)
dev->intr_handle.type = RTE_INTR_HANDLE_UIO;
else {
dev->intr_handle.type = RTE_INTR_HANDLE_UIO_INTX;
diff --git a/lib/librte_eal/linuxapp/nfp_uio/Makefile
b/lib/librte_eal/linuxapp/nfp_uio/Makefile
new file mode 100644
index 000..b9e2f0a
--- /dev/null
+++ b/lib/librte_eal/linuxapp/nfp_uio/Makefile
@@ -0,0 +1,53 @@
+# BSD LICENSE
+#
+# Copyright(c) 2014-2015 Netronome. All rights reserved.
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+# * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
