From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 8CDCECF9 for ; Thu, 7 May 2015 17:33:44 +0200 (CEST) Received: by wgin8 with SMTP id n8so47446417wgi.0 for ; Thu, 07 May 2015 08:33:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6CbEhdgjJll1kftTAMF1yFc2Nx45H5ZdmjHb1UxLhH0=; b=D+7lda3Yml45aos7pSrgbT+x8pLc3Xyo6LvNzyPJwuGvjv5Hh6e4QSnYhqec89r2wW xtuyw7HnRH7DW+Of70waKsWmpiROM9dmlB/eT5/3aydFOpXm0CCZg4SXHYzPqlGgiqY/ EZu16xLR3NQud2BrbCsJguoXSjtPUOHMKelGjL62sJoHM+9H8Dq8pdpl74IEbCfR1Jqo FCs5X3whRVqjYnw5z3KD9OG2At0tzzNWM9cOlaHXoFFJvpLINLIWeY2KQ0TX9BhxNfid 08zhDa+ngGesn/RcbInzDzAGX6dm08YlJbhJL+aL6djpC6CPykMOVEjYQ3qE2hwIt3xk rDtQ== X-Gm-Message-State: ALoCoQlhrZUjnJ+29BP1HLYJuu804VTZjAimRuQ+6yjll7wuRT8vlZPS3u53T1F21iZ9Ad5CEWXa X-Received: by 10.180.37.73 with SMTP id w9mr7701436wij.7.1431012824457; Thu, 07 May 2015 08:33:44 -0700 (PDT) Received: from avi.cloudius ([212.143.139.214]) by mx.google.com with ESMTPSA id ju2sm4530491wid.12.2015.05.07.08.33.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 08:33:43 -0700 (PDT) Message-ID: <554B85D5.6010808@cloudius-systems.com> Date: Thu, 07 May 2015 18:33:41 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Wiles, Keith" , "O'Driscoll, Tim" References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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:33:44 -0000 On 05/07/2015 06:27 PM, Wiles, Keith wrote: > > 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/Š > > 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? An initialization routine that accepts argc/argv can hardly be called clean. In seastar, we have our own malloc() (since seastar is sharded we can provide a faster thread-unsafe malloc implementation). We also have our own threading, and since dpdk is an optional component in seastar, dpdk support requires code duplication. I would like to launch my own threads, pin them where I like, and call PMD drivers to send and receive packets. Practically everything else that dpdk does gets in my way, including mbuf pools. I'd much prefer to allocate mbufs myself. >> [1] http://seastar-project.org