From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 54411A04F1; Fri, 13 Dec 2019 23:26:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2403C1BFC4; Fri, 13 Dec 2019 23:26:00 +0100 (CET) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by dpdk.org (Postfix) with ESMTP id 475F91BFC3 for ; Fri, 13 Dec 2019 23:25:59 +0100 (CET) Received: by mail-oi1-f169.google.com with SMTP id v140so2048183oie.0 for ; Fri, 13 Dec 2019 14:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinite-io.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=RrJxof21yuUgP6iWItOj/PEHuCiJ18vGhOr1EzKG75s=; b=B6Hbes4l7HcpiL2evIkUmc/o+qqyNpP4X+WvbzYIOmSWrEIwMRTGldF1QBHYpeujcC 1dWwUt/9/4v7f3YSz07DeuV8khQl2/ZrF8+SJhQ5TRmvb4Be7uv2D1uLCCsAiapnRKZR MuRULX4835iGPN0peVgkmQv22LW13CIdLO5LWRDsf+XUwqWrYjb7Zg/ZvzFyIZhoprjd 6mqyi63Do80mvxt1uo/9sA2/C2d3pBNXYeZCCeo1ULQJzrHggwpHA/SFcaOLep1Eq969 /U8vi/+x8ZfHAq4S0O8cSwlVyqc4LZtG/AUvZv55erk71s2TL8JO1E+ipOGcRE1CzXY6 bG5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=RrJxof21yuUgP6iWItOj/PEHuCiJ18vGhOr1EzKG75s=; b=W3cz4Y8Ji6tK57SBUlEdH6dhPGhViTBYdhDDYCukzWNXWTMeP2LaTHgIo1SNxbY1gY yg1HqtZIxGd9V/EIWUOCIgxREH1lzCryfJuUjzfMuhrVjqCcXvvyf5KVtGJsGx5OF6dT sWjSq8eNVjAGqWkF4mR2v+kO6nGaAI1s1LV4ZDgyJWBTMsYaLo5no9n1lD+DnC8IX5bF 9ia3gX12T1EMAQwc8wq9b8OnF57AwMDo6y4tlNAqTy1bBU5ZRMonzb/Nj7ljY0MipsSG 6Wrgxk0lyB49Q3CNPXq7N0ExHOuXjwgPd0MHKRmfO535aegKVkHITehZvWVgcDZIOBKn gtjg== X-Gm-Message-State: APjAAAV/qwIoC47ukxZZ+nroNztOHPofSStKVVU+X8w/85JUtIos3o66 QPwU+8V9RApTeccFxJi+QGpNsifhkRxDIw== X-Google-Smtp-Source: APXvYqzj1nZYuhUj+ILO/Pr0d0y8f8X2Li7C+zNkbXtFk1EQ73wfgu/0RjiA//fIvNfW93r+8WQX/g== X-Received: by 2002:aca:728c:: with SMTP id p134mr8363818oic.176.1576275958065; Fri, 13 Dec 2019 14:25:58 -0800 (PST) Received: from [10.3.1.54] (INFINITE-IO.bear2.Houston1.Level3.net. [4.14.61.118]) by smtp.gmail.com with ESMTPSA id 11sm3912663otz.3.2019.12.13.14.25.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2019 14:25:57 -0800 (PST) From: Dave Burton Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 13 Dec 2019 16:25:56 -0600 To: dev@dpdk.org X-Mailer: Apple Mail (2.3445.104.11) Subject: [dpdk-dev] 82599 TX flush on carrier loss X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 =3D 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=E2=80=99ve tried using rte_eth_dev_tx_queue_stop and = rte_eth_dev_tx_queue_start, but this makes no difference. I can get = these =E2=80=9Cflushed" 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? =E2=80=94 Dave=