From: Dave Burton <daveb@infinite.io>
To: dev@dpdk.org
Subject: [dpdk-dev] 82599 TX flush on carrier loss
Date: Fri, 13 Dec 2019 16:25:56 -0600 [thread overview]
Message-ID: <A78A2461-2E5E-4C8B-B462-68FFB77B596F@infinite.io> (raw)
Howdy!
I would like to know how to get the TX queue drained when the link is down (rte_eth_link_get_nowait return rte_eth_link.link_status = 0).
Background: our appliance has multi-port 82599 multimode-fiber NICs, and acts as a bump-on-a-wire, taking packets off port N, perhaps processing them, and passing them to port N+1. In this particular case, we are a simple packet forwarder. For the test, with a client connected to port N, and the server connected to port N+1:
client: ping -i0.2 -f $server_ip
server: tcpdump -i $iface
Allow the ping flood to run for a while, then pull the cable from port N+1 (link goes down), and the client ping starts printing dots, and the tcpdump on the server stops seeing ICMP-echos from the client. After a few tens of seconds, kill the client ping. After another few tens of seconds, reconnect the cable.
Immediately upon link-up, we are seeing ~31 ICMP-echo packets sequentially from the last packet before the cable was pulled.
The desire here is all these packets are discarded, or we can flush them somehow. I’ve tried using rte_eth_dev_tx_queue_stop and rte_eth_dev_tx_queue_start, but this makes no difference. I can get these “flushed" by stopping the device: rte_eth_dev_stop and rte_eth_dev_start, but this is undesirable for other reasons.
Is there a way to configure an 82599 fiber to discard packets if the device cannot TX them? If not, is there a way to flush all the TX queues so they will not be delivered once the link is restored?
— Dave
reply other threads:[~2019-12-13 22:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=A78A2461-2E5E-4C8B-B462-68FFB77B596F@infinite.io \
--to=daveb@infinite.io \
--cc=dev@dpdk.org \
/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).