From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by dpdk.org (Postfix) with ESMTP id 297085934 for ; Thu, 7 May 2015 16:02:23 +0200 (CEST) Received: by qku63 with SMTP id 63so27711483qku.3 for ; Thu, 07 May 2015 07:02:22 -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=QQjSIWSwos7UXmPM+Dm+Ob/UIcUsngVff5/LhqNWsuU=; b=QlxBVvdUjCsps+QTwTu3qD+AeGUImg29QnIPaWQrsMCsE/vrZA9tGY2UQH+3weXCxm 4fnmNh4+c9Y6U8GKB1xjWFYKIBKvVqdbkK6a9m/iFbha/D8+8Q77qc9yhTALz75WGg4H 3+y9ZJQ/f6WGXtA8VePCXDmslGAdWtpSdhI0+QRJVpuRgH9OLM32HMzB6PCBFWJvFiGZ c7W6ebLaKs3FhTXtonwkax3utrikJH5WBIeiIa/czjzKhdBNRCA98uMoY9LP0nf9ioh9 yYjncM669l6BklDiq4dh6ACvjqX1QbMJC7MURV198GtZclxyjbowEhEFh6AmI707Vmpm 6u5Q== X-Gm-Message-State: ALoCoQnSB/ugyC36XFSjMwxQ890RyoOzRzkE1WCyrdOtxmH3FQjyNr+iUg7TMuNF39FUY/50ODOj MIME-Version: 1.0 X-Received: by 10.140.233.214 with SMTP id e205mr5571144qhc.68.1431007342620; Thu, 07 May 2015 07:02:22 -0700 (PDT) Received: by 10.140.221.80 with HTTP; Thu, 7 May 2015 07:02:22 -0700 (PDT) In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> Date: Thu, 7 May 2015 17:02:22 +0300 Message-ID: From: Avi Kivity To: "O'Driscoll, Tim" 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: Thu, 07 May 2015 14:02:23 -0000 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. [1] http://seastar-project.org