From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id 0310ACF9 for ; Thu, 7 May 2015 17:33:37 +0200 (CEST) Received: by wiun10 with SMTP id n10so64520390wiu.1 for ; Thu, 07 May 2015 08:33:36 -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=l0QbtptglpQh9Lwrv8E61betCWlF50iBkQzYn/ZVdCPytKp8/ZjpRIq7lz6Gh9gCmQ JVfCsR7S6oMVkaSyAw9FM0GvzXQnI/Y8rGHg7bJy7U4ujNTDm5V/js47M1eUL9qMLX/5 Nk5k4iAbKdVgRSHii1/rHjo7DSkpxWyZiIyBNnHcfTnxT8h2KGr5h/tNpvCKpCgg++UJ 4kDugNleQ5S2EfVJtOjzvK8BYlQMJ1VSPttvOMdId7AxgQtAy2tQ0TFEiNSv8Ha9gQv2 7ACQJB/WEhU0ZVYrZBbj2bqD6J6NwO+o5XpiC6K1UNqduhVUTVxiHFS/x07xVovaNTc8 j7Ww== X-Gm-Message-State: ALoCoQnoe6yl478SLkfvK+SQy8DGpYdbcz6qPB94r4DxOWs9UwUO0Z8kFilpOWNs4BVLb8nk+ibc X-Received: by 10.180.97.129 with SMTP id ea1mr8003341wib.24.1431012816808; Thu, 07 May 2015 08:33:36 -0700 (PDT) Received: from avi.cloudius ([212.143.139.214]) by mx.google.com with ESMTPSA id di7sm4508899wib.23.2015.05.07.08.33.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 08:33:34 -0700 (PDT) Message-ID: <554B85CD.1080404@cloudius-systems.com> Date: Thu, 07 May 2015 18:33:33 +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:37 -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