From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0A07CA0548 for ; Thu, 11 Nov 2021 10:40:59 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C8A0F40E03; Thu, 11 Nov 2021 10:40:58 +0100 (CET) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by mails.dpdk.org (Postfix) with ESMTP id 5079B40E03 for ; Thu, 11 Nov 2021 10:40:57 +0100 (CET) Received: by mail-wm1-f54.google.com with SMTP id b184-20020a1c1bc1000000b0033140bf8dd5so3945932wmb.5 for ; Thu, 11 Nov 2021 01:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id; bh=8SIWkmcVQHOAHIZo19sJdOhaFlXbDIYhxzVs/2M776k=; b=j/d0ZHPAGw9VimjJfk8QZgvDfR63hd8sLhiCGR4tM3451xz1OJ12XEqna3wickdvjy TrgBwTALcdmh98MLn0unlFf/3S63igz0uY/Vd62fb5OzyBPjywWzn7fJ7m5CCW2Br6U3 JO/0eTxzcnWYPMQHDGT0G42et4AUg7bguvhfk97PGHO0qz+mtcfOqSetWvZje3fNhOHq in/IgyxY5eee6n2FB9Yt6V5R2UhSDBF/AasBDeKu/9uZRFi78o6obckkU770Val4XTxb WhQW/VQBpiEvLkiEork7rRme91iV3vfEJnRHvg7hUIsr+tFl7fOzm6G6W7Fn3SwzF1Du GzIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=8SIWkmcVQHOAHIZo19sJdOhaFlXbDIYhxzVs/2M776k=; b=tzMukZ1oCcUOX1WUshQ9siMqdlzAzljvDqvDChCb+NrgmQuMMFhPDc98mHG/FSXtzv VdmSX20shRCCta6lUIArXBVHftnTcfo/3PTbJk8HjpaxcfB2tw7Hbm1+1WbaG/9GT4kp sk3SHQKhYLMTxLWy5BwzU62a3L4Sgz0qzTcliqdCVxhj7lbCXi8CWr88etc5ShFN/t1d cG4mRSTvyXGAeEwKKE86pNzCdaqJNWwHmQbEVUV4HGxmzLNUoNwm6U91Ed5eW04toG/5 tO3bzrzrn0jtVzd6baNj8wKQmZvoIPa1ghKGF0MwytawLZ6NxNCHAQnFsPiSvIQwKBlc WWkg== X-Gm-Message-State: AOAM530IRQem33hGJM2+lwceMqOnZCzvqAW2ZEdECLz2apMLwn9KZ3j5 AQowJf428HnBSalRDt9un/KGrCnJFEC3Cw== X-Google-Smtp-Source: ABdhPJzp8xW2vOTVZl1iLy/Wadtdpv5jfjSwOf59ErRbcDjauFQJ7RAfFRXoDiXrotTSVT9Y06AqlQ== X-Received: by 2002:a1c:7201:: with SMTP id n1mr24238003wmc.176.1636623656767; Thu, 11 Nov 2021 01:40:56 -0800 (PST) Received: from tucornea-dev-machine.localdomain ([193.226.172.42]) by smtp.gmail.com with ESMTPSA id t189sm2311900wma.8.2021.11.11.01.40.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Nov 2021 01:40:56 -0800 (PST) From: Tudor Cornea To: stable@dpdk.org Cc: xuemingl@nvidia.com, Tudor Cornea , Mihai Pogonaru Subject: [PATCH 20.11] net/af_packet: fix ignoring full ring on Tx Date: Thu, 11 Nov 2021 11:40:49 +0200 Message-Id: <1636623649-57152-1-git-send-email-tudor.cornea@gmail.com> X-Mailer: git-send-email 2.7.4 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org [ upstream commit f86d553cc180f9a65e115edb5641a49bbf2cf2f0 ] The poll call can return POLLERR which is ignored, or it can return POLLOUT, even if there are no free frames in the mmap-ed area. We can account for both of these cases by re-checking if the next frame is empty before writing into it. We have attempted to reproduce this issue with pktgen-dpdk, using the following configuration. pktgen -l 1-4 -n 4 --proc-type=primary --no-pci --no-telemetry \ --no-huge -m 512 \ --vdev=net_af_packet0,iface=eth1,blocksz=16384,framesz=8192, \ framecnt=2048,qpairs=1,qdisc_bypass=0 \ -- \ -P \ -T \ -m "3.0" \ -f themes/black-yellow.theme We configure a low tx rate (~ 335 packets / second) and a small packet size, of about 300 Bytes from the pktgen CLI. set 0 size 300 set 0 rate 0.008 set 0 burst 1 start 0 After bringing the interface down, and up again, we seem to arrive in a state in which the tx rate is inconsistent, and does not recover. ifconfig eth1 down; sleep 7; ifconfig eth1 up [1] http://code.dpdk.org/pktgen-dpdk/pktgen-20.11.2/source/INSTALL.md Fixes: 364e08f2bbc0 ("af_packet: add PMD for AF_PACKET-based virtual devices") Signed-off-by: Mihai Pogonaru Signed-off-by: Tudor Cornea Reviewed-by: Ferruh Yigit --- drivers/net/af_packet/rte_eth_af_packet.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c index 671ee87..f0945f2 100644 --- a/drivers/net/af_packet/rte_eth_af_packet.c +++ b/drivers/net/af_packet/rte_eth_af_packet.c @@ -212,8 +212,30 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) } /* point at the next incoming frame */ - if ((ppd->tp_status != TP_STATUS_AVAILABLE) && - (poll(&pfd, 1, -1) < 0)) + if (ppd->tp_status != TP_STATUS_AVAILABLE) { + if (poll(&pfd, 1, -1) < 0) + break; + + /* poll() can return POLLERR if the interface is down */ + if (pfd.revents & POLLERR) + break; + } + + /* + * poll() will almost always return POLLOUT, even if there + * are no extra buffers available + * + * This happens, because packet_poll() calls datagram_poll() + * which checks the space left in the socket buffer and, + * in the case of packet_mmap, the default socket buffer length + * doesn't match the requested size for the tx_ring. + * As such, there is almost always space left in socket buffer, + * which doesn't seem to be correlated to the requested size + * for the tx_ring in packet_mmap. + * + * This results in poll() returning POLLOUT. + */ + if (ppd->tp_status != TP_STATUS_AVAILABLE) break; /* copy the tx frame data */ -- 2.7.4