From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Fran=E7ois-Fr=E9d=E9ric_Ozog?= Subject: Re: Decoupling DPDK from EAL Date: Wed, 4 Dec 2013 09:27:10 +0100 Message-ID: <035f01cef0ca$a0d7a470$e286ed50$@com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: "'Jason Vassbender'" , Return-path: In-Reply-To: Content-Language: fr 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" Hi, I just completed such a consulting mission for a customer. They were = using 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 = only 20% of the 20 times performance boost I managed to achieve: most of the latency is due to "application" and other internal communication = mechanisms. So I agree that DPDK is not light, but I think most of the power of DPDK comes from EAL thread management and "IPC"...=20 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=A0: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] De la part de Jason = Vassbender > Envoy=E9=A0: mardi 3 d=E9cembre 2013 22:51 > =C0=A0: dev-VfR2kkLFssw@public.gmane.org > Objet=A0: [dpdk-dev] Decoupling DPDK from EAL >=20 > Hello, >=20 > 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 = bootstrap > mechanism (not necessarily via command line arguments), we wish to > integrate DPDK as an alternative network back-end, but it wants to to = take > over our entire way of doing things. >=20 > Are there any plans to decouple DPDK's core functionality away from = EAL so > that it can be more easily integrated into existing applications? >=20 > -Jason