From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 60B5112A8 for ; Thu, 7 May 2015 17:27:50 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 07 May 2015 08:27:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,384,1427785200"; d="scan'208";a="725384158" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga002.jf.intel.com with ESMTP; 07 May 2015 08:27:49 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 7 May 2015 08:27:48 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by ORSMSX152.amr.corp.intel.com (10.22.226.39) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 7 May 2015 08:27:48 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.26]) by fmsmsx111.amr.corp.intel.com ([169.254.12.169]) with mapi id 14.03.0224.002; Thu, 7 May 2015 08:27:48 -0700 From: "Wiles, Keith" To: Avi Kivity , "O'Driscoll, Tim" Thread-Topic: [dpdk-dev] Beyond DPDK 2.0 Thread-Index: AdB4KSdm1ftzhuzCQX2G2XNq9ZOWFAE5VxLQAv6mNgD//6KBAA== Date: Thu, 7 May 2015 15:27:47 +0000 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.128.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1B3AB5F93154FC45994F2A77856719B3@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 07 May 2015 15:27:51 -0000 On 5/7/15, 7:02 AM, "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@dpdk.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. The DPDK system is somewhat divided now between the EAL, PMDS and utility functions like malloc/rings/=8A The problem I see is the PMDs need a framework to be usable and the EAL plus the ethdev layers provide that support today. Setting up and initializing the DPDK system is pretty clean just call the EAL init routines along with the pool creates and the basic configs for the PMDs/hardware. Once the system is inited one can create new threads and not requiring anyone to use DPDK launch routines. Maybe I am not understanding your needs can you explain more? > >[1] http://seastar-project.org