[dpdk-dev] [PATCH v2] ntnic: add PMD driver
This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK. This patch adds support for Napatech NICs to DPDK. This is the initial implementation. Signed-off-by: Finn Christensen --- v2: * Added information how to build the PMD without NIC Board Support Package * Fixed some formatting issues --- MAINTAINERS | 5 + config/common_base | 6 + doc/guides/nics/features/ntnic.ini | 15 + doc/guides/nics/index.rst | 1 + doc/guides/nics/ntnic.rst | 145 + drivers/net/Makefile| 1 + drivers/net/ntnic/Makefile | 65 ++ drivers/net/ntnic/rte_eth_ntnic.c | 975 drivers/net/ntnic/rte_pmd_ntnic_version.map | 4 + mk/rte.app.mk | 7 + 10 files changed, 1224 insertions(+) create mode 100644 doc/guides/nics/features/ntnic.ini create mode 100644 doc/guides/nics/ntnic.rst create mode 100644 drivers/net/ntnic/Makefile create mode 100644 drivers/net/ntnic/rte_eth_ntnic.c create mode 100644 drivers/net/ntnic/rte_pmd_ntnic_version.map diff --git a/MAINTAINERS b/MAINTAINERS index bc9aa02..d3e5f56 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -356,6 +356,11 @@ M: Sony Chacko F: drivers/net/qede/ F: doc/guides/nics/qede.rst +Napatech ntnic +M: Finn Christensen +F: drivers/net/ntnic/ +F: doc/guides/nics/ntnic.rst + RedHat virtio M: Huawei Xie M: Yuanhan Liu diff --git a/config/common_base b/config/common_base index 7830535..4a3b2b8 100644 --- a/config/common_base +++ b/config/common_base @@ -309,6 +309,12 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16 CONFIG_RTE_LIBRTE_PMD_PCAP=n # +# Compile software PMD backed by NTNIC files +# +CONFIG_RTE_LIBRTE_PMD_NTNIC=n + + +# # Compile link bonding PMD library # CONFIG_RTE_LIBRTE_PMD_BOND=y diff --git a/doc/guides/nics/features/ntnic.ini b/doc/guides/nics/features/ntnic.ini new file mode 100644 index 000..b6cfc5a --- /dev/null +++ b/doc/guides/nics/features/ntnic.ini @@ -0,0 +1,15 @@ +; +; Supported features of the 'ntnic' network poll mode driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Link status = Y +Queue start/stop = Y +Promiscuous mode = Y +Jumbo frame = Y +Basic stats = Y +Multiprocess aware = Y +x86-32 = Y +x86-64 = Y +Usage doc= Y diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index 92d56a5..5c4205c 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -52,6 +52,7 @@ Network Interface Controller Drivers qede szedata2 thunderx +ntnic virtio vhost vmxnet3 diff --git a/doc/guides/nics/ntnic.rst b/doc/guides/nics/ntnic.rst new file mode 100644 index 000..8512d02 --- /dev/null +++ b/doc/guides/nics/ntnic.rst @@ -0,0 +1,145 @@ +.. BSD LICENSE +Copyright (c) 2016 Napatech A/S +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 Napatech 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, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +NTNIC Poll Mode Driver +== + +The NTNIC poll mode driver library (**librte_pmd_ntnic**) implements support +for **Napatech NIC** 40/50 Gbps adapters. +This PMD is implemented as a pure software virtual device and must be created +by using the EAL --vdev=parameter (parameters are explained i detail later). +It runs on top of the Napatech NFV NIC Board Support Package that must be +instal
[dpdk-dev] [PATCH v2] ntnic: add PMD driver
> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: 8. september 2016 15:50 > To: Finn Christensen > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com; > stephen at networkplumber.org > Subject: Re: [dpdk-dev] [PATCH v2] ntnic: add PMD driver > > On Thu, Sep 08, 2016 at 11:14:24AM +, Finn Christensen wrote: > > This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK. > > > > This patch adds support for Napatech NICs to DPDK. This is the initial > > implementation. > > > > Signed-off-by: Finn Christensen > > --- > > v2: > > * Added information how to build the PMD without NIC > > Board Support Package > > * Fixed some formatting issues > > --- > > MAINTAINERS | 5 + > > config/common_base | 6 + > > doc/guides/nics/features/ntnic.ini | 15 + > > doc/guides/nics/index.rst | 1 + > > doc/guides/nics/ntnic.rst | 145 + > > drivers/net/Makefile| 1 + > > drivers/net/ntnic/Makefile | 65 ++ > > drivers/net/ntnic/rte_eth_ntnic.c | 975 > > > drivers/net/ntnic/rte_pmd_ntnic_version.map | 4 + > > mk/rte.app.mk | 7 + > > 10 files changed, 1224 insertions(+) > > create mode 100644 doc/guides/nics/features/ntnic.ini > > create mode 100644 doc/guides/nics/ntnic.rst create mode 100644 > > drivers/net/ntnic/Makefile create mode 100644 > > drivers/net/ntnic/rte_eth_ntnic.c create mode 100644 > > drivers/net/ntnic/rte_pmd_ntnic_version.map > > > > diff --git a/MAINTAINERS b/MAINTAINERS index bc9aa02..d3e5f56 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -356,6 +356,11 @@ M: Sony Chacko > > F: drivers/net/qede/ > > F: doc/guides/nics/qede.rst > > > > +Napatech ntnic > > +M: Finn Christensen > > +F: drivers/net/ntnic/ > > +F: doc/guides/nics/ntnic.rst > > + > > RedHat virtio > > M: Huawei Xie > > M: Yuanhan Liu diff --git > > a/config/common_base b/config/common_base index 7830535..4a3b2b8 > > 100644 > > --- a/config/common_base > > +++ b/config/common_base > > @@ -309,6 +309,12 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16 > > CONFIG_RTE_LIBRTE_PMD_PCAP=n > > > > # > > +# Compile software PMD backed by NTNIC files # > > +CONFIG_RTE_LIBRTE_PMD_NTNIC=n > > + > > + > > +# > > # Compile link bonding PMD library > > # > > CONFIG_RTE_LIBRTE_PMD_BOND=y > > diff --git a/doc/guides/nics/features/ntnic.ini > > b/doc/guides/nics/features/ntnic.ini > > new file mode 100644 > > index 000..b6cfc5a > > --- /dev/null > > +++ b/doc/guides/nics/features/ntnic.ini > > @@ -0,0 +1,15 @@ > > +; > > +; Supported features of the 'ntnic' network poll mode driver. > > +; > > +; Refer to default.ini for the full list of available PMD features. > > +; > > +[Features] > > +Link status = Y > > +Queue start/stop = Y > > +Promiscuous mode = Y > > +Jumbo frame = Y > > +Basic stats = Y > > +Multiprocess aware = Y > > +x86-32 = Y > > +x86-64 = Y > > +Usage doc= Y > > diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst > > index 92d56a5..5c4205c 100644 > > --- a/doc/guides/nics/index.rst > > +++ b/doc/guides/nics/index.rst > > @@ -52,6 +52,7 @@ Network Interface Controller Drivers > > qede > > szedata2 > > thunderx > > +ntnic > > virtio > > vhost > > vmxnet3 > > diff --git a/doc/guides/nics/ntnic.rst b/doc/guides/nics/ntnic.rst new > > file mode 100644 index 000..8512d02 > > --- /dev/null > > +++ b/doc/guides/nics/ntnic.rst > > @@ -0,0 +1,145 @@ > > +.. BSD LICENSE > > +Copyright (c) 2016 Napatech A/S > > +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 do
[dpdk-dev] [PATCH v3] ntnic: add PMD driver
This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK. This patch adds support for Napatech NICs to DPDK. This is the initial implementation. Signed-off-by: Finn Christensen --- v3: * Removed the need for binary libraries on build v2: * Added information how to build the PMD without NIC Board Support Package * Fixed some formatting issues --- MAINTAINERS |5 + config/common_base |6 + doc/guides/nics/features/ntnic.ini | 14 + doc/guides/nics/index.rst |1 + doc/guides/nics/ntnic.rst | 145 drivers/net/Makefile|1 + drivers/net/ntnic/Makefile | 66 ++ drivers/net/ntnic/rte_eth_ntnic.c | 1150 +++ drivers/net/ntnic/rte_pmd_ntnic_version.map |4 + mk/rte.app.mk |3 + 10 files changed, 1395 insertions(+) create mode 100644 doc/guides/nics/features/ntnic.ini create mode 100644 doc/guides/nics/ntnic.rst create mode 100644 drivers/net/ntnic/Makefile create mode 100644 drivers/net/ntnic/rte_eth_ntnic.c create mode 100644 drivers/net/ntnic/rte_pmd_ntnic_version.map diff --git a/MAINTAINERS b/MAINTAINERS index bc9aa02..d3e5f56 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -356,6 +356,11 @@ M: Sony Chacko F: drivers/net/qede/ F: doc/guides/nics/qede.rst +Napatech ntnic +M: Finn Christensen +F: drivers/net/ntnic/ +F: doc/guides/nics/ntnic.rst + RedHat virtio M: Huawei Xie M: Yuanhan Liu diff --git a/config/common_base b/config/common_base index 7830535..4a3b2b8 100644 --- a/config/common_base +++ b/config/common_base @@ -309,6 +309,12 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16 CONFIG_RTE_LIBRTE_PMD_PCAP=n # +# Compile software PMD backed by NTNIC files +# +CONFIG_RTE_LIBRTE_PMD_NTNIC=n + + +# # Compile link bonding PMD library # CONFIG_RTE_LIBRTE_PMD_BOND=y diff --git a/doc/guides/nics/features/ntnic.ini b/doc/guides/nics/features/ntnic.ini new file mode 100644 index 000..4237e6e --- /dev/null +++ b/doc/guides/nics/features/ntnic.ini @@ -0,0 +1,14 @@ +; +; Supported features of the 'ntnic' network poll mode driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Link status = Y +Queue start/stop = Y +Promiscuous mode = Y +Jumbo frame = Y +Basic stats = Y +Multiprocess aware = Y +x86-64 = Y +Usage doc= Y diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index 92d56a5..5c4205c 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -52,6 +52,7 @@ Network Interface Controller Drivers qede szedata2 thunderx +ntnic virtio vhost vmxnet3 diff --git a/doc/guides/nics/ntnic.rst b/doc/guides/nics/ntnic.rst new file mode 100644 index 000..f9398db --- /dev/null +++ b/doc/guides/nics/ntnic.rst @@ -0,0 +1,145 @@ +.. BSD LICENSE +Copyright (c) 2016 Napatech A/S +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 Napatech 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, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +NTNIC Poll Mode Driver +== + +The NTNIC poll mode driver library (**librte_pmd_ntnic**) implements support +for **Napatech NIC** 40/50 Gbps adapters. +This PMD is implemented as a pure software virtual device and must be created +by using the EAL --vdev=parameter (parameters are explained i detail later). +It runs on top of the Napatech NFV NIC Board
[dpdk-dev] [PATCH v3] ntnic: add PMD driver
> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: 9. september 2016 15:51 > To: Finn Christensen > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com; > stephen at networkplumber.org > Subject: Re: [PATCH v3] ntnic: add PMD driver > > On Fri, Sep 09, 2016 at 12:48:38PM +, Finn Christensen wrote: > > This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK. > > > > This patch adds support for Napatech NICs to DPDK. This is the > > initial implementation. > > > > Signed-off-by: Finn Christensen > > --- > > v3: > > * Removed the need for binary libraries on build > > v2: > > * Added information how to build the PMD without NIC > > Board Support Package > > * Fixed some formatting issues > So, this is a step in the right direction, but I think its solving the wrong > problem. If you have a dependency on an external library, thats ok, and > accessing it via dlopen makes it possible to build the library without having > that library present, but it not really in keeping with the spirit of what I > meant. This driver is still effectively dependent on a binary blob that we > have > no visibility into. The better solution is releasing the source for the ntnic > and ntos libraries. The license file in the referenced git tree indicates its > BSD licensed, so I don't think there should be a problem in doing that. > > Neil > No, unfortunately the ntapi is not BSD licensed, only the header files that you can freely download are. We are building this NT NIC by using parts or our technology from our capture adapters and that is using closed source software. We are new to opensource and we want to go that way, but we haven't yet a complete stand-alone driver ready that we can put into the DPDK PMD to have a complete self contained and open sourced DPDK PMD, that only needs the actual HW NIC plugged in to run. Therefore this version is implemented as a virtual device, exactly like the PCAP PMD driver is, and it runs on top of a driver that follows the NIC itself. In regards to the DPDK functionality we do not see that anything is missing. I cannot either see where we should add source code, because it is not part of the DPDK package and it should not be either. One of the things I really liked about the DPDK open source project is that it uses BSD licensing not GPL. Therefore, I must admit, we completely failed to see that the "spirit" of the DPDK community is not really BSD. Our view of this community was that the main driving force of it was to be able to make DPDK run on everything anywhere effectively, in a global contributing community, without any legally constrains prohibiting us to do so. However, this is our standing, and I don't know what else to do. Please advise or NAK this PMD. Finn > > --- > > MAINTAINERS |5 + > > config/common_base |6 + > > doc/guides/nics/features/ntnic.ini | 14 + > > doc/guides/nics/index.rst |1 + > > doc/guides/nics/ntnic.rst | 145 > > drivers/net/Makefile|1 + > > drivers/net/ntnic/Makefile | 66 ++ > > drivers/net/ntnic/rte_eth_ntnic.c | 1150 > +++ > > drivers/net/ntnic/rte_pmd_ntnic_version.map |4 + > > mk/rte.app.mk |3 + > > 10 files changed, 1395 insertions(+) > > create mode 100644 doc/guides/nics/features/ntnic.ini > > create mode 100644 doc/guides/nics/ntnic.rst > > create mode 100644 drivers/net/ntnic/Makefile > > create mode 100644 drivers/net/ntnic/rte_eth_ntnic.c > > create mode 100644 drivers/net/ntnic/rte_pmd_ntnic_version.map > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index bc9aa02..d3e5f56 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -356,6 +356,11 @@ M: Sony Chacko > > F: drivers/net/qede/ > > F: doc/guides/nics/qede.rst > > > > +Napatech ntnic > > +M: Finn Christensen > > +F: drivers/net/ntnic/ > > +F: doc/guides/nics/ntnic.rst > > + > > RedHat virtio > > M: Huawei Xie > > M: Yuanhan Liu > > diff --git a/config/common_base b/config/common_base > > index 7830535..4a3b2b8 100644 > > --- a/config/common_base > > +++ b/config/common_base > > @@ -309,6 +309,12 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16 > > CONFIG_RTE_LIBRTE_PMD_PCAP=n > > > > # > > +# Compile software PMD backed by NTNIC files > > +# > > +CONFIG_RTE_LIBRTE_PMD_NTNIC=n > > + > > + > > +# > > # Compile link
[dpdk-dev] [PATCH v3] ntnic: add PMD driver
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: 10. september 2016 10:20 > To: Finn Christensen > Cc: Neil Horman ; dev at dpdk.org; > stephen at networkplumber.org > Subject: Re: [PATCH v3] ntnic: add PMD driver > > 2016-09-10 07:58, Finn Christensen: > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > On Fri, Sep 09, 2016 at 12:48:38PM +, Finn Christensen wrote: > > > > This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK. > > > > > > > > This patch adds support for Napatech NICs to DPDK. This is the > > > > initial implementation. > > > > > > > > Signed-off-by: Finn Christensen > > > > --- > > > > v3: > > > > * Removed the need for binary libraries on build > > > > v2: > > > > * Added information how to build the PMD without NIC > > > > Board Support Package > > > > * Fixed some formatting issues > > > > > > So, this is a step in the right direction, but I think its solving > > > the wrong problem. If you have a dependency on an external library, > > > thats ok, and accessing it via dlopen makes it possible to build the > > > library without having that library present, but it not really in > > > keeping with the spirit of what I meant. This driver is still > > > effectively dependent on a binary blob that we have no visibility > > > into. The better solution is releasing the source for the ntnic and > > > ntos libraries. The license file in the referenced git tree > > > indicates its BSD licensed, so I don't think there should be a problem in > doing that. > > > > > > Neil > > > > > No, unfortunately the ntapi is not BSD licensed, only the header files > > that you can freely download are. > > We are building this NT NIC by using parts or our technology from our > > capture adapters and that is using closed source software. > > > > We are new to opensource and we want to go that way, but we haven't > > yet a complete stand-alone driver ready that we can put into the DPDK > > PMD to have a complete self contained and open sourced DPDK PMD, that > > only needs the actual HW NIC plugged in to run. > > Therefore this version is implemented as a virtual device, exactly > > like the PCAP PMD driver is, and it runs on top of a driver that follows the > NIC itself. > > > > In regards to the DPDK functionality we do not see that anything is missing. > > I cannot either see where we should add source code, because it is not > > part of the DPDK package and it should not be either. > > > > One of the things I really liked about the DPDK open source project is > > that it uses BSD licensing not GPL. Therefore, I must admit, we > > completely failed to see that the "spirit" of the DPDK community is > > not really BSD. Our view of this community was that the main driving > > force of it was to be able to make DPDK run on everything anywhere > > effectively, in a global contributing community, without any legally > constrains prohibiting us to do so. > > It is difficult to define what is the spirit of a community, especially only > after > few mail exchanges. > I agree that running on everything anywhere is a nice goal. > Here Neil, as a RedHat developer, is probably concerned about enabling your > driver in a distribution. It seems your model is not compatible with the > "anywhere goal" and will be disabled in that case, until it is fully open. The ntnic PMD is not enabled by default and I think it should not be either. To enable it in a distribution for general purposes seems wrong. In that respect we see no difference between the PCAP PMD and this ntnic PMD. > > However, this is our standing, and I don't know what else to do. > > Please advise or NAK this PMD. > > I do not remember having already seen such model in DPDK. > So we need to think about the implications a bit more. > (Comments/discussions are welcome) > Thanks for your patience. Thanks. I will be happy to discuss this further, so that we can get to a conclusion. If the outcome is that the majority of the community does not like the idea that upstream supported PMDs has external linking dependencies to closed source libraries, then it is ok with us(a pity though). But then it might be a good idea to make that decision clear to everybody else by putting in a clause into the contribution section of the DPDK guide, or somewhere else in the guide. In our opinion, the inclusion of the ntnic PMD into upstream DPDK, does not seem
[dpdk-dev] [PATCH v3] ntnic: add PMD driver
Yes, this we can do without asking you guys, and we already do so. But that is not what this ntnic PMD is about. We have built a NT NIC out of our existing accelerator products. This NIC is built using an FPGA and is targeted towards NFV acceleration in virtualized environments. Now, we have seen good acceleration results in our tests by using DPDK (with small additions to DPDK). What we want to do is to make this part of open source DPDK and in general run this project in an open source spirit. We want to make further RFCs to the DPDK community about extensions to the DPDK that can accelerate packet processing, and this ntnic PMD is the first step in our participation/contribution into the DPDK project. Furthermore, we do not think in proprietary code with this project, and no further libraries or other external closed source dependencies will be added in upcoming contributions from our side (at least we have no plan in doing so). Finn From: Stephen Hemminger [mailto:step...@networkplumber.org] Sent: 10. september 2016 20:31 To: Thomas Monjalon Cc: dev at dpdk.org; Finn Christensen ; Neil Horman Subject: Re: [PATCH v3] ntnic: add PMD driver I think that if the driver is just a shim for proprietary code, then the vendor should just maintain it out of tree. 6wind and windriver already do this. Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
Re: [dpdk-dev] Napatech pmd
>-Original Message- >From: Thomas Monjalon [mailto:tho...@monjalon.net] >Sent: 8. januar 2018 16:16 >To: Finn Christensen >Cc: dev@dpdk.org >Subject: Re: [dpdk-dev] Napatech pmd > >Hi, > >08/01/2018 14:08, Finn Christensen: >> Hi Thomas, >> >> Thanks for bringing this discussion up again. >> >> The Napatech PMD is build on top of our proprietary driver. The reason is >basically that we utilize many years of driver development and thus reuses >the FPGA controlling code in the DPDK PMD. The Napatech driver suite is still >closed source. >> The current NTNIC PMD dynamically links a Napatech proprietary NTAPI >library to control the FPGA on our NICs. >> >> We did think of the PMD as being our responsibility to keep updated >towards the Napatech NIC communication, and that we would be engaged >and asked to modify accordingly if changes in DPDK required that >(maintainer). Furthermore, the PMD compiles with no issues, when NTNIC is >enabled. >> We have plans to write a stand-alone PMD, but this is not a small task to do, >therefore we haven't got to that yet. > >This standalone PMD would be open and BSD licensed? Yes! > >> If the DPDK community would accept the dynamic linking to a proprietary >library, from inside our PMD, then it would be great. > >Dynamic linking is OK. >I think we can accept such PMD at the condition that we can build it, meaning >we can easily download the build dependencies for free. That sounds great. This was also our initial thoughts about the implementation. I will try to start this task up again and next step, I guess, will be a new RFC for a new Napatech pmd. > >> Let me know what you think. Or maybe you have ideas to what else we >could do to make it upstream. > >My thinking is to allow every hardware to have a good DPDK support. >Every step in this direction is a progress. Thanks, Finn
Re: [dpdk-dev] standardize device identification
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas
Monjalon
Sent: 20. december 2017 23:03
To: dev@dpdk.org
Cc: Yuanhan Liu ; Adrien Mazarguil
; Ciara Loftus ;
Kevin Traynor ; step...@networkplumber.org;
ferruh.yi...@intel.com
Subject: Re: [dpdk-dev] standardize device identification
Changing the title and adding more comments inline:
19/12/2017 00:05, Thomas Monjalon:
> Let's summarize and resume this thread.
>
> We need a generic syntax to describe a device.
> This syntax can be used
> - before initializing the device (i.e. whitelist/blacklist)
> - or after the initialization (e.g. user config)
>
> We need to answer 4 questions:
> 1/ what are the separators (comma, colon, etc)?
> 2/ how to distinguish a device identification from a configuration?
> 3/ what are the mandatory parts?
> 4/ what can be the optional properties?
>
> 30/11/2017 08:35, Yuanhan Liu:
> > What this patch proposes is to use "name[,mac]" syntax. "name" is
> > the PCI id for pci device. For vdev, it's the vdev name given by
> > user. The reason "mac" is needed is for some devices (say
> > ConnectX-3), 2 ports (in a single NIC) have the same PCI id.
>
> Based on the feedbacks we had, I suggest a syntax where everything is
> optional key/value pairs, and split in 3 categories:
> - bus (pci, vdev, vmbus, fslmc, etc)
> - class (eth, crypto)
> - driver (i40e, mlx5, virtio, etc)
The key/value pair describing the category scope is mandatory and must
be the first pair in the category properties.
Example: bus=pci, must be placed before id=:01:00.0
> Between categories, the separator is a slash.
> Inside a category, the separator is a comma.
> Inside a key/value pair, the separator is an equal sign.
>
> It may look like this:
>
bus=BUS_NAME,id=BUS_ID/class=CLASS_NAME,dev_port=PORT_NUM,m
ac=MAC_ADDR
> ESS/driver=DRIVER_NAME,driverspecificproperty=VALUE
>
> A device is identified when every properties are matched.
> Before device is probed, only the bus category is relevant.
> For the simple PCI whitelist, it means moving from
> -w :01:00.0
> to
> -w bus=pci,id=:01:00.0
>
> It is possible to mix some settings in these devargs syntax if the
> keys are differents. Example: mac= is for identification by MAC,
> whereas newmac= would be for specifying a MAC address to set.
>
> Agreement?
We also need to distinguish between multiple ports sitting on same PCI bus ID.
and from our point of view, this will fully cover our needs.
Thanks - great proposal.
Regards,
Finn Christensen, Napatech
Yuanhan is proposing to use this syntax in OVS option dpdk-devargs:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-
December/342273.html
Please, any feedback or approval that this syntax is good?
Re: [dpdk-dev] standardize device identification
-Original Message- From: Thomas Monjalon [mailto:tho...@monjalon.net] Sent: 5. januar 2018 09:40 To: Finn Christensen Cc: dev@dpdk.org; Yuanhan Liu ; Adrien Mazarguil ; Ciara Loftus ; Kevin Traynor ; step...@networkplumber.org; ferruh.yi...@intel.com Subject: Re: [dpdk-dev] standardize device identification 05/01/2018 08:52, Finn Christensen: > From: Thomas > > It may look like this: > > > > bus=BUS_NAME,id=BUS_ID/class=CLASS_NAME,dev_port=PORT_NUM, > > mac=MAC_ADDRESS/driver=DRIVER_NAME,driverspecificproperty=VALUE [...] > We also need to distinguish between multiple ports sitting on same PCI bus ID. > and from our point of view, this will fully cover our needs. Which property can help to distinguish Napatech ports? Can you use class=eth,dev_port=X ? The dev_port property will use /sys/class/net/DEV/dev_port on Linux. Is it OK for you? Actually, what we were thinking of was using the mac property in the class category to distinguish our ports. For instance: -w bus=pci,id=:01:00.0/class=eth,mac=00:11:22:33:44:55 or simply: -w class=eth,mac=00:11:22:33:44:55 We will not be able to support the dev_port property, that will not work for us. At least not for now. Regards, Finn
Re: [dpdk-dev] standardize device identification
>-Original Message- >From: Thomas Monjalon [mailto:tho...@monjalon.net] >Sent: 5. januar 2018 13:02 >To: Finn Christensen >Cc: dev@dpdk.org; Yuanhan Liu ; Adrien Mazarguil >; Ciara Loftus ; Kevin >Traynor ; step...@networkplumber.org; >ferruh.yi...@intel.com >Subject: Re: [dpdk-dev] standardize device identification > >05/01/2018 12:09, Finn Christensen: >> From: Thomas Monjalon >> Which property can help to distinguish Napatech ports? >> Can you use class=eth,dev_port=X ? >> The dev_port property will use /sys/class/net/DEV/dev_port on Linux. Is >> it >> OK for you? >> >> Actually, what we were thinking of was using the mac property in the >> class category to distinguish our ports. >> For instance: >> -w bus=pci,id=:01:00.0/class=eth,mac=00:11:22:33:44:55 >> or simply: >> -w class=eth,mac=00:11:22:33:44:55 > >The problem with the mac property is that it cannot be used for >white/blacklisting in DPDK because the MAC is not known before port >initialization. > Sure, that makes sense. I just for a minute thought that we could use that mechanism to enable individual ports at startup also. We will continue to use proprietary devargs passed by whiterlist to the PMD probe function. What we needed was a way to select the individual ports, by using rte_eth_dev_get_port_by_name(). >> We will not be able to support the dev_port property, that will not work for >us. >> At least not for now.
Re: [dpdk-dev] standardize device identification
>-Original Message- >From: Thomas Monjalon [mailto:tho...@monjalon.net] >Sent: 5. januar 2018 16:34 >To: Finn Christensen >Cc: dev@dpdk.org; Yuanhan Liu ; Adrien Mazarguil >; Ciara Loftus ; Kevin >Traynor ; step...@networkplumber.org; >ferruh.yi...@intel.com >Subject: Re: [dpdk-dev] standardize device identification > >05/01/2018 15:14, Finn Christensen: >> From: Thomas Monjalon [mailto:tho...@monjalon.net] >> >05/01/2018 12:09, Finn Christensen: >> >> From: Thomas Monjalon >> >> Which property can help to distinguish Napatech ports? >> >> Can you use class=eth,dev_port=X ? >> >> The dev_port property will use /sys/class/net/DEV/dev_port on Linux. >Is it >> >> OK for you? >> >> >> >> Actually, what we were thinking of was using the mac property in >> >> the class category to distinguish our ports. >> >> For instance: >> >> -w bus=pci,id=:01:00.0/class=eth,mac=00:11:22:33:44:55 >> >> or simply: >> >> -w class=eth,mac=00:11:22:33:44:55 >> > >> >The problem with the mac property is that it cannot be used for >> >white/blacklisting in DPDK because the MAC is not known before port >> >initialization. >> > >> >> Sure, that makes sense. I just for a minute thought that we could use >> that mechanism to enable individual ports at startup also. We will >> continue to use proprietary devargs passed by whiterlist to the PMD probe >function. >> What we needed was a way to select the individual ports, by using >> rte_eth_dev_get_port_by_name(). > >The whitelist will be replaced by this new syntax. >And yes, you can have your own driver-specific property with this syntax. That's fine. > >> >> We will not be able to support the dev_port property, that will not >> >> work for >> >us. >> >> At least not for now. > >It leads to a totally different question: >Can we discuss again how to integrate your driver in DPDK upstream? >Please explain again your situation in a new thread. Sure, I'll get back to you in a new thread. Thanks!
[dpdk-dev] Napatech pmd
Hi Thomas, Thanks for bringing this discussion up again. The Napatech PMD is build on top of our proprietary driver. The reason is basically that we utilize many years of driver development and thus reuses the FPGA controlling code in the DPDK PMD. The Napatech driver suite is still closed source. The current NTNIC PMD dynamically links a Napatech proprietary NTAPI library to control the FPGA on our NICs. We did think of the PMD as being our responsibility to keep updated towards the Napatech NIC communication, and that we would be engaged and asked to modify accordingly if changes in DPDK required that (maintainer). Furthermore, the PMD compiles with no issues, when NTNIC is enabled. We have plans to write a stand-alone PMD, but this is not a small task to do, therefore we haven't got to that yet. If the DPDK community would accept the dynamic linking to a proprietary library, from inside our PMD, then it would be great. Let me know what you think. Or maybe you have ideas to what else we could do to make it upstream. Thanks, Finn >-Original Message- >From: Thomas Monjalon [mailto:tho...@monjalon.net] >Sent: 5. januar 2018 16:34 >To: Finn Christensen >Subject: Re: [dpdk-dev] standardize device identification > >It leads to a totally different question: >Can we discuss again how to integrate your driver in DPDK upstream? >Please explain again your situation in a new thread.
[dpdk-dev] [PATCH] ntnic: add PMD driver
This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK. This patch adds support for Napatech NICs to DPDK. This is the inital implementation. Signed-off-by: Finn Christensen --- MAINTAINERS | 5 + config/common_base | 6 + doc/guides/nics/features/ntnic.ini | 15 + doc/guides/nics/index.rst | 1 + doc/guides/nics/ntnic.rst | 138 + drivers/net/Makefile| 1 + drivers/net/ntnic/Makefile | 65 ++ drivers/net/ntnic/rte_eth_ntnic.c | 912 drivers/net/ntnic/rte_pmd_ntnic_version.map | 4 + mk/rte.app.mk | 7 + 10 files changed, 1154 insertions(+) create mode 100644 doc/guides/nics/features/ntnic.ini create mode 100644 doc/guides/nics/ntnic.rst create mode 100644 drivers/net/ntnic/Makefile create mode 100644 drivers/net/ntnic/rte_eth_ntnic.c create mode 100644 drivers/net/ntnic/rte_pmd_ntnic_version.map diff --git a/MAINTAINERS b/MAINTAINERS index bc9aa02..d3e5f56 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -356,6 +356,11 @@ M: Sony Chacko F: drivers/net/qede/ F: doc/guides/nics/qede.rst +Napatech ntnic +M: Finn Christensen +F: drivers/net/ntnic/ +F: doc/guides/nics/ntnic.rst + RedHat virtio M: Huawei Xie M: Yuanhan Liu diff --git a/config/common_base b/config/common_base index 7830535..4a3b2b8 100644 --- a/config/common_base +++ b/config/common_base @@ -309,6 +309,12 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16 CONFIG_RTE_LIBRTE_PMD_PCAP=n # +# Compile software PMD backed by NTNIC files +# +CONFIG_RTE_LIBRTE_PMD_NTNIC=n + + +# # Compile link bonding PMD library # CONFIG_RTE_LIBRTE_PMD_BOND=y diff --git a/doc/guides/nics/features/ntnic.ini b/doc/guides/nics/features/ntnic.ini new file mode 100644 index 000..b6cfc5a --- /dev/null +++ b/doc/guides/nics/features/ntnic.ini @@ -0,0 +1,15 @@ +; +; Supported features of the 'ntnic' network poll mode driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Link status = Y +Queue start/stop = Y +Promiscuous mode = Y +Jumbo frame = Y +Basic stats = Y +Multiprocess aware = Y +x86-32 = Y +x86-64 = Y +Usage doc= Y diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index 92d56a5..5c4205c 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -52,6 +52,7 @@ Network Interface Controller Drivers qede szedata2 thunderx +ntnic virtio vhost vmxnet3 diff --git a/doc/guides/nics/ntnic.rst b/doc/guides/nics/ntnic.rst new file mode 100644 index 000..3f2497c --- /dev/null +++ b/doc/guides/nics/ntnic.rst @@ -0,0 +1,138 @@ +.. BSD LICENSE +Copyright (c) 2016 Napatech A/S +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 Napatech 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, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +NTNIC Poll Mode Driver +== + +The NTNIC poll mode driver library (**librte_pmd_ntnic**) implements support +for **Napatech NIC** 40/50 Gbps adapters. +This PMD is implemented as a pure software virtual device and must be created +by using the EAL --vdev=parameter (parameters are explained i detail later). +It runs on top of the Napatech NIC Driver Suite that must be installed and +started. + +Supported Features +-- + +- RSS (Receive Side Scaling) +- TSS (Transmit Side Scaling) +- Promi
[dpdk-dev] [PATCH] ntnic: add PMD driver
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: 26. august 2016 16:44 > To: Finn Christensen > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] ntnic: add PMD driver > > Welcome, Thanks! > > 2016-08-26 13:44, Finn Christensen: > > +NTNIC Poll Mode Driver > > +== > > + > > +The NTNIC poll mode driver library (**librte_pmd_ntnic**) implements > > +support for **Napatech NIC** 40/50 Gbps adapters. > > +This PMD is implemented as a pure software virtual device and must be > > +created by using the EAL --vdev=parameter (parameters are explained i > detail later). > > +It runs on top of the Napatech NIC Driver Suite that must be > > +installed and started. > > It would help a lot to describe what is the Napatech NIC Driver Suite, and why > it is a virtual driver. I will elaborate on the description to make it more clear and send an update patch. However, the driver is a virtual driver because we already bypasses the kernel stack in our NIC driver and does that in an effective manner. > What is the hardware it runs on? Where can we get it? It is running on a newly developed hardware by Napatech. It is not yet available, but it will soon be. > Where can we download the Driver Suite? When the Napatech NIC is released, the driver suite will then be available for download. If you need something sooner, we will need to make special arrangements. > > > +Supported Features > > +-- > > + > > +- RSS (Receive Side Scaling) > > +- TSS (Transmit Side Scaling) > > +- Promiscuous mode > > +- Basic statistics > > + > > + > > +Prerequisites > > +- > > + > > +Requires Napatech NIC and Napatech NIC Driver Suite installed and > > +running in version **0.3.0** or higher. > > +This includes external libraries and kernel driver for resources > > +allocations and initialization. > > So the Driver Suite is just a library to help implementing the driver for the > Napatech NIC? Yes and no. The driver suite contains additional monitoring and diagnostics tools, but the DPDK PMD only needs a few libraries and the kernel driver. > > Thanks for explaining your solution Thank you for the fast reply. This is really appreciated. Thanks again! Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
[dpdk-dev] [PATCH] ntnic: add PMD driver
> From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: 26. august 2016 18:54 > To: Finn Christensen > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] ntnic: add PMD driver > > On Fri, 26 Aug 2016 13:44:01 +0000 > Finn Christensen wrote: > > > +The NTNIC poll mode driver library (**librte_pmd_ntnic**) implements > > +support for **Napatech NIC** 40/50 Gbps adapters. > > +This PMD is implemented as a pure software virtual device and must be > > +created by using the EAL --vdev=parameter (parameters are explained i > detail later). > > +It runs on top of the Napatech NIC Driver Suite that must be > > +installed and started. > > What is the license of this driver suite? The driver suite is a closed-source driver, which is not free downloadable. > IMHO the upstream DPDK shouldn't be a platform for non-free driver suites. This is our first steps towards opensource, and our upcoming NIC is partly build on HW and SW from our Accelerator products. And since we already bypasses the kernel effectively in our driver, this first solution for a DPDK PMD driver, has been built on top of that software suite. We like the idea of opensource, but we will need to do the transition stepwise, considering our NIC product. We have seen large performance improvements (x4-x7 times with 64 byte packets compared to a std NIC in a phy-ovs-vm-ovs-phy setup utilizing a modified DPDK), and this is the main motivation to go forward and try to push our contribution to DPDK upstream. This is the first step of contributions that we want to make. This DPDK PMD solution is not compileable unless you have our driver. We may need to make that possible, so that a free downloadable driver can be retrieved. Once this is said, we thought that the DPDK was BSD licensed and I must admit that we have failed to see this limitation that you are mentioning. Is there another license or agreement text that we need to read? Thanks for your repy! Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
[dpdk-dev] [PATCH] ntnic: add PMD driver
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: 29. august 2016 12:04 > To: Finn Christensen > Cc: dev at dpdk.org; Stephen Hemminger > Subject: Re: [dpdk-dev] [PATCH] ntnic: add PMD driver > > 2016-08-29 06:22, Finn Christensen: > > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > > What is the license of this driver suite? > > > > The driver suite is a closed-source driver, which is not free downloadable. > > > > > IMHO the upstream DPDK shouldn't be a platform for non-free driver > suites. > > > > This is our first steps towards opensource, and our upcoming NIC is > > partly build on HW and SW from our Accelerator products. > > And since we already bypasses the kernel effectively in our driver, > > this first solution for a DPDK PMD driver, has been built on top of > > that software suite. > > We like the idea of opensource, but we will need to do the transition > > stepwise, considering our NIC product. > > I think the first step should be to free the lowest level, here the code you > build your drivers on. I think that will not become a problem. > > We have seen large performance improvements (x4-x7 times with 64 byte > > packets compared to a std NIC in a phy-ovs-vm-ovs-phy setup utilizing > > a modified DPDK), and this is the main motivation to go forward and > > try to push our contribution to DPDK upstream. > > This is the first step of contributions that we want to make. > > This DPDK PMD solution is not compileable unless you have our driver. > > Not being able to compile the PMD is a real problem for maintenance. > The PMD would be considered as dead code, so is forbidden. Yes, that does fully make sense. We will come up with a way to freely download a driver with header files and libraries to make it possible for anyone to build the PMD. > > > We may need to make that possible, so that a free downloadable driver > > can be retrieved. > > > > Once this is said, we thought that the DPDK was BSD licensed and I > > must admit that we have failed to see this limitation that you are > mentioning. > > Is there another license or agreement text that we need to read? > > Maybe you'll find some interesting parts in the contributing guide. > But honestly, I think you have already done the right thing in your case: > you sent some code and open the discussion :) Now you just need to enable > a free compilation environment for your patch. > Thanks We will do that. I'll get back with an updated patch once this has been established. Thank you both for your help on this. Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
[dpdk-dev] [PATCH v3] ntnic: add PMD driver
I have changed the state to rejected. Sorry for not doing this earlier. Finn Christensen -Original Message- From: Ferruh Yigit [mailto:ferruh.yi...@intel.com] Sent: 21. november 2016 14:48 To: Finn Christensen ; Thomas Monjalon Cc: Neil Horman ; dev at dpdk.org; stephen at networkplumber.org Subject: Re: [dpdk-dev] [PATCH v3] ntnic: add PMD driver On 9/12/2016 8:34 AM, fc at napatech.com (Finn Christensen) wrote: >> -Original Message- >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] >> Sent: 10. september 2016 10:20 >> To: Finn Christensen >> Cc: Neil Horman ; dev at dpdk.org; stephen >> at networkplumber.org >> Subject: Re: [PATCH v3] ntnic: add PMD driver >> >> 2016-09-10 07:58, Finn Christensen: >>> From: Neil Horman [mailto:nhorman at tuxdriver.com] >>>> On Fri, Sep 09, 2016 at 12:48:38PM +, Finn Christensen wrote: >>>>> This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK. >>>>> >>>>> This patch adds support for Napatech NICs to DPDK. This is the >>>>> initial implementation. >>>>> >>>>> Signed-off-by: Finn Christensen >>>>> --- >>>>> v3: >>>>> * Removed the need for binary libraries on build >>>>> v2: >>>>> * Added information how to build the PMD without NIC >>>>> Board Support Package >>>>> * Fixed some formatting issues >>>> >>>> So, this is a step in the right direction, but I think its solving >>>> the wrong problem. If you have a dependency on an external >>>> library, thats ok, and accessing it via dlopen makes it possible to >>>> build the library without having that library present, but it not >>>> really in keeping with the spirit of what I meant. This driver is >>>> still effectively dependent on a binary blob that we have no >>>> visibility into. The better solution is releasing the source for >>>> the ntnic and ntos libraries. The license file in the referenced >>>> git tree indicates its BSD licensed, so I don't think there should >>>> be a problem in >> doing that. >>>> >>>> Neil >>>> >>> No, unfortunately the ntapi is not BSD licensed, only the header >>> files that you can freely download are. >>> We are building this NT NIC by using parts or our technology from >>> our capture adapters and that is using closed source software. >>> >>> We are new to opensource and we want to go that way, but we haven't >>> yet a complete stand-alone driver ready that we can put into the >>> DPDK PMD to have a complete self contained and open sourced DPDK >>> PMD, that only needs the actual HW NIC plugged in to run. >>> Therefore this version is implemented as a virtual device, exactly >>> like the PCAP PMD driver is, and it runs on top of a driver that >>> follows the >> NIC itself. >>> >>> In regards to the DPDK functionality we do not see that anything is missing. >>> I cannot either see where we should add source code, because it is >>> not part of the DPDK package and it should not be either. >>> >>> One of the things I really liked about the DPDK open source project >>> is that it uses BSD licensing not GPL. Therefore, I must admit, we >>> completely failed to see that the "spirit" of the DPDK community is >>> not really BSD. Our view of this community was that the main driving >>> force of it was to be able to make DPDK run on everything anywhere >>> effectively, in a global contributing community, without any >>> legally >> constrains prohibiting us to do so. >> >> It is difficult to define what is the spirit of a community, >> especially only after few mail exchanges. >> I agree that running on everything anywhere is a nice goal. >> Here Neil, as a RedHat developer, is probably concerned about >> enabling your driver in a distribution. It seems your model is not >> compatible with the "anywhere goal" and will be disabled in that case, until >> it is fully open. > > The ntnic PMD is not enabled by default and I think it should not be > either. To enable it in a distribution for general purposes seems > wrong. In that respect we see no difference between the PCAP PMD and this > ntnic PMD. > >>> However, this is our standing, and I don't know what else to do. >>> Please advise or NAK this PMD. >> >> I do not remember having already seen su
