Re: [dpdk-dev] Question about link up/down events and transmit queues

[Matt Laswell <laswell@infiniteio.com>]

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


On Tue, Mar 10, 2015 at 10:47 AM, Matt Laswell <laswell@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@infiniteio.com
>