DPDK patches and discussions
 help / color / mirror / Atom feed
From: Alejandro Lucero <alejandro.lucero@netronome.com>
To: dev@dpdk.org
Cc: stable@dpdk.org
Subject: [dpdk-dev] [PATCH] nfp: handle packets with length 0 as usual ones
Date: Fri, 11 Aug 2017 11:05:50 +0100	[thread overview]
Message-ID: <1502445950-44582-1-git-send-email-alejandro.lucero@netronome.com> (raw)

A DPDK app could, whatever the reason, send packets with size 0.
The PMD is not sending those packets, which does make sense,
but the problem is the mbuf is not released either. That leads
to mbufs not being available, because the app trusts the
PMD will do it.

Although this is a problem related to app wrong behaviour, we
should harden the PMD in this regard. Not sending a packet with
size 0 could be problematic, needing special handling inside the
PMD xmit function. It could be a burst of those packets, which can
be easily handled, but it could also be a single packet in a burst,
what is harder to handle.

It would be simpler to just send that kind of packets, which will
likely be dropped by the hw at some point. The main problem is how
the fw/hw handles the DMA, because a dma read to a hypothetical 0x0
address could trigger an IOMMU error. It turns out, it is safe to
send a descriptor with packet size 0 to the hardware: the DMA never
happens, from the PCIe point of view.

Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
---
 drivers/net/nfp/nfp_net.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 92b03c4..679a91b 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2094,7 +2094,7 @@ uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
 		 */
 		pkt_size = pkt->pkt_len;
 
-		while (pkt_size) {
+		while (pkt) {
 			/* Copying TSO, VLAN and cksum info */
 			*txds = txd;
 
@@ -2126,17 +2126,24 @@ uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
 				txq->wr_p = 0;
 
 			pkt_size -= dma_size;
-			if (!pkt_size) {
+			if (!pkt_size)
 				/* End of packet */
 				txds->offset_eop |= PCIE_DESC_TX_EOP;
-			} else {
+			else
 				txds->offset_eop &= PCIE_DESC_TX_OFFSET_MASK;
-				pkt = pkt->next;
-			}
+
+			pkt = pkt->next;
 			/* Referencing next free TX descriptor */
 			txds = &txq->txds[txq->wr_p];
 			lmbuf = &txq->txbufs[txq->wr_p].mbuf;
 			issued_descs++;
+
+			/* Double-checking if we have to use chained mbuf.
+			 * It seems there are some apps which could wrongly
+			 * have zeroed mbufs chained leading to send null
+			 * descriptors to the hw. */
+			if (!pkt_size)
+				break;
 		}
 		i++;
 	}
-- 
1.9.1

             reply	other threads:[~2017-08-11 10:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 10:05 Alejandro Lucero [this message]
2017-08-18 15:10 ` Ferruh Yigit
2017-08-18 16:23   ` Alejandro Lucero
2017-08-21 10:34     ` Ferruh Yigit
2017-08-21 13:08       ` Alejandro Lucero
2017-08-21 13:25         ` Ferruh Yigit

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=1502445950-44582-1-git-send-email-alejandro.lucero@netronome.com \
    --to=alejandro.lucero@netronome.com \
    --cc=dev@dpdk.org \
    --cc=stable@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).