From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Finn Christensen <fc@napatech.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
dev@dpdk.org,
"stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] [PATCH v3] ntnic: add PMD driver
Date: Sat, 10 Sep 2016 10:20:06 +0200 [thread overview]
Message-ID: <1913786.NX7M2nQ5WY@xps13> (raw)
In-Reply-To: <c5e8998f3e0d4a8e9a26b6457193795e@napatech.com>
2016-09-10 07:58, Finn Christensen:
> From: Neil Horman [mailto:nhorman@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@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.
> 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.
next prev parent reply other threads:[~2016-09-10 8:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 13:44 [dpdk-dev] [PATCH] " Finn Christensen
2016-08-26 14:44 ` Thomas Monjalon
2016-08-26 16:32 ` Finn Christensen
2016-08-27 9:07 ` Thomas Monjalon
2016-08-26 16:54 ` Stephen Hemminger
2016-08-29 6:22 ` Finn Christensen
2016-08-29 10:04 ` Thomas Monjalon
2016-08-29 12:00 ` Finn Christensen
2016-09-08 11:14 ` [dpdk-dev] [PATCH v2] " Finn Christensen
2016-09-08 13:49 ` Neil Horman
2016-09-08 14:22 ` Finn Christensen
2016-09-09 12:48 ` [dpdk-dev] [PATCH v3] " Finn Christensen
2016-09-09 13:51 ` Neil Horman
2016-09-10 7:58 ` Finn Christensen
2016-09-10 8:20 ` Thomas Monjalon [this message]
2016-09-10 18:31 ` Stephen Hemminger
2016-09-12 8:08 ` Finn Christensen
2016-09-12 12:33 ` Neil Horman
2016-09-12 7:34 ` Finn Christensen
2016-11-21 13:47 ` Ferruh Yigit
2016-11-21 13:55 ` Finn Christensen
2016-09-12 12:32 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1913786.NX7M2nQ5WY@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=fc@napatech.com \
--cc=nhorman@tuxdriver.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).