From: Andrey Korolyov <andrey@xdel.ru>
To: dev@dpdk.org
Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>
Subject: [dpdk-dev] Packet drops during non-exhaustive flood with OVS and 1.8.0
Date: Wed, 21 Jan 2015 21:02:11 +0400 [thread overview]
Message-ID: <CABYiri-qn_HGYeRSxH+z0+LGi0se9NEOk0q9hzFg4R+wg05ABw@mail.gmail.com> (raw)
Hello,
I observed that the latest OVS with dpdk-1.8.0 and igb_uio starts to
drop packets earlier than a regular Linux ixgbe 10G interface, setup
follows:
receiver/forwarder:
- 8 core/2 head system with E5-2603v2, cores 1-3 are given to OVS exclusively
- n-dpdk-rxqs=6, rx scattering is not enabled
- x520 da
- 3.10/3.18 host kernel
- during 'legacy mode' testing, queue interrupts are scattered through all cores
sender:
- 16-core E52630, netmap framework for packet generation
- pkt-gen -f tx -i eth2 -s 10.6.9.0-10.6.9.255 -d
10.6.10.0-10.6.10.255 -S 90:e2:ba:84:19:a0 -D 90:e2:ba:85:06:07 -R
11000000, results in 11Mpps 60-byte packet flood, there are constant
values during test.
OVS contains only single drop rule at the moment:
ovs-ofctl add-flow br0 in_port=1,actions=DROP
Packet generator was launched for tens of seconds for both Linux stack
and OVS+DPDK cases, resulting in zero drop/error count on the
interface in first, along with same counter values on pktgen and host
interface stat (means that the none of generated packets are
unaccounted).
I selected rate for about 11M because OVS starts to do packet drop
around this value, after same short test interface stat shows
following:
statistics : {collisions=0, rx_bytes=22003928768,
rx_crc_err=0, rx_dropped=0, rx_errors=10694693, rx_frame_err=0,
rx_over_err=0, rx_packets=343811387, tx_bytes=0, tx_dropped=0,
tx_errors=0, tx_packets=0}
pktgen side:
Sent 354506080 packets, 60 bytes each, in 32.23 seconds.
Speed: 11.00 Mpps Bandwidth: 5.28 Gbps (raw 7.39 Gbps)
If rate will be increased up to 13-14Mpps, the relative error/overall
ratio will rise up to a one third. So far OVS on dpdk shows perfect
results and I do not want to reject this solution due to exhaustive
behavior like described one, so I`m open for any suggestions to
improve the situation (except using 1.7 branch :) ).
next reply other threads:[~2015-01-21 17:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 17:02 Andrey Korolyov [this message]
2015-01-22 17:11 ` Andrey Korolyov
[not found] ` <CABYiri_q4QqWrhTQL-UZ1wf3FLz-wj9SbtBJrDntz2Bw4cEPoQ@mail.gmail.com>
2015-02-03 17:02 ` Traynor, Kevin
2015-02-03 17:21 ` Andrey Korolyov
2015-02-06 14:43 ` Andrey Korolyov
2015-02-12 15:05 ` Traynor, Kevin
2015-02-12 15:15 ` Andrey Korolyov
2015-02-13 10:58 ` Traynor, Kevin
2015-02-16 22:37 ` Andrey Korolyov
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=CABYiri-qn_HGYeRSxH+z0+LGi0se9NEOk0q9hzFg4R+wg05ABw@mail.gmail.com \
--to=andrey@xdel.ru \
--cc=dev@dpdk.org \
--cc=discuss@openvswitch.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).