From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ve0-x241.google.com (mail-ve0-x241.google.com [IPv6:2607:f8b0:400c:c01::241]) by dpdk.org (Postfix) with ESMTP id 63C749DE for ; Wed, 4 Dec 2013 10:23:59 +0100 (CET) Received: by mail-ve0-f193.google.com with SMTP id oy12so1901882veb.4 for ; Wed, 04 Dec 2013 01:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YJVMRkypy6U7sJbPcGhvjLs946pyYFs5WtpgTjvhnH4=; b=I98QNb3Y+IH/gwrwpK9zrHWyPfiGrxu7m/szmqtJc/CD+rSyN6cDXlZCgY6tRf1rH8 jq54KCKGcH2F8Xcp6UXanIrlCzN5y71nD5Qh7XEtobKDk6D3d8qmlgRxxOpTlM+tndB/ axNo1ob+KOeJqYR1gOk8mk+G91BOhUD0pBp6YwKy7bk9mRdgG3Yso1RONT6CqvgvAVST V0Y0LO+LM7OMEsW8jGEcZtC0DnmB+soc9QshgI4J0LXmKPUuQywlLJ7u7V0CTPckBpEA IDOiJPMU//DI+vbZsW5Q7sRg669gqdnpn4RoIHV/3FCLI6GtG6Bssi5OkEt4WdQx5ABR LMaA== MIME-Version: 1.0 X-Received: by 10.220.97.145 with SMTP id l17mr250398vcn.35.1386149101471; Wed, 04 Dec 2013 01:25:01 -0800 (PST) Received: by 10.59.5.67 with HTTP; Wed, 4 Dec 2013 01:25:01 -0800 (PST) In-Reply-To: <035f01cef0ca$a0d7a470$e286ed50$@com> References: <035f01cef0ca$a0d7a470$e286ed50$@com> Date: Wed, 4 Dec 2013 11:25:01 +0200 Message-ID: From: Jason Vassbender To: =?ISO-8859-1?Q?Fran=E7ois=2DFr=E9d=E9ric_Ozog?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Decoupling DPDK from EAL 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: Wed, 04 Dec 2013 09:23:59 -0000 Hey, I guess the main hurdle is that we already have our own multi-threaded architecture and ways to control thread startup/shutdown, priorities and affinities and they are all balanced very delicately (our application is latency sensitive, runs on rt_preempt, boots with isolcpus, etc). In addition, we are already using the command line to initialize some of our things, and part of the configuration for the application does not even come from the command line, but from eg. XML configuration file over the network. So ideally what I would have preferred is that EAL initialization could be done by other means (for example a simple initialization function with a dictionary as to be more flexible) and thread creation/shutdown could be left to the application if it so desires, provided it meets the execution conditions expected by DPDK. Essentially, at its current state, DPDK offers a complete solution to your problem including the entire surrounding framework. But for most big applications they already have their own frameworks in place and integrating DPDK becomes harder than it should be. So if DPDK were to be decoupled from EAL, made more modular, and some of the functions optionally left to applications to provide if they already have the facilities for them would make integration much easier and more flexible. -Jason On Wed, Dec 4, 2013 at 10:27 AM, Fran=E7ois-Fr=E9d=E9ric Ozog = wrote: > Hi, > > I just completed such a consulting mission for a customer. They were usin= g > libpcap as the network back end and the most challenging hurdle was to > transform a single threaded capture architecture to a multi-threaded one > with DPDK. The other key take away, is that DPDK capture helps to get onl= y > 20% of the 20 times performance boost I managed to achieve: most of the > latency is due to "application" and other internal communication mechanis= ms. > > So I agree that DPDK is not light, but I think most of the power of DPDK > comes from EAL thread management and "IPC"... > > Having said all that, I may have missed a critical point, so, what is the > specific major hurdle you see in the integration? > > Fran=E7ois-Fr=E9d=E9ric > > >> -----Message d'origine----- >> De : dev [mailto:dev-bounces@dpdk.org] De la part de Jason Vassbender >> Envoy=E9 : mardi 3 d=E9cembre 2013 22:51 >> =C0 : dev@dpdk.org >> Objet : [dpdk-dev] Decoupling DPDK from EAL >> >> Hello, >> >> I am trying to integrate DPDK into an existing application in order to >> improve packet processing latency, but it is proving rather difficult >> because of DPDK's dependency on EAL's thread management and bootstrap >> mechanism. Our application already has its own framework for managing >> threads and their affinities/priorities, IPC, timers and its own bootstr= ap >> mechanism (not necessarily via command line arguments), we wish to >> integrate DPDK as an alternative network back-end, but it wants to to ta= ke >> over our entire way of doing things. >> >> Are there any plans to decouple DPDK's core functionality away from EAL = so >> that it can be more easily integrated into existing applications? >> >> -Jason >