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

[Ferruh Yigit]

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?