Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?= <bjorn.topel@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net 2/2] i40e, xsk: clear the status bits for the next_to_use descriptor
Date: Fri, 11 Dec 2020 15:57:12 +0100	[thread overview]
Message-ID: <20201211145712.72957-3-bjorn.topel@gmail.com> (raw)
In-Reply-To: <20201211145712.72957-1-bjorn.topel@gmail.com>

From: Bj?rn T?pel <bjorn.topel@intel.com>

On the Rx side, the next_to_use index points to the next item in the
HW ring to be refilled/allocated, and next_to_clean points to the next
item to potentially be processed.

When the HW Rx ring is fully refilled, i.e. no packets has been
processed, the next_to_use will be next_to_clean - 1. When the ring is
fully processed next_to_clean will be equal to next_to_use. The latter
case is where a bug is triggered.

If the next_to_use bits are not cleared, and the "fully processed"
state is entered, a stale descriptor can be processed.

The skb-path correctly clear the status bit for the next_to_use
descriptor, but the AF_XDP zero-copy path did not do that.

This change adds the status bits clearing of the next_to_use
descriptor.

Fixes: 3b4f0b66c2b3 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL")
Signed-off-by: Bj?rn T?pel <bjorn.topel@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_xsk.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index 567fd67e900e..e402c62eb313 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -219,8 +219,11 @@ bool i40e_alloc_rx_buffers_zc(struct i40e_ring *rx_ring, u16 count)
 	} while (count);
 
 no_buffers:
-	if (rx_ring->next_to_use != ntu)
+	if (rx_ring->next_to_use != ntu) {
+		/* clear the status bits for the next_to_use descriptor */
+		rx_desc->wb.qword1.status_error_len = 0;
 		i40e_release_rx_desc(rx_ring, ntu);
+	}
 
 	return ok;
 }
-- 
2.27.0


  parent reply	other threads:[~2020-12-11 14:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-11 14:57 [Intel-wired-lan] [PATCH net 0/2] i40e/ice AF_XDP ZC fixes =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-12-11 14:57 ` [Intel-wired-lan] [PATCH net 1/2] ice, xsk: clear the status bits for the next_to_use descriptor =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-12-11 14:57 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?= [this message]
2020-12-16 18:55 ` [Intel-wired-lan] [PATCH net 0/2] i40e/ice AF_XDP ZC fixes Jakub Kicinski

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=20201211145712.72957-3-bjorn.topel@gmail.com \
    --to=bjorn.topel@gmail.com \
    --cc=intel-wired-lan@osuosl.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