From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: George Yaneff <gesha2@abv.bg>, "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] DPDK Distributor app issues
Date: Mon, 10 Jun 2019 16:13:19 +0000 [thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA6758692D1@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <1567292027.2330305.1560177614329@nm22.abv.bg>
> -----Original Message-----
> From: users [mailto:users-bounces@dpdk.org] On Behalf Of George Yaneff
> Sent: Monday, June 10, 2019 3:40 PM
> To: users@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:
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
next prev parent reply other threads:[~2019-06-10 16:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-10 14:40 George Yaneff
2019-06-10 16:13 ` Van Haaren, Harry [this message]
2019-06-11 6:40 ` George Yaneff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E923DB57A917B54B9182A2E928D00FA6758692D1@IRSMSX102.ger.corp.intel.com \
--to=harry.van.haaren@intel.com \
--cc=gesha2@abv.bg \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).