Re: [dpdk-dev] Beyond DPDK 2.0

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 24 Apr 2015 09:47:58 +0200
Luke Gorrie <luke@snabb.co> wrote:

> Hi Tim,
> 
> On 16 April 2015 at 12:38, O'Driscoll, Tim <tim.o'driscoll@intel.com> wrote:
> 
> > Following the launch of DPDK by Intel as an internal development project,
> > the launch of dpdk.org by 6WIND in 2013, and the first DPDK RPM packages
> > for Fedora in 2014, 6WIND, Red Hat and Intel would like to prepare for
> > future releases after DPDK 2.0 by starting a discussion on its evolution.
> > Anyone is welcome to join this initiative.
> >
> 
> Thank you for the open invitation.
> 
> I have a couple of questions about the long term of DPDK:
> 
> 1. How will DPDK manage overlap with other project over time?
> 

In general DPDK will be successful only if it stick to differentiating
technology and avoids NIH and reinvention. 
I.e if DPDK tries to redo things in libc or have special
needs, then DPDK becomes harder to use for many things and makes DPDK applications
hard to integrate with other libraries. It is bad enough now that each
library has its own view of threads.

> DPDK into the kernel than the rest of the good bits of the kernel into DPDK?

If DPDK tries to become too general it will lose the performance
advantage. The kernel has to serve all types of applications,
and have many layers of services therefore it is slow. For example,
if every DPDK facility had its own locking and was thread safe
the performance would end up being about the same as just using
kernel.


> 2. How will DPDK users justify contributing to DPDK upstream?
> 
> Engineers in network equipment vendors want to contribute to open source,
> but what is the incentive for the companies to support this? This would be
> easy if DPDK were GPL'd (they are compelled) or if everybody were
> dynamically linking with the upstream libdpdk (can't have private patches).
> However, in a world where DPDK is BSD-licensed and statically linked, is it
> not both cheaper and competitively advantageous to keep fixes and
> optimizations in house?

There are several incentives.
a. Brocade views open source as a differentiator from competitors and wants
to contribute as much as possible to open source, this includes DPDK, Open Daylight
and Openstack. Marketing benefit.

b. By contributing what we do back we get benefits of more testing and review.
Several bugs have been spotted in areas that were not covered because the current
product usage and testing will not cover all possibilities.

c. By contributing back, the contributor gets to set the agenda and make the API's.
If you go first, you set the API and you can make life hard for competitors or
other users who do the same thing but haven't contributed. In fact, the worst pain
for us was cases where there were two or more parallel implementations of something
to deal with (ie vmxnet3).  "Lead, follow, or get of the way"