From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id A09D4591A for ; Thu, 7 May 2015 17:34:17 +0200 (CEST) Received: by widdi4 with SMTP id di4so247302363wid.0 for ; Thu, 07 May 2015 08:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ss7UeRUq50u9DPD7HzO+PpcscbP7BG1IBKVXr0GlExg=; b=mXrQGgnHv7ThVXpIULQN92/9S0sjUED0fUF6hB4P75BYN6EJWn4Rk9so1AsZ6v90Ve aYzUJZ2QWjvgtDq0foxgivDc75717bHpOsq9bkra4rjbp8hK0xVJWOdx65rMXm4vof0Q LWyrZw6DJwL2HYdwruN5FysnnED6GAugnQG24Szl/JapkpqokPpCBtAQRLpfuThImJWA 1PkhJAXVL8DLw+GkJkciex6eM0juSXLC1+up3H75izsnFCiaNGTb12lPsYHIJ2Aw65P6 /x72qBuqzUG8dbKhxrZOAPgsF/v8ERid/zGErGixHZb28Oj3x8tHTJ9Fbaf7p/7nx6YW IgiA== MIME-Version: 1.0 X-Received: by 10.194.104.164 with SMTP id gf4mr8906671wjb.102.1431012857505; Thu, 07 May 2015 08:34:17 -0700 (PDT) Sender: lukego@gmail.com Received: by 10.27.134.198 with HTTP; Thu, 7 May 2015 08:34:17 -0700 (PDT) In-Reply-To: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> Date: Thu, 7 May 2015 17:34:17 +0200 X-Google-Sender-Auth: 3_6YUS9sw2c-zjTKWLJl86Hi7t8 Message-ID: From: Luke Gorrie To: Avi Kivity 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 15:34:17 -0000 On 7 May 2015 at 16:02, Avi Kivity wrote: > 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. > That is also broadly why we don't currently use DPDK in Snabb Switch [1]. There is a bunch of functionality in DPDK that would be tempting for us to use and contribute back to: device drivers, SIMD routines, data structures, and so on. I think that we would do this if they were available piecemeal as stand-alone libi40e, libsimd, liblpn, etc. The whole DPDK platform/framework is too much for us to adopt though. Some aspects of it are in conflict with our goals and it is an all-or-nothing proposition. So for now we are staying self-sufficient even when it means writing our own ixgbe replacement, etc. Having said that we are able to share code that doesn't require linking into our address space e.g. vhost-user and potentially the bifurcated drivers in the future. That seems like a nice direction for things to be going in and a way to collaborate even without our directly linking with DPDK. [1] https://github.com/lukego/snabbswitch/blob/README/README.md