DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Bly, Mike" <mbly@ciena.com>, "'dev@dpdk.org'" <dev@dpdk.org>
Subject: Re: [dpdk-dev] x552 transmit issue and rte_ethtool -	rte_ethtool_get_regs()
Date: Tue, 23 Jul 2019 16:03:01 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772580168A5A018@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <MWHPR04MB05928BC9F7AD94448DDB9253CFC70@MWHPR04MB0592.namprd04.prod.outlook.com>




> 
> Hello,
> 
> We are chasing an interesting NIC transmit issue where after some period of time with normal operation the NIC enters a state where it
> refuses to transmit frames from our DPDK application via rte_eth_tx_burst(). All indications are the port is up and otherwise operational and
> is still receiving traffic. It simply refuses to transmit anymore.
> 
> Our application is running DPDK 17.05.1. In digging through the email archives, this appears to be related to the following posts, as we see
> the same nb_free = 0 and IXGBE_ADVTXD_STAT_DD not set problems they describe:
> http://mails.dpdk.org/archives/dev/2017-August/073240.html
> http://inbox.dpdk.org/dev/b704af91-dcc6-4481-a54c-3e174b744d17.h.liu@alibaba-inc.com/
> 
> Having not seen any resolution on the above DPDK posts and after a number of other investigative steps, we incorporated the rte_ethtool
> lib to provide the ability to dump the NIC register set via rte_ethtool_get_regs() in the hopes that perhaps there would be something there
> in a status register to point us in the right direction. The question now is what is the best way to check the register contents dumped to the
> binary output file this API creates, for the x552 NIC? Does anyone know if a decoder script exists?
> 
> Other ideas to pursue?

It is hard to tell without any other information, but sometimes that happens 
when user tries to TX malformed packet.
Might be worth to try using rte_eth_tx_prepare() inside your app.
It does some sanity checks to prevent such situations, especially when RTE_LIBRTE_ETHDEV_DEBUG is on.
Konstantin 





  reply	other threads:[~2019-07-23 16:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <MWHPR04MB059226F0055B856110C55933CFC80@MWHPR04MB0592.namprd04.prod.outlook.com>
2019-07-23 15:16 ` Bly, Mike
2019-07-23 16:03   ` Ananyev, Konstantin [this message]
2019-07-23 17:08     ` Bly, Mike
2019-07-23 23:09       ` Bly, Mike
2019-07-24  7:52         ` Ananyev, Konstantin
2019-07-25 16:28           ` Bly, Mike

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=2601191342CEEE43887BDE71AB9772580168A5A018@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=dev@dpdk.org \
    --cc=mbly@ciena.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).