DPDK patches and discussions
 help / color / mirror / Atom feed
From: peng1x.zhang@intel.com
To: dev@dpdk.org
Cc: beilei.xing@intel.com, jingjing.wu@intel.com,
	Peng Zhang <peng1x.zhang@intel.com>
Subject: [PATCH 1/2] net/iavf: enable TSO offloading for tunnel cases
Date: Sat, 13 Aug 2022 00:52:22 +0800	[thread overview]
Message-ID: <20220812165223.470777-1-peng1x.zhang@intel.com> (raw)

From: Peng Zhang <peng1x.zhang@intel.com>

Hardware limits that max buffer size per Tx descriptor should be (16K-1)B.
So when TSO enabled under unencrypt scenario, the mbuf data size may exceed
the limit and cause malicious behavior to the NIC.

This patch supports Tx descriptors for this kind of large buffer.

Signed-off-by: Peng Zhang <peng1x.zhang@intel.com>
---
 drivers/net/iavf/iavf_rxtx.c | 66 ++++++++++++++++++++++++++++++++----
 1 file changed, 60 insertions(+), 6 deletions(-)

diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index dfd021889e..adec58e90a 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -2642,6 +2642,47 @@ iavf_ipsec_crypto_get_pkt_metadata(const struct iavf_tx_queue *txq,
 	return NULL;
 }
 
+/* HW requires that TX buffer size ranges from 1B up to (16K-1)B. */
+#define IAVF_MAX_DATA_PER_TXD \
+	(IAVF_TXD_QW1_TX_BUF_SZ_MASK >> IAVF_TXD_QW1_TX_BUF_SZ_SHIFT)
+
+static inline void
+iavf_fill_unencrypt_desc(volatile struct iavf_tx_desc *txd, struct rte_mbuf *m,
+			 volatile uint64_t desc_template, struct iavf_tx_entry *txe,
+			 volatile struct iavf_tx_desc *txr, struct iavf_tx_entry *txe_ring,
+			 int desc_idx_last)
+{
+		/* Setup TX Descriptor */
+		int desc_idx;
+		uint16_t slen = m->data_len;
+		uint64_t buf_dma_addr = rte_mbuf_data_iova(m);
+		struct iavf_tx_entry *txn = &txe_ring[txe->next_id];
+
+		while ((m->ol_flags & RTE_MBUF_F_TX_TCP_SEG) &&
+			unlikely(slen > IAVF_MAX_DATA_PER_TXD)) {
+			txd->buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
+
+			txd->cmd_type_offset_bsz =
+			rte_cpu_to_le_64(IAVF_TX_DESC_DTYPE_DATA |
+			(uint64_t)IAVF_MAX_DATA_PER_TXD <<
+			IAVF_TXD_DATA_QW1_TX_BUF_SZ_SHIFT) | desc_template;
+
+			buf_dma_addr += IAVF_MAX_DATA_PER_TXD;
+			slen -= IAVF_MAX_DATA_PER_TXD;
+
+			txe->last_id = desc_idx_last;
+			desc_idx = txe->next_id;
+			txe = txn;
+			txd = &txr[desc_idx];
+			txn = &txe_ring[txe->next_id];
+		}
+
+		txd->buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
+		txd->cmd_type_offset_bsz =
+			rte_cpu_to_le_64((uint64_t)slen << IAVF_TXD_DATA_QW1_TX_BUF_SZ_SHIFT) |
+				desc_template;
+}
+
 /* TX function */
 uint16_t
 iavf_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
@@ -2650,6 +2691,7 @@ iavf_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
 	volatile struct iavf_tx_desc *txr = txq->tx_ring;
 	struct iavf_tx_entry *txe_ring = txq->sw_ring;
 	struct iavf_tx_entry *txe, *txn;
+	volatile struct iavf_tx_desc *txd;
 	struct rte_mbuf *mb, *mb_seg;
 	uint16_t desc_idx, desc_idx_last;
 	uint16_t idx;
@@ -2781,6 +2823,7 @@ iavf_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
 			ddesc = (volatile struct iavf_tx_desc *)
 					&txr[desc_idx];
 
+			txd = &txr[desc_idx];
 			txn = &txe_ring[txe->next_id];
 			RTE_MBUF_PREFETCH_TO_FREE(txn->mbuf);
 
@@ -2788,10 +2831,16 @@ iavf_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
 				rte_pktmbuf_free_seg(txe->mbuf);
 
 			txe->mbuf = mb_seg;
-			iavf_fill_data_desc(ddesc, mb_seg,
-					ddesc_template, tlen, ipseclen);
 
-			IAVF_DUMP_TX_DESC(txq, ddesc, desc_idx);
+			if (nb_desc_ipsec) {
+				iavf_fill_data_desc(ddesc, mb_seg,
+					ddesc_template, tlen, ipseclen);
+				IAVF_DUMP_TX_DESC(txq, ddesc, desc_idx);
+			} else {
+				iavf_fill_unencrypt_desc(txd, mb_seg,
+					ddesc_template, txe, txr, txe_ring, desc_idx_last);
+				IAVF_DUMP_TX_DESC(txq, txd, desc_idx);
+			}
 
 			txe->last_id = desc_idx_last;
 			desc_idx = txe->next_id;
@@ -2816,10 +2865,15 @@ iavf_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
 			txq->nb_used = 0;
 		}
 
-		ddesc->cmd_type_offset_bsz |= rte_cpu_to_le_64(ddesc_cmd <<
+		if (nb_desc_ipsec) {
+			ddesc->cmd_type_offset_bsz |= rte_cpu_to_le_64(ddesc_cmd <<
 				IAVF_TXD_DATA_QW1_CMD_SHIFT);
-
-		IAVF_DUMP_TX_DESC(txq, ddesc, desc_idx - 1);
+			IAVF_DUMP_TX_DESC(txq, ddesc, desc_idx - 1);
+		} else {
+			txd->cmd_type_offset_bsz |= rte_cpu_to_le_64(ddesc_cmd <<
+				IAVF_TXD_DATA_QW1_CMD_SHIFT);
+			IAVF_DUMP_TX_DESC(txq, txd, desc_idx - 1);
+		}
 	}
 
 end_of_tx:
-- 
2.25.1


             reply	other threads:[~2022-08-12  9:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 16:52 peng1x.zhang [this message]
2022-08-12 16:52 ` [PATCH 2/2] net/iavf: support inner and outer checksum offload peng1x.zhang
2022-08-30  8:12   ` Yang, Qiming
2022-09-01  9:33   ` [PATCH v2] net/iavf: enable inner and outer Tx " Peng Zhang
2022-09-01 11:04     ` Zhang, Qi Z
2022-09-05  2:25     ` Yang, Qiming
2022-09-20  9:14     ` [PATCH v3] " Zhichao Zeng
2022-09-22  9:02       ` Xu, Ke1
2022-09-25  5:58         ` Zhang, Qi Z
2022-08-30  7:52 ` [PATCH 1/2] net/iavf: enable TSO offloading for tunnel cases Yang, Qiming
2022-09-26  5:17 ` [PATCH v2] net/iavf: fix TSO offload for tunnel case Zhichao Zeng
2022-09-26  9:48   ` Xu, Ke1
2022-09-27  2:33   ` Zhang, Qi Z
2022-09-27  9:56   ` [PATCH v3] " Zhichao Zeng
2022-09-29  5:27     ` [PATCH v4] " Zhichao Zeng
2022-09-30  3:46       ` Xu, Ke1
2022-09-30  9:05       ` Nicolau, Radu
2022-10-08  7:55         ` Zhang, Qi Z
2022-08-26 14:37 [PATCH 1/2] net/iavf: enable TSO offloading for tunnel cases Buckley, Daniel M
2022-08-30  2:22 Xu, Ke1

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=20220812165223.470777-1-peng1x.zhang@intel.com \
    --to=peng1x.zhang@intel.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=jingjing.wu@intel.com \
    /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).