From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luke Gorrie Subject: Re: Beyond DPDK 2.0 Date: Thu, 7 May 2015 17:34:17 +0200 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Avi Kivity 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 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