[dpdk-dev] Beyond DPDK 2.0

[Neil Horman]

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 at 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