From: Rasesh Mody <rasesh.mody@cavium.com>
To: dev@dpdk.org
Cc: Harish Patil <harish.patil@cavium.com>,
ferruh.yigit@intel.com, Dept-EngDPDKDev@cavium.com,
stable@dpdk.org
Subject: [dpdk-stable] [PATCH 04/11] net/qede: fix tunnel header size in Tx BD configuration
Date: Sat, 27 Jan 2018 13:15:28 -0800 [thread overview]
Message-ID: <1517087735-16191-5-git-send-email-rasesh.mody@cavium.com> (raw)
In-Reply-To: <1517087735-16191-1-git-send-email-rasesh.mody@cavium.com>
From: Harish Patil <harish.patil@cavium.com>
- Fix incorrect header size. In the tunnel case, the outer L2/L3 lengths
should be included to calculate tunnel header_size.
- In TSO case, skip manipulating TX BD1 and TX BD2 data buffer fields
since those fields are already updated with header and payload lengths
respectively.
- Update TX BD debug data collection.
Fixes: 3d4bb4411683 ("net/qede: add fastpath support for VXLAN tunneling")
Cc: stable@dpdk.org
Signed-off-by: Harish Patil <harish.patil@cavium.com>
---
drivers/net/qede/qede_rxtx.c | 40 +++++++++++++++++++++++++---------------
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index 2af1bfc..df248cf 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -1588,7 +1588,8 @@ static inline uint32_t qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
/* Populate scatter gather buffer descriptor fields */
static inline uint16_t
qede_encode_sg_bd(struct qede_tx_queue *p_txq, struct rte_mbuf *m_seg,
- struct eth_tx_2nd_bd **bd2, struct eth_tx_3rd_bd **bd3)
+ struct eth_tx_2nd_bd **bd2, struct eth_tx_3rd_bd **bd3,
+ uint16_t start_seg)
{
struct qede_tx_queue *txq = p_txq;
struct eth_tx_bd *tx_bd = NULL;
@@ -1597,7 +1598,7 @@ static inline uint32_t qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
/* Check for scattered buffers */
while (m_seg) {
- if (nb_segs == 0) {
+ if (start_seg == 0) {
if (!*bd2) {
*bd2 = (struct eth_tx_2nd_bd *)
ecore_chain_produce(&txq->tx_pbl);
@@ -1607,7 +1608,7 @@ static inline uint32_t qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
mapping = rte_mbuf_data_iova(m_seg);
QEDE_BD_SET_ADDR_LEN(*bd2, mapping, m_seg->data_len);
PMD_TX_LOG(DEBUG, txq, "BD2 len %04x", m_seg->data_len);
- } else if (nb_segs == 1) {
+ } else if (start_seg == 1) {
if (!*bd3) {
*bd3 = (struct eth_tx_3rd_bd *)
ecore_chain_produce(&txq->tx_pbl);
@@ -1645,20 +1646,24 @@ static inline uint32_t qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
if (bd1)
PMD_TX_LOG(INFO, txq,
- "BD1: nbytes=%u nbds=%u bd_flags=%04x bf=%04x",
- rte_cpu_to_le_16(bd1->nbytes), bd1->data.nbds,
- bd1->data.bd_flags.bitfields,
- rte_cpu_to_le_16(bd1->data.bitfields));
+ "BD1: nbytes=0x%04x nbds=0x%04x bd_flags=0x%04x bf=0x%04x",
+ rte_cpu_to_le_16(bd1->nbytes), bd1->data.nbds,
+ bd1->data.bd_flags.bitfields,
+ rte_cpu_to_le_16(bd1->data.bitfields));
if (bd2)
PMD_TX_LOG(INFO, txq,
- "BD2: nbytes=%u bf=%04x\n",
- rte_cpu_to_le_16(bd2->nbytes), bd2->data.bitfields1);
+ "BD2: nbytes=0x%04x bf1=0x%04x bf2=0x%04x tunn_ip=0x%04x\n",
+ rte_cpu_to_le_16(bd2->nbytes), bd2->data.bitfields1,
+ bd2->data.bitfields2, bd2->data.tunn_ip_size);
if (bd3)
PMD_TX_LOG(INFO, txq,
- "BD3: nbytes=%u bf=%04x mss=%u\n",
- rte_cpu_to_le_16(bd3->nbytes),
- rte_cpu_to_le_16(bd3->data.bitfields),
- rte_cpu_to_le_16(bd3->data.lso_mss));
+ "BD3: nbytes=0x%04x bf=0x%04x MSS=0x%04x "
+ "tunn_l4_hdr_start_offset_w=0x%04x tunn_hdr_size=0x%04x\n",
+ rte_cpu_to_le_16(bd3->nbytes),
+ rte_cpu_to_le_16(bd3->data.bitfields),
+ rte_cpu_to_le_16(bd3->data.lso_mss),
+ bd3->data.tunn_l4_hdr_start_offset_w,
+ bd3->data.tunn_hdr_size_w);
rte_get_tx_ol_flag_list(tx_ol_flags, ol_buf, sizeof(ol_buf));
PMD_TX_LOG(INFO, txq, "TX offloads = %s\n", ol_buf);
@@ -1938,6 +1943,10 @@ static inline uint32_t qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
* and BD2 onwards for data.
*/
hdr_size = mbuf->l2_len + mbuf->l3_len + mbuf->l4_len;
+ if (tunn_flg)
+ hdr_size += mbuf->outer_l2_len +
+ mbuf->outer_l3_len;
+
bd1_bd_flags_bf |= 1 << ETH_TX_1ST_BD_FLAGS_LSO_SHIFT;
bd1_bd_flags_bf |=
1 << ETH_TX_1ST_BD_FLAGS_IP_CSUM_SHIFT;
@@ -2054,9 +2063,11 @@ static inline uint32_t qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
/* Handle fragmented MBUF */
m_seg = mbuf->next;
+
/* Encode scatter gather buffer descriptors if required */
- nb_frags = qede_encode_sg_bd(txq, m_seg, &bd2, &bd3);
+ nb_frags = qede_encode_sg_bd(txq, m_seg, &bd2, &bd3, nbds - 1);
bd1->data.nbds = nbds + nb_frags;
+
txq->nb_tx_avail -= bd1->data.nbds;
txq->sw_tx_prod++;
rte_prefetch0(txq->sw_tx_ring[TX_PROD(txq)].mbuf);
@@ -2064,7 +2075,6 @@ static inline uint32_t qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
rte_cpu_to_le_16(ecore_chain_get_prod_idx(&txq->tx_pbl));
#ifdef RTE_LIBRTE_QEDE_DEBUG_TX
print_tx_bd_info(txq, bd1, bd2, bd3, tx_ol_flags);
- PMD_TX_LOG(INFO, txq, "lso=%d tunn=%d", lso_flg, tunn_flg);
#endif
nb_pkt_sent++;
txq->xmit_pkts++;
--
1.7.10.3
next prev parent reply other threads:[~2018-01-27 21:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1517087735-16191-1-git-send-email-rasesh.mody@cavium.com>
2018-01-27 21:15 ` [dpdk-stable] [PATCH 01/11] net/qede/base: fix VF LRO tunnel params configuration Rasesh Mody
2018-01-27 21:15 ` [dpdk-stable] [PATCH 02/11] net/qede: initialize VF tunnel as enabled on start Rasesh Mody
2018-01-27 21:15 ` [dpdk-stable] [PATCH 03/11] net/qede: fix to check if tunnel L3 header is valid Rasesh Mody
2018-01-27 21:15 ` Rasesh Mody [this message]
2018-01-27 21:15 ` [dpdk-stable] [PATCH 06/11] net/qede: fix MTU set and max Rx pkt len usage Rasesh Mody
2018-01-27 21:15 ` [dpdk-stable] [PATCH 07/11] net/qede: fix clearing of queue stats Rasesh Mody
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=1517087735-16191-5-git-send-email-rasesh.mody@cavium.com \
--to=rasesh.mody@cavium.com \
--cc=Dept-EngDPDKDev@cavium.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=harish.patil@cavium.com \
--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).