[dpdk-users] DPDK Distributor app issues

Van Haaren, Harry harry.van.haaren at intel.com
Mon Jun 10 18:13:19 CEST 2019

> -----Original Message-----
> From: users [mailto:users-bounces at dpdk.org] On Behalf Of George Yaneff
> Sent: Monday, June 10, 2019 3:40 PM
> To: users at dpdk.org
> Subject: [dpdk-users] DPDK Distributor app issues
> I'm playing with the distributor example application from dpdk 19.05.0

Ah cool - Not sure what your goal is, but if you're looking for the
more future-proof load-balancing / distribution APIs in DPDK the I
recommend to look at the Eventdev library, as this has been added to
DPDK for more "pipelined" applications and load-balancing within those
pipeline stages.

If you know your use case matches distributor library, and are aware of
the existence of Eventdev libs, please ignore the above :)

> I
> have three machines connected sequentially with an UTP Ethernet cable. The
>   middle is Ubuntu 18.04.2 LTS with a eigth core Intel I7 processor and 24
> GB ram.  The eth device used is Intel I350 with four ports.
>   The strange behavior I'm observing is when I ping the second node from the
> first node (traffic passing through the distributor)  there are always one
> or two packets lost.
>   When I use
> l2fwd or
> basicfwd applications there is no packet loss.  Anyone knows if this is
> normal or if it is not - what I'm doing wrong?

This seems strange - although I'm not very familiar with Distributor sample app.

Perhaps add some statistics counters around the "rte_pktmbuf_free()" calls in
the sample app, to identify if the sample-app is dropping packets in SW, or if
the root cause is really platform configuration?

>   Another thing I noticed is that the ping replies come to the first node
> with around one second of delay. (1024ms on most packets)  Again there is no
> latency with the basicfwd (packets arriving in 0.101 ms there).  Is there
> any way to minimize this delay in distributor application also?

The sample application adds artificial "work" per packet to simulate a real
world distributing workload:

Per packet, 100 cycles of work is performed, so eg:
(burst-size # of packets * 100 cycles) @ CPU freq + RX, TX and Distributor
work will be the total delay along the wire.

>   George

Hope that helps, -Harry

More information about the users mailing list