From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Boule Subject: Re: Beyond DPDK 2.0 Date: Thu, 07 May 2015 16:34:34 +0200 Message-ID: <554B77FA.3050404@6wind.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Avi Kivity , "O'Driscoll, Tim" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Avi, On 05/07/2015 04:02 PM, Avi Kivity wrote: > On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim > wrote: > >> Does anybody have any input or comments on this? >> >> >>> -----Original Message----- >>> From: O'Driscoll, Tim >>> Sent: Thursday, April 16, 2015 11:39 AM >>> To: dev-VfR2kkLFssw@public.gmane.org >>> Subject: Beyond DPDK 2.0 >>> >>> 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. >>> >>> Since then, the project has grown significantly: >>> - The number of commits and mailing list posts has increased >>> steadily. >>> - Support has been added for a wide range of new NICs (Mellanox >>> support submitted by 6WIND, Cisco VIC, Intel i40e and fm10k etc.). >>> - DPDK is now supported on multiple architectures (IBM Power support >>> in DPDK 1.8, Tile support submitted by EZchip but not yet reviewed or >>> applied). >>> >>> While this is great progress, we need to make sure that the project is >>> structured in a way that enables it to continue to grow. To achieve >>> this, 6WIND, Red Hat and Intel would like to start a discussion about >>> the future of the project, so that we can agree and establish processes >>> that satisfy the needs of the current and future DPDK community. >>> >>> We're very interested in hearing the views of everybody in the >>> community. In addition to debate on the mailing list, we'll also >>> schedule community calls to discuss this. >>> >>> >>> Project Goals >>> ------------- >>> >>> Some topics to be considered for the DPDK project include: >>> - Project Charter: The charter of the DPDK project should be clearly >>> defined, and should explain the limits of DPDK (what it does and does >>> not cover). This does not mean that we would be stuck with a singular >>> charter for all time, but the direction and intent of the project should >>> be well understood. >> > > > One problem we've seen with dpdk is that it is a framework, not a library: > it wants to create threads, manage memory, and generally take over. This > is a problem for us, as we are writing a framework (seastar, [1]) and need > to create threads, manage memory, and generally take over ourselves. > > Perhaps dpdk can be split into two layers, a library layer that only > provides mechanisms, and a framework layer that glues together those > mechanisms and applies a policy, trading in generality for ease of use. > > [1] http://seastar-project.org > I fully agree with this analysis/proposal. And I think that: - the associated modifications should be done ASAP, - the underlying design rules that this proposal refers to should drive the design and review of new DPDK features. Regards, Ivan