Just a bit more on this. We've found that when a link goes down, the TX descriptor ring appears to fill up with packets fairly quickly, and then calls to rte_eth_tx_burst() start returning zero. Our application handles this case, and frees the mbufs that could not be sent.
However, when link is reestablished, the TX descriptor ring appears to stay full. Hence, subsequent calls to rte_eth_tx_burst() continue to return zero, and we continue to free the mbufs without sending them. Frankly, this was surprising, as we I have assumed that the TX descriptor ring would be emptied when the link came back up, either by sending the enqueued packets, or by reinitializing. I've tried calling rte_eth_dev_start() and rte_eth_promiscuous_enable() in order to restart everything. That appears to work, at least on the combination of drivers that I tested with. Can somebody please tell me whether this is the preferred way to recover from link down? Thanks, -- Matt Laswell *infinite io, inc.* laswell at infiniteio.com On Tue, Mar 10, 2015 at 10:47 AM, Matt Laswell <laswell at infiniteio.com> wrote: > Hey Folks, > > I'm running into an issue that I hope is obvious and simple. We're > running DPDK 1.6.2 with an 82599 NIC. We find that if, while running > traffic, we disconnect a port and then later reconnect it, we never regain > the ability to transmit packets out of that port after it comes back up. > Specifically, our calls to rte_eth_tx_burst() get return values that > indicate that no packets could be sent. > > Is there an additional step that we have to do on link down/up operations, > perhaps to tell the NIC to flush its descriptor ring? > > Thanks in advance for your help. > > -- > Matt Laswell > *infinite io, inc.* > laswell at infiniteio.com >
