From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id CB4D3C442 for ; Mon, 27 Apr 2015 15:46:01 +0200 (CEST) Received: by wizk4 with SMTP id k4so100159793wiz.1 for ; Mon, 27 Apr 2015 06:46:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/xzGNO4RPo4d17Qn+G7gCEXihCVC1RkY1fxOLC7fcuI=; b=b56jjBUowEl8OAgiXCWiudoeO1Qlp5LurIXNuuSMDLNqxYtZtDGugidNy28+IOwjmK ktRP3c+Thtt8mUb/Y8cKMaDpo+10HQ1Y+cboV9dPQaJVLNxESd6rz/7hnjkIffQ9m9BA +oLqOjLBUrZhaOPdhsKRAQ/gRkzEZaER6QJot79SY+O9JfQucLWPwNlGW1OuwikgXpjZ LkN8QJQOuGnPGPLytThX7lmXWL92LalL76WbuijaPxpv7i1uq+8E/PZQkMsGCrq+b9uO nBV88BmFXxY0byKKIGDJ+fUhn3htFDr+CkdOoVQyBGCfNOHj71Quhp947mnbizOSLO10 YUcA== X-Gm-Message-State: ALoCoQl88QiOG2KKw6tiCreyMotIsmyTXHDZ+C5esXae5y49cIerxGTzCcV+rbogl0fpcO3cTSiz MIME-Version: 1.0 X-Received: by 10.180.77.170 with SMTP id t10mr20628549wiw.5.1430142361619; Mon, 27 Apr 2015 06:46:01 -0700 (PDT) Received: by 10.194.36.193 with HTTP; Mon, 27 Apr 2015 06:46:01 -0700 (PDT) In-Reply-To: <20150425121030.GA26734@neilslaptop.think-freely.org> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <20150424185123.GD32445@hmsreliant.think-freely.org> <20150425121030.GA26734@neilslaptop.think-freely.org> Date: Mon, 27 Apr 2015 08:46:01 -0500 Message-ID: From: Jay Rolette To: Neil Horman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Mon, 27 Apr 2015 13:46:02 -0000 On Sat, Apr 25, 2015 at 7:10 AM, Neil Horman wrote: > 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. > > > > > 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? > (1) was just my response to Luke about what would motivate a company to submit patches if the license didn't require it (GPL vs BSD discussion). Maint overhead had little to do with why we decided to use DPDK. (2) is certainly true enough, but not really all that big of a factor in the reasons why our participation isn't at some higher level. I'd say there are two primary factors: *New Contributors* Dropping a major patch on a project where we have no history would be foolish and frustrating. Every open source project has a vibe to it and its own way of operating. It normally takes some time to figure that out, but for major contributions, it generally involves a level of trust. Major code drops or patches aren't generally well received unless it is from someone that is known and trusted by the community. Building up that trust ("street cred") normally involves participating in smaller, less risky ways. Answering questions where you can, small patches to fix bugs, possibly reviewing code (although this can be iffy as well), etc. This facilitates understanding the process, who the players are and what sort of toes you are likely to step on. It also gives you time to ramp up on the internals of the code and philosophy/goals of the project better. With DPDK, performance is obviously more important than portability. Until recently, very little care was given to API stability or the impact that has on DPDK apps. Both of those are very different approaches than typical and it affects what you might do when approaching submitting a patch. If you want to build up the number of folks contributing, expect them to start small and make sure it actually GOES somewhere. The first patch I submitted in mid-December had some quick responses and questions back-and-forth, but then stalled on a couple of undocumented minor stylistic things (comment style and use of #ifdefs). I never heard anything back and 4.5 months later, a simple startup opto is still sitting there. The second patch I submitted (also mid-December) got no response at all for 4 months. I've replied to the feedback that came eventually, but once again, no subsequent answers. Neither of the patches were important, but the process doesn't exactly inspire a strong desire to contribute more. *Different Goals* I see at least two different sets of people on the mailing list. The heavy hitters generally have a product reason for their high level of involvement with DPDK. For Intel and 6Wind, the reasons are pretty obvious. Same deal with NIC vendors. For large companies, sometimes the reasons are less obvious, but supporting certain open source projects can be strategic for them for several reasons. For this group, improving DPDK itself is important enough to dedicate resources to. It's a goal in and of itself, even if it isn't the main goal. The other group are what I'd call "DPDK users". They picked DPDK because it fit a need they had in their product/project, just like they might pick Linux or FreeBSD, Apache, gcc and any number of libraries. I'm in that second group. DPDK has been tremendously valuable to me, so I'm happy to contribute back where I can, but it isn't my goal. I've got a product to build and DPDK is another piece of the puzzle. The same is true of Linux and all the various libraries we use. The nature of the contributions from those two groups are going to be different. 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? > Yes, there are problems we've hit with DPDK that we haven't fed back the fixes for. We generally do, but sometimes it isn't clear that what we are doing would be considered a general problem. Sometimes we fix things with hacks that work for us, but aren't necessarily a good "real" fix that should go into DPDK. On the "desired additions" bit, it's less clear. Is it product specific or something that is general purpose DPDK-wise? As a startup company, we don't have the luxury yet of being able to spend the time required to refactor subsystems/modules so it can be shared. Hopefully we'll succeed to the point where those discussions are possible :) In the meantime, we do provide feedback on RFCs that come across the mailing list on things where we have experience. Most of that seems to just go in the bit bucket unfortunately. There's not a lot of actual *discussion* / back-and-forth on things here. 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. > It should be clear from above that yes, we have a strong bias on development of our product. We are a startup with a very finite runway. Just the reality that we live in... There are no executives or senior management telling us we can't contribute more, so that isn't the case for us. However, it certainly could be at other companies. One thing I'd describe differently as a "DPDK user" is the notion of treating it as a customer. Treating it as a customer implies there are expectations of (or support contracts for) things being fixed, features being added, etc. I believe we treat it like we do any other open source project. If we run into problems, we search for answers and if we don't find anything, we ask the community in case someone else can help. When others ask for help, we help when we can. Our ability to do so grows over time. 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? > Hopefully my comments above address your questions and what I see as the reasons. Cheers, Jay