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 5108CADA2 for ; Fri, 24 Apr 2015 19:00:43 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Ylgxx-0001kx-O6; Fri, 24 Apr 2015 13:00:40 -0400 Date: Fri, 24 Apr 2015 13:00:36 -0400 From: Neil Horman To: "O'Driscoll, Tim" Message-ID: <20150424170035.GC32445@hmsreliant.think-freely.org> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D2C241@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D2C241@IRSMSX102.ger.corp.intel.com> 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: Fri, 24 Apr 2015 17:00:43 -0000 On Fri, Apr 24, 2015 at 03:29:01PM +0000, O'Driscoll, Tim wrote: > > > From: lukego@gmail.com [mailto:lukego@gmail.com] On Behalf Of Luke Gorrie > > > > > On 16 April 2015 at 12:38, O'Driscoll, Tim 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? > This is a good question, and I know efforts are underway to that end. I can tell you for certain that: 1) Many DPDK enhancement (tx batching for instance) are being investigated for kernel integration 2) The DPDK will never be backported in its entirety to the kernel (too many x86 specific bits/optimizations), and api requirements. As such, I think you'll find that the kernel will approach, but never quite reach the performance goals of the DPDK. As such I think the DPDK will always be something of a niche market for user to whoom every last ounce of performance is the primary requirement (even above and beyond compatibility with standard OS interfaces), but it will continue to exist independently as a project, as that user demographic is out there. > > 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. > Well, BSD licensing is a guarantee that users won't contribute back to the project (look at openssh for an example). That said, the space that DPDK operates in does tend to make a it a building block for larger applications that are not of general use, by implementors that are not tradionally inclined to contrubute back to the community. I think what we need here is a 'killer-app' that makes the DPDK relevant to developers who are biased toward an open source mindset. Rather than a telco app that sits on one vendors hardware, never to be used by other telcos, we should support and encourage the participation of open projects who might benefit from using DPDK to accelerate network functionality. OVS is a great example here. If we can make it easy for them to use DPDK to get better performance, I think we'll see a larger uptake in adoption. Neil > 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. >