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 7666CA0547 for ; Tue, 9 Feb 2021 11:36:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 70A07160712; Tue, 9 Feb 2021 11:36:45 +0100 (CET) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by mails.dpdk.org (Postfix) with ESMTP id 49E0816070A for ; Tue, 9 Feb 2021 11:36:44 +0100 (CET) Received: by mail-wr1-f53.google.com with SMTP id v15so20970293wrx.4 for ; Tue, 09 Feb 2021 02:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ayDHn6lM1LynguD7V5473DlijJTSuTL4He9w3LvNGEQ=; b=mwrujCpEmhMZSCJDcJNSgB9QSjemWQDamqy6LKnAvSSDN7NH7BCHWfEKd1diMlnnOs fUXIj0peyt/X+7+ylOYmNSfeoYby6401M0F2ZXpLgcjYcshaI9MxS7092eQl2Mf26ATU akWS04aycMTk4neXtneOLOISMkD2J7EIw/Y6UGSznMD+PvHC+WDkNQlCpSWRCVm7O3C+ AT1qlxk8gojegW6HpI9+SrIIW3ba9vQD5YJodrdBrSdF2Gx9HmqaTJqCw5mN3jvUFgRg JHdKIeBdREQmlZx3o+nBwYvw+g9o3JA45WIPqSDKV3+Mi0KM0kiPtLYcUE6jjrcOT1QZ dUbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ayDHn6lM1LynguD7V5473DlijJTSuTL4He9w3LvNGEQ=; b=FmaK4e9+BL9DZwl2+ODkolkYvn0phplvm3arabsVvyPPfNHWmgCF1p/2VCi0WdkrVC haZgUMFBChgaDKWMFrKtbSjRYTOtE2Mh8FXOkcfQrLS5o1pMVN+8BfsLom119o1ANvxH 8A1xXEmds2gv13Shz8r31BvaZ5D/iajZ5fWGBh+FhBaiSQ/Y2f1GWf+EZ/5jg5XWDkTA HG9UUOrQ1RjEygety84C8uf+4NsbH88UCmGuXAP1Gh/ml98ADJ51eeyx8F41u7mqsqrF NXxkZ3xTe1h2sdfWgEDuBQEpVbz5xescsFLoS+GGtHBvlmDJ2FPMOersKMCoN5tLCZRj Ir+w== X-Gm-Message-State: AOAM532igv1qh5mgiLWadbRdgMlSfsyUn4jc9l9P0+5qeVrgYgduFhxq 7FJaenOQF/BbdvTT0bRzi38hMCZX0RhNgw== X-Google-Smtp-Source: ABdhPJwtcuu/7JGN7NTbRH52DwzBYhOVp9nvDEEOxTMDdwRLgIzz6HbJqWMQhwBHTFjbZZ9Ai+5Lyw== X-Received: by 2002:adf:d852:: with SMTP id k18mr25115074wrl.262.1612867004100; Tue, 09 Feb 2021 02:36:44 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id o124sm4069987wmb.5.2021.02.09.02.36.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Feb 2021 02:36:43 -0800 (PST) From: luca.boccassi@gmail.com To: Ferruh Yigit Cc: Cian Ferriter , dpdk stable Date: Tue, 9 Feb 2021 10:35:22 +0000 Message-Id: <20210209103529.466775-24-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20210209103529.466775-1-luca.boccassi@gmail.com> References: <20210205111920.1272063-1-luca.boccassi@gmail.com> <20210209103529.466775-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'net/pcap: fix infinite Rx with large files' has been queued to stable release 20.11.1 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 Sender: "stable" Hi, FYI, your patch has been queued to stable release 20.11.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 02/11/21. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Queued patches are on a temporary branch at: https://github.com/bluca/dpdk-stable This queued commit can be viewed at: https://github.com/bluca/dpdk-stable/commit/396b447e24df0ea62a81f8251e3e1805a86a0e32 Thanks. Luca Boccassi --- >From 396b447e24df0ea62a81f8251e3e1805a86a0e32 Mon Sep 17 00:00:00 2001 From: Ferruh Yigit Date: Thu, 4 Feb 2021 16:51:03 +0000 Subject: [PATCH] net/pcap: fix infinite Rx with large files [ upstream commit f62490e64d60cb564240721d55f8b51d2bd719a9 ] Packet forwarding is not working when infinite Rx feature is used with large .pcap files that has high number of packets. The problem is number of allocated mbufs are less than the infinite Rx ring size, and all mbufs consumed to fill the ring, so there is no mbuf left for forwarding. Current logic can not detect that infinite Rx ring is not filled completely and no more mbufs left, and setup continues which leads silent fail on packet forwarding. There isn't much can be done when there is not enough mbuf for the given .pcap file, so additional checks added to detect the case and fail explicitly with an error log. Bugzilla ID: 595 Fixes: a3f5252e5cbd ("net/pcap: enable infinitely Rx a pcap file") Reported-by: Cian Ferriter Signed-off-by: Ferruh Yigit Acked-by: Cian Ferriter --- drivers/net/pcap/rte_eth_pcap.c | 40 ++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c index d44e1d39ae..40f4fa9021 100644 --- a/drivers/net/pcap/rte_eth_pcap.c +++ b/drivers/net/pcap/rte_eth_pcap.c @@ -735,6 +735,17 @@ eth_stats_reset(struct rte_eth_dev *dev) return 0; } +static inline void +infinite_rx_ring_free(struct rte_ring *pkts) +{ + struct rte_mbuf *bufs; + + while (!rte_ring_dequeue(pkts, (void **)&bufs)) + rte_pktmbuf_free(bufs); + + rte_ring_free(pkts); +} + static int eth_dev_close(struct rte_eth_dev *dev) { @@ -753,7 +764,6 @@ eth_dev_close(struct rte_eth_dev *dev) if (internals->infinite_rx) { for (i = 0; i < dev->data->nb_rx_queues; i++) { struct pcap_rx_queue *pcap_q = &internals->rx_queue[i]; - struct rte_mbuf *pcap_buf; /* * 'pcap_q->pkts' can be NULL if 'eth_dev_close()' @@ -762,11 +772,7 @@ eth_dev_close(struct rte_eth_dev *dev) if (pcap_q->pkts == NULL) continue; - while (!rte_ring_dequeue(pcap_q->pkts, - (void **)&pcap_buf)) - rte_pktmbuf_free(pcap_buf); - - rte_ring_free(pcap_q->pkts); + infinite_rx_ring_free(pcap_q->pkts); } } @@ -835,21 +841,25 @@ eth_rx_queue_setup(struct rte_eth_dev *dev, while (eth_pcap_rx(pcap_q, bufs, 1)) { /* Check for multiseg mbufs. */ if (bufs[0]->nb_segs != 1) { - rte_pktmbuf_free(*bufs); - - while (!rte_ring_dequeue(pcap_q->pkts, - (void **)bufs)) - rte_pktmbuf_free(*bufs); - - rte_ring_free(pcap_q->pkts); - PMD_LOG(ERR, "Multiseg mbufs are not supported in infinite_rx " - "mode."); + infinite_rx_ring_free(pcap_q->pkts); + PMD_LOG(ERR, + "Multiseg mbufs are not supported in infinite_rx mode."); return -EINVAL; } rte_ring_enqueue_bulk(pcap_q->pkts, (void * const *)bufs, 1, NULL); } + + if (rte_ring_count(pcap_q->pkts) < pcap_pkt_count) { + infinite_rx_ring_free(pcap_q->pkts); + PMD_LOG(ERR, + "Not enough mbufs to accommodate packets in pcap file. " + "At least %" PRIu64 " mbufs per queue is required.", + pcap_pkt_count); + return -EINVAL; + } + /* * Reset the stats for this queue since eth_pcap_rx calls above * didn't result in the application receiving packets. -- 2.29.2 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2021-02-09 10:34:58.891772691 +0000 +++ 0024-net-pcap-fix-infinite-Rx-with-large-files.patch 2021-02-09 10:34:57.926584313 +0000 @@ -1 +1 @@ -From f62490e64d60cb564240721d55f8b51d2bd719a9 Mon Sep 17 00:00:00 2001 +From 396b447e24df0ea62a81f8251e3e1805a86a0e32 Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit f62490e64d60cb564240721d55f8b51d2bd719a9 ] + @@ -23 +24,0 @@ -Cc: stable@dpdk.org @@ -33 +34 @@ -index c7751b7ba7..90f5d75ea8 100644 +index d44e1d39ae..40f4fa9021 100644