Re: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs()

["Bly, Mike" <mbly@ciena.com>]

Konstantin,

Thank you for the prompt reply on this posting. In looking at the single use-case in test-pmd's csumonly.c, it would seem prepare + retry_enabled may have some shortcomings as currently coded when nb_prep < nb_rx. Has anyone looked at this? I happened to notice this when looking for a reference for how it is expected to be used. It would seem nb_rx should be replaced with nb_prep in the retry code. I think the rest of the code should "just work" from there. Thoughts?

Regards,
Mike

-----Original Message-----
From: Ananyev, Konstantin <konstantin.ananyev@intel.com> 
Sent: Tuesday, July 23, 2019 9:03 AM
To: Bly, Mike <mbly@ciena.com>; 'dev@dpdk.org' <dev@dpdk.org>
Subject: [**EXTERNAL**] RE: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs()




> 
> 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@a
> libaba-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