DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Jay Rolette <rolette@infiniteio.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Beyond DPDK 2.0
Date: Sat, 25 Apr 2015 08:10:31 -0400	[thread overview]
Message-ID: <20150425121030.GA26734@neilslaptop.think-freely.org> (raw)
In-Reply-To: <CADNuJVpRciO61kvCkjFEbQDRiVpgMgnT2VhbzXNTQp-eLnHNAw@mail.gmail.com>

On Fri, Apr 24, 2015 at 02:55:33PM -0500, Jay Rolette wrote:
> On Fri, Apr 24, 2015 at 1:51 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> 
> > So, I hear your arguments, and its understandable that you might not want
> > a GPL
> > licensed product, given that the DPDK is a library (though I'm not sure
> > what the
> > aversion to LGPL would be).  Regardless, I think this conversation is a
> > bit more
> > about participation than license choice.  While you are correct, in that
> > the
> > first step to support (by which I presume you mean participation in the
> > community) is use, the goal here is to get people contributing patches and
> > helping increase the usefulness of DPDK.
> 
> 
> > Given that DPDK is primarily licensed as BSD now, whats preventing you, or
> > what
> > would encourage you to participate in the community?  I see emails from
> > infiniteio addresss in the archives asking questions and making
> > suggestions on
> > occasion, but no patches.  What would get you (or others in a simmilar
> > situation) to submit those?
> >
> 
> 36 hours in the day? :)
> 
> It's not a lot, but we've submitted a couple of small patches. It's mostly
> a matter of opportunity. We submit patches as we come across DPDK bugs or
> find useful optos.
> 
> *Patches*
> 
>    - replaced O(n^2) sort in sort_by_physaddr() with qsort() from standard
>    library <http://dpdk.org/dev/patchwork/patch/1955/>
>    - Fixed spam from kni_allocate_mbufs() when no mbufs are free. If mbufs
>    exhausted, 'out of memory' message logged at EXTREMELY high rates. Now logs
>    no more than once per 10 mins <http://dpdk.org/dev/patchwork/patch/2062/>
> 
> *Reviews*
> 
>    - kni: optimizing the rte_kni_rx_burst
>    <http://dpdk.org/dev/patchwork/patch/84/>
>    - [PATCH RFC] librte_reorder: new reorder library
>    <http://www.dpdk.io/ml/archives/dev/2014-October/006767.html>
>    - [PATCH v2 09/17] i40e: clean log messages
>    <http://dpdk.org/ml/archives/dev/2014-September/005133.html> (several in
>    that series, but I figure 1 link is plenty)
> 
> *Other*
> Not really patches or reviews, but trying to participate in the community:
> 
>    - VMware Fusion + DPDK and KNI
>    <http://dpdk.org/ml/archives/dev/2014-August/004737.html>
>    - Appropriate DPDK data structures for TCP sockets
>    <http://patchwork.dpdk.org/ml/archives/dev/2015-February/013941.html>
>    - kernel: BUG: soft lockup - CPU#1 stuck for 22s! [kni_single:1782]
>    <http://patchwork.dpdk.org/ml/archives/dev/2015-February/013335.html>
>    - segmented recv ixgbevf
>    <http://dpdk.org/ml/archives/dev/2014-November/007621.html>
> 
> Jay

Understand, I'm not trying to single you out here.  I see that you, and others
from infiniteio have had some participation in the project, and thats great, and
appreciated. I'm more focused on why that level of participation is not higher
(not only from you, but from the larger presumed user base in general).  As
noted at the start of this thread, one of the goals of this discussion is to
find ways to maximize participation in the project, and from you I'm hearing
that:

1) you use the dpdk because it lowers maintenence overhead
2) you don't participate more in the project because your product work schedule
doesn't allow you to do so.

Are those both accurate statements?

Can we also assume, for the sake of discussion that you have encountered
problems, or desired additions to the DPDK, for which you have implemented your
own code in the library that is not contributed back to the DPDK? 

If that is true, perhaps part of this conversation needs to revolve around the
tangible benefits of contributing that code back to the upstream project (the
aforementioned reduction of overhead) as well as the intangible (thought
leadership as the project develops).  Its been my experience, that these
situations often arise because management at a company often places a strong
bias on development of their product over participation in the open source
portion of it, treating the latter as if they are a customer of it, rather than
a participant in it, and it would be my desire to see that bias adjusted so as
to allow you greater freedom to participate in the project.

Would you agree to that assessment?  If so, how would you suggest that we, as a
community address this, and illustrate the appeal of contribution and
participation to your company and the benefits thereof?

Best
Neil

  reply	other threads:[~2015-04-25 12:10 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
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 [this message]
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=20150425121030.GA26734@neilslaptop.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=rolette@infiniteio.com \
    /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).