From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Beyond DPDK 2.0 Date: Thu, 07 May 2015 18:33:41 +0300 Message-ID: <554B85D5.6010808@cloudius-systems.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: "Wiles, Keith" , "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" 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-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 o= r >>>> 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 abou= t >>>> 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 doe= s >>>> not cover). This does not mean that we would be stuck with a singula= r >>>> 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 libr= ary: >> it wants to create threads, manage memory, and generally take over. T= his >> 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 utili= ty > 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? An initialization routine that accepts argc/argv can hardly be called cle= an. In seastar, we have our own malloc() (since seastar is sharded we can=20 provide a faster thread-unsafe malloc implementation). We also have our=20 own threading, and since dpdk is an optional component in seastar, dpdk=20 support requires code duplication. I would like to launch my own threads, pin them where I like, and call=20 PMD drivers to send and receive packets. Practically everything else=20 that dpdk does gets in my way, including mbuf pools. I'd much prefer to=20 allocate mbufs myself. >> [1] http://seastar-project.org