From: Alex _ <asb.tyum@gmail.com>
To: users@dpdk.org
Subject: [dpdk-users] Output packets are lost and reordered when using rte_eth_tx_burst on i40e
Date: Tue, 15 Aug 2017 16:29:50 +0500 [thread overview]
Message-ID: <CAEAoBZ5qi4Mt5z_L5iaLnKyyfaq_FS3yNBOJycdZPn9ewJ-pbg@mail.gmail.com> (raw)
Hi.
Help me please understand the problem.
DPDK ver. 17.05
Scheme:
Generator -> port 0 -> port 1 -> host with tcpdump
How to reproduce:
1. I used l2fwd from examples, with the most significant change:
-#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
+#define BURST_TX_DRAIN_US 0xFFFFF /* Use big window in order to
rte_eth_tx_burst begins to work out */
2. Start the generator and observe in tcpdump how on the wire only a few
packets appear and they in different order.
15:53:25.133596 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 23495,
length 64
15:53:25.133597 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23496, length 64 <+++ lost (23499-23496) packets
15:53:26.181602 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23499, length 64 <--- burst send start
15:53:26.181605 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23500, length 64
15:53:26.181606 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23501, length 64
15:53:26.181607 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23502, length 64
15:53:26.181642 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 23498,
length 64
15:53:26.181649 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23503, length 64
15:53:26.181649 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 23499,
length 64 <--- burst end, tx only few packets
15:53:27.229651 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23504, length 64
15:53:27.229654 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23505, length 64
15:53:27.229654 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23506, length 64
15:53:27.229655 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23507, length 64
15:53:27.229699 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23508, length 64
15:53:27.229714 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 23504,
length 64
15:53:27.229720 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 23505,
length 64
15:53:28.277701 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23509, length 64
15:53:28.277704 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23510, length 64
15:53:28.277704 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23511, length 64
15:53:28.277744 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 23509,
length 64
15:53:28.277749 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23512, length 64
15:53:28.277750 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
23513, length 64
15:53:28.277750 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 23510,
length 64
3. DPDK said that all packets were transmitted
Port statistics ====================================
Statistics for port 0 ------------------------------
Packets sent: 0
Packets received: 11658796
Packets dropped: 0
Statistics for port 1 ------------------------------
Packets sent: 104
Packets received: 11831290
Packets dropped: 0
Aggregate statistics ===============================
Total packets sent: 104
Total packets received: 23490099
Total packets dropped: 0
====================================================
P.S
If I set BURST_TX_DRAIN_US to 100 (i.e. one packet must be send to wire per
rte_eth_tx_buffer call), all works fine:
16:14:30.896217 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29814, length 64
16:14:30.924453 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29814,
length 64
16:14:31.096663 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29815, length 64
16:14:31.124895 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29815,
length 64
16:14:31.297013 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29816, length 64
16:14:31.325258 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29816,
length 64
16:14:31.497364 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29817, length 64
16:14:31.526002 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29817,
length 64
16:14:31.698213 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29818, length 64
16:14:31.726446 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29818,
length 64
16:14:31.898655 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29819, length 64
16:14:31.926886 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29819,
length 64
16:14:32.098950 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29820, length 64
16:14:32.127887 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29820,
length 64
16:14:32.299597 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29821, length 64
16:14:32.328037 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29821,
length 64
16:14:32.500245 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29822, length 64
16:14:32.528686 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29822,
length 64
16:14:32.700796 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29823, length 64
16:14:32.729037 IP 8.8.8.8 > x.x.x.x: ICMP echo reply, id 46934, seq 29823,
length 64
16:14:32.901137 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 46934, seq
29824, length 64
No drops, no reordering.
reply other threads:[~2017-08-15 11:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CAEAoBZ5qi4Mt5z_L5iaLnKyyfaq_FS3yNBOJycdZPn9ewJ-pbg@mail.gmail.com \
--to=asb.tyum@gmail.com \
--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).