DPDK patches and discussions
 help / color / mirror / Atom feed
From: "O'Driscoll, Tim" <tim.o'driscoll@intel.com>
To: Luke Gorrie <luke@snabb.co>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Beyond DPDK 2.0
Date: Fri, 24 Apr 2015 15:29:01 +0000	[thread overview]
Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D2C241@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <CAA2XHbcFy1Oha0_XMegfaGBBhZcAx_4EyZu5d-LMtqvHTpmATA@mail.gmail.com>


> From: lukego@gmail.com [mailto:lukego@gmail.com] On Behalf Of Luke Gorrie
>
> > 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 some ways DPDK is growing more overlap with other projects e.g. forking/rewriting functionality from
> Linux (e.g. ixgbe), FreeBSD (e.g. Broadcom PMD), GLIBC (e.g. memcpy).
> 
> In other ways DPDK is delegating functionality to external systems instead e.g. the bifurcated driver
> (delegate to kernel) and Mellanox PMD (delegate to vendor shared library).
> 
> How is this going to play out over the long term? And is there an existential risk that it will end up
> being easier to port the good bits of DPDK into the kernel than the rest of the good bits of the kernel
> into DPDK?

Good question. I don't have a good answer to this, but it is something we will need to consider. Perhaps others have opinions?

> 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?
> 
> Today the community is benefiting immensely from the contributions of companies like 6WIND and Brocade,
> but I wonder if this going to be the exception or the rule.

That's another good question. Expanding the community and soliciting more contributions is one of the reasons for initiating this discussion.

At first glance, it can seem cheaper and competitively advantageous for people to keep DPDK enhancements/optimisations in house. However, that's not necessarily the case. There is an advantage in upstreaming these changes because firstly others in the community may contribute further enhancements, and also because it makes upgrading to new DPDK versions easier because those enhancements will be a core part of DPDK rather than having to be ported separately to new DPDK versions.

> That's all from me. Thanks for listening :-).

Thanks for contributing your views.


  reply	other threads:[~2015-04-24 15:29 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16 10:38 O'Driscoll, Tim
2015-04-22 15:11 ` O'Driscoll, Tim
2015-04-22 15:33   ` Stephen Hemminger
2015-04-23 11:36     ` O'Driscoll, Tim
2015-04-24 21:02       ` Dave Neary
2015-05-07 14:02   ` Avi Kivity
2015-05-07 14:34     ` Ivan Boule
2015-05-07 15:27     ` Wiles, Keith
2015-05-07 15:33       ` Avi Kivity
2015-05-07 15:33       ` Avi Kivity
2015-05-07 15:49         ` Wiles, Keith
2015-05-07 16:05           ` Avi Kivity
2015-05-08  4:16             ` Wiles, Keith
2015-05-08  5:29               ` Luke Gorrie
2015-05-08  9:06                 ` Bruce Richardson
2015-05-08  9:32                   ` Luke Gorrie
2015-05-08  9:42                     ` Bruce Richardson
2015-05-08 10:02                       ` Luke Gorrie
2015-05-08 14:44                 ` Wiles, Keith
2015-05-08 16:16                   ` Stephen Hemminger
2015-05-08 10:26               ` Hobywan Kenoby
2015-05-08 13:31                 ` Neil Horman
2015-05-08 16:22                   ` Stephen Hemminger
2015-05-07 15:34     ` Luke Gorrie
2015-05-08  4:31       ` Wiles, Keith
2015-04-24  7:47 ` Luke Gorrie
2015-04-24 15:29   ` O'Driscoll, Tim [this message]
2015-04-24 17:00     ` Neil Horman
2015-04-26  9:07       ` Luke Gorrie
2015-04-24 17:39   ` Jay Rolette
2015-04-24 17:51     ` Matthew Hall
2015-04-25 13:30       ` Marc Sune
2015-04-25 16:08         ` Wiles, Keith
2015-04-26 21:56           ` Neil Horman
2015-04-27  2:29             ` Jim Thompson
2015-04-27 13:07               ` Neil Horman
2015-04-27 16:07               ` Stephen Hemminger
2015-04-28  7:20               ` Dor Laor
     [not found]             ` <D162FA4E.1DED8%keith.wiles@intel.com>
2015-04-27  9:52               ` Marc Sune
2015-04-27 13:39                 ` Wiles, Keith
2015-04-27 15:34                   ` Marc Sune
2015-04-27 10:29               ` Neil Horman
2015-04-27 13:50                 ` Wiles, Keith
2015-04-27 15:23                   ` Neil Horman
2015-04-27 12:38             ` Dave Neary
2015-04-27 13:41               ` Neil Horman
2015-04-27 16:09               ` Stephen Hemminger
2015-04-24 18:12     ` Matt Laswell
2015-04-24 18:51       ` Neil Horman
2015-04-24 19:55         ` Jay Rolette
2015-04-25 12:10           ` Neil Horman
2015-04-27 13:46             ` Jay Rolette
2015-04-28 17:26               ` Neil Horman
2015-04-28 20:02                 ` Jay Rolette
2015-04-28  6:22             ` Matthew Hall
2015-04-28 17:48   ` Stephen Hemminger
2015-04-30 21:31 Wiles, Keith
2015-04-30 21:38 ` Wiles, Keith

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=26FA93C7ED1EAA44AB77D62FBE1D27BA54D2C241@IRSMSX102.ger.corp.intel.com \
    --to=tim.o'driscoll@intel.com \
    --cc=dev@dpdk.org \
    --cc=luke@snabb.co \
    /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).