From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by dpdk.org (Postfix) with ESMTP id AB824C6BC for ; Tue, 28 Apr 2015 19:48:31 +0200 (CEST) Received: by pdbqd1 with SMTP id qd1so2166484pdb.2 for ; Tue, 28 Apr 2015 10:48:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=7d3boL+lriYt4uUHMWFUyJ1L0jeD7Kr/dEhRQeOMuNU=; b=d3t4b9Ci76rfMFh+/xXgUY1EUkZXhvNUH6rlvQc9x3xK+cVF09+nSzSgXbSCaHNcrU PTMuckRyAZV50VP5pAbGjprPlZgVCj9aOk5EMEMbVvPyfOgZXa4BhKvtDUqh+Y/XJnMN oNgrUCQSKJIPYSVSomeUf8AXVMeCRj9/UQxvbjsMaUa/BTww+uErvp7fdTiq1VIt+hvJ Ui9oGkiQBcM42telQ3DhHBqVWBD15kqLFr4vLZzVfLx8E2kFGwFftYXNyjEYU8fmnpw2 BzjDkp7cxxpksNqY+0hvvZoD6lTQv/B/5v3M7Gls5Nzr6mo6yoGt030bfb/25BYznfCM limw== X-Gm-Message-State: ALoCoQn8YVV6iSZhs/YCNdGt77iuxYYa83E8l6/fHSmM1c3mXEpHOs0++Dwg5bZK0SKDqeaG61MB X-Received: by 10.70.128.130 with SMTP id no2mr34365191pdb.95.1430243310854; Tue, 28 Apr 2015 10:48:30 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id cp10sm23074343pdb.44.2015.04.28.10.48.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 10:48:30 -0700 (PDT) Date: Tue, 28 Apr 2015 10:48:34 -0700 From: Stephen Hemminger To: Luke Gorrie Message-ID: <20150428104834.522b271e@urahara> In-Reply-To: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 28 Apr 2015 17:48:32 -0000 On Fri, 24 Apr 2015 09:47:58 +0200 Luke Gorrie wrote: > Hi Tim, > > 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 general DPDK will be successful only if it stick to differentiating technology and avoids NIH and reinvention. I.e if DPDK tries to redo things in libc or have special needs, then DPDK becomes harder to use for many things and makes DPDK applications hard to integrate with other libraries. It is bad enough now that each library has its own view of threads. > DPDK into the kernel than the rest of the good bits of the kernel into DPDK? If DPDK tries to become too general it will lose the performance advantage. The kernel has to serve all types of applications, and have many layers of services therefore it is slow. For example, if every DPDK facility had its own locking and was thread safe the performance would end up being about the same as just using kernel. > 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? There are several incentives. a. Brocade views open source as a differentiator from competitors and wants to contribute as much as possible to open source, this includes DPDK, Open Daylight and Openstack. Marketing benefit. b. By contributing what we do back we get benefits of more testing and review. Several bugs have been spotted in areas that were not covered because the current product usage and testing will not cover all possibilities. c. By contributing back, the contributor gets to set the agenda and make the API's. If you go first, you set the API and you can make life hard for competitors or other users who do the same thing but haven't contributed. In fact, the worst pain for us was cases where there were two or more parallel implementations of something to deal with (ie vmxnet3). "Lead, follow, or get of the way"