> -----Original Message----- > From: users [mailto:[email protected]] On Behalf Of George Yaneff > Sent: Monday, June 10, 2019 3:40 PM > To: [email protected] > 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: http://git.dpdk.org/dpdk/tree/examples/distributor/main.c#n574 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
