From: Martin Weiser <martin.weiser@allegro-packets.com>
To: helin.zhang@intel.com
Cc: dev@dpdk.org
Subject: [dpdk-dev] i40e: problem with rx packet drops not accounted in statistics
Date: Wed, 9 Sep 2015 13:57:59 +0200 [thread overview]
Message-ID: <55F01EC7.1070909@allegro-packets.com> (raw)
Hi Helin,
in one of our test setups involving i40e adapters we are experiencing
packet drops which are not reflected in the interfaces statistics.
The call to rte_eth_stats_get suggests that all packets were properly
received but the total number of packets received through
rte_eth_rx_burst is less than the ipackets counter.
When for example running the l2fwd application (l2fwd -c 0xfe -n 4 -- -p
0x3) and having driver debug messages enabled the following output is
generated for the interface in question:
...
PMD: i40e_update_vsi_stats(): ***************** VSI[6] stats start
*******************
PMD: i40e_update_vsi_stats(): rx_bytes: 242624340000
PMD: i40e_update_vsi_stats(): rx_unicast: 167790000
PMD: i40e_update_vsi_stats(): rx_multicast: 0
PMD: i40e_update_vsi_stats(): rx_broadcast: 0
PMD: i40e_update_vsi_stats(): rx_discards: 1192557
PMD: i40e_update_vsi_stats(): rx_unknown_protocol: 0
PMD: i40e_update_vsi_stats(): tx_bytes: 0
PMD: i40e_update_vsi_stats(): tx_unicast: 0
PMD: i40e_update_vsi_stats(): tx_multicast: 0
PMD: i40e_update_vsi_stats(): tx_broadcast: 0
PMD: i40e_update_vsi_stats(): tx_discards: 0
PMD: i40e_update_vsi_stats(): tx_errors: 0
PMD: i40e_update_vsi_stats(): ***************** VSI[6] stats end
*******************
PMD: i40e_dev_stats_get(): ***************** PF stats start
*******************
PMD: i40e_dev_stats_get(): rx_bytes: 242624340000
PMD: i40e_dev_stats_get(): rx_unicast: 167790000
PMD: i40e_dev_stats_get(): rx_multicast: 0
PMD: i40e_dev_stats_get(): rx_broadcast: 0
PMD: i40e_dev_stats_get(): rx_discards: 0
PMD: i40e_dev_stats_get(): rx_unknown_protocol: 167790000
PMD: i40e_dev_stats_get(): tx_bytes: 0
PMD: i40e_dev_stats_get(): tx_unicast: 0
PMD: i40e_dev_stats_get(): tx_multicast: 0
PMD: i40e_dev_stats_get(): tx_broadcast: 0
PMD: i40e_dev_stats_get(): tx_discards: 0
PMD: i40e_dev_stats_get(): tx_errors: 0
PMD: i40e_dev_stats_get(): tx_dropped_link_down: 0
PMD: i40e_dev_stats_get(): crc_errors: 0
PMD: i40e_dev_stats_get(): illegal_bytes: 0
PMD: i40e_dev_stats_get(): error_bytes: 0
PMD: i40e_dev_stats_get(): mac_local_faults: 1
PMD: i40e_dev_stats_get(): mac_remote_faults: 1
PMD: i40e_dev_stats_get(): rx_length_errors: 0
PMD: i40e_dev_stats_get(): link_xon_rx: 0
PMD: i40e_dev_stats_get(): link_xoff_rx: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[0]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[0]: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[1]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[1]: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[2]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[2]: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[3]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[3]: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[4]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[4]: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[5]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[5]: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[6]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[6]: 0
PMD: i40e_dev_stats_get(): priority_xon_rx[7]: 0
PMD: i40e_dev_stats_get(): priority_xoff_rx[7]: 0
PMD: i40e_dev_stats_get(): link_xon_tx: 0
PMD: i40e_dev_stats_get(): link_xoff_tx: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[0]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[0]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[0]: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[1]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[1]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[1]: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[2]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[2]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[2]: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[3]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[3]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[3]: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[4]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[4]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[4]: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[5]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[5]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[5]: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[6]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[6]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[6]: 0
PMD: i40e_dev_stats_get(): priority_xon_tx[7]: 0
PMD: i40e_dev_stats_get(): priority_xoff_tx[7]: 0
PMD: i40e_dev_stats_get(): priority_xon_2_xoff[7]: 0
PMD: i40e_dev_stats_get(): rx_size_64: 0
PMD: i40e_dev_stats_get(): rx_size_127: 0
PMD: i40e_dev_stats_get(): rx_size_255: 0
PMD: i40e_dev_stats_get(): rx_size_511: 0
PMD: i40e_dev_stats_get(): rx_size_1023: 0
PMD: i40e_dev_stats_get(): rx_size_1522: 167790000
PMD: i40e_dev_stats_get(): rx_size_big: 0
PMD: i40e_dev_stats_get(): rx_undersize: 0
PMD: i40e_dev_stats_get(): rx_fragments: 0
PMD: i40e_dev_stats_get(): rx_oversize: 0
PMD: i40e_dev_stats_get(): rx_jabber: 0
PMD: i40e_dev_stats_get(): tx_size_64: 0
PMD: i40e_dev_stats_get(): tx_size_127: 0
PMD: i40e_dev_stats_get(): tx_size_255: 0
PMD: i40e_dev_stats_get(): tx_size_511: 0
PMD: i40e_dev_stats_get(): tx_size_1023: 0
PMD: i40e_dev_stats_get(): tx_size_1522: 0
PMD: i40e_dev_stats_get(): tx_size_big: 0
PMD: i40e_dev_stats_get(): mac_short_packet_dropped: 0
PMD: i40e_dev_stats_get(): checksum_error: 0
PMD: i40e_dev_stats_get(): fdir_match: 0
PMD: i40e_dev_stats_get(): ***************** PF stats end
********************
...
The count for rx_unicast is exactly the number of packets we would have
expected and the count for rx_discards in the VSI stats is exactly the
number of packets we are missing.
The question is why this number shows up only in the VSI stats and not
in the PF stats and of course why the packets which were obviously
discarded are still counted in the rx_unicast stats.
This test was performed using DPDK 2.1 and the firmware of the XL710 is
the latest one (FW 4.40 API 1.4 NVM 04.05.03).
Do you have an idea what might be going on?
Best regards,
Martin
next reply other threads:[~2015-09-09 11:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 11:57 Martin Weiser [this message]
2015-09-10 1:09 ` Zhang, Helin
2015-10-21 8:44 ` Martin Weiser
2015-10-22 0:16 ` Zhang, Helin
2015-10-22 7:59 ` Martin Weiser
2015-10-23 0:42 ` Zhang, Helin
2015-10-25 18:51 ` Arnon Warshavsky
2015-10-26 1:57 ` Zhang, Helin
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=55F01EC7.1070909@allegro-packets.com \
--to=martin.weiser@allegro-packets.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
/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).