From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 49BE45A38 for ; Fri, 8 May 2015 06:31:11 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 07 May 2015 21:31:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,388,1427785200"; d="scan'208";a="707095796" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga001.fm.intel.com with ESMTP; 07 May 2015 21:31:10 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 7 May 2015 21:31:09 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.26]) by fmsmsx115.amr.corp.intel.com ([169.254.4.128]) with mapi id 14.03.0224.002; Thu, 7 May 2015 21:31:09 -0700 From: "Wiles, Keith" To: Luke Gorrie , Avi Kivity Thread-Topic: [dpdk-dev] Beyond DPDK 2.0 Thread-Index: AdB4KSdm1ftzhuzCQX2G2XNq9ZOWFAE5VxLQAv6mNgAAAzXMgAAMdjEA Date: Fri, 8 May 2015 04:31:09 +0000 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.101.227] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E522A831043CE4F92564B6AE0D97074@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 08 May 2015 04:31:11 -0000 Hi Luke On 5/7/15, 8:34 AM, "Luke Gorrie" wrote: >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. Would the shared library support in DPDK be useful here? I know it still links in a dynamic way. I believe DPDK is much like your snabbswitch as it provides a basic system to run networking applications, in your case a vSwitch like design. The design has some parts that are standalone, but to be effective they require other parts of DPDK to work correctly. If you have some suggestion as to how DPDK could be split up and maintain its features and performance I would like to understand how. Regards, ++Keith > >[1] https://github.com/lukego/snabbswitch/blob/README/README.md