From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 2B220C33A for ; Sat, 25 Apr 2015 14:10:56 +0200 (CEST) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Ylyv1-0001IR-1a; Sat, 25 Apr 2015 08:10:53 -0400 Date: Sat, 25 Apr 2015 08:10:31 -0400 From: Neil Horman To: Jay Rolette Message-ID: <20150425121030.GA26734@neilslaptop.think-freely.org> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <20150424185123.GD32445@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Beyond DPDK 2.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 12:10:56 -0000 On Fri, Apr 24, 2015 at 02:55:33PM -0500, Jay Rolette wrote: > On Fri, Apr 24, 2015 at 1:51 PM, Neil Horman 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 > - 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 > > *Reviews* > > - kni: optimizing the rte_kni_rx_burst > > - [PATCH RFC] librte_reorder: new reorder library > > - [PATCH v2 09/17] i40e: clean log messages > (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 > > - Appropriate DPDK data structures for TCP sockets > > - kernel: BUG: soft lockup - CPU#1 stuck for 22s! [kni_single:1782] > > - segmented recv ixgbevf > > > 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