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 at dpdk.org] De la part de Jason Vassbender > Envoy??: mardi 3 d?cembre 2013 22:51 > ??: dev at 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 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
