Re: Decoupling DPDK from EAL

["François-Frédéric Ozog" <ff-SpBG2i6TTxU@public.gmane.org>]

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"... 

Having said all that, I may have missed a critical point, so, what is the
specific major hurdle you see in the integration?

François-Frédéric


> -----Message d'origine-----
> De : dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] De la part de Jason Vassbender
> Envoyé : mardi 3 décembre 2013 22:51
> À : dev-VfR2kkLFssw@public.gmane.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 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.
> 
> 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