[dpdk-dev] [PATCH v3] ntnic: add PMD driver

Finn Christensen fc at napatech.com
Mon Nov 21 14:55:05 CET 2016

I have changed the state to rejected. Sorry for not doing this earlier.

Finn Christensen

-----Original Message-----
From: Ferruh Yigit [mailto:ferruh.yigit at intel.com]
Sent: 21. november 2016 14:48
To: Finn Christensen <fc at napatech.com>; Thomas Monjalon <thomas.monjalon at 6wind.com>
Cc: Neil Horman <nhorman at tuxdriver.com>; 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 <fc at napatech.com>
>> Cc: Neil Horman <nhorman at tuxdriver.com>; 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 +0000, 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 <fc at napatech.com>
>>>>> ---
>>>>> 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 to be any different than that of the PCAP PMD, since
> that is also dependent on external header files and externally built libraries.
> Of course we see the difference in open source vs close source
> library. But we cannot see that is has any influence in the usage or functionality of the DPDK.
> Thanks for this discussion!

The patch is still waiting in the patchwork.

This requires a high level discussion. Any suggestion on how to proceed?

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.

More information about the dev mailing list