>
> 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....@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
