From: Joshua Washington <joshwash@google.com>
To: netdev@vger.kernel.org
Cc: Joshua Washington <joshwash@google.com>,
Harshitha Ramamurthy <hramamurthy@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jordan Rhee <jordanrhee@google.com>,
Willem de Bruijn <willemb@google.com>,
Ankit Garg <nktgrg@google.com>,
Tim Hostetler <thostet@google.com>,
Praveen Kaligineedi <pkaligineedi@google.com>,
Jeroen de Borst <jeroendb@google.com>,
Stanislav Fomichev <sdf@fomichev.me>,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH net 1/6] gve: increment work_done for XDP and error packets
Date: Fri, 14 Aug 2026 16:48:40 -0700 [thread overview]
Message-ID: <20260814234845.773189-2-joshwash@google.com> (raw)
In-Reply-To: <20260814234845.773189-1-joshwash@google.com>
The GVE RX NAPI will continue polling as long as
1) there are packets to be processed, and
2) less than NAPI budget SKBs (denoted in GVE by work_done) have been
passed up to the kernel.
However, GVE does not account for all of the packets that don't create
SKBs, namely error packets and XDP packets.
This can result in XDP programs that scarcely return XDP_PASS failing to
exit the NAPI poll as long as the NIC is DMA'ing packets, possibly
processing the entire RX ring before returning from the NAPI.
This has 3 negative implications:
1) XDP RX path can run much longer than is desirable, hogging CPU
resources.
2) If XDP_PASS is never returned, the work_done never increases beyond
0, which can lead to scheduling delays due to missed chances to
reschedule the NAPI.
3) In AF_XDP zero-copy, XSK_TX occurs after the RX poll. If the RX poll
takes a long time, it will delay TX, leading to degraded performance.
Ensure every packet is accounted for in work_done by incrementing
work_done before checking for the existence of a SKB.
Fixes: 293b49361f91 ("gve: add XDP DROP and PASS support for DQ")
Cc: stable@vger.kernel.org
Reviewed-by: Tim Hostetler <thostet@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
drivers/net/ethernet/google/gve/gve_rx_dqo.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 0ece2f6fdffb..db38bc645296 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -1145,13 +1145,14 @@ int gve_rx_poll_dqo(struct gve_notify_block *block, int budget)
/* Free running counter of completed descriptors */
rx->cnt++;
- if (!rx->ctx.skb_head)
- continue;
-
if (!compl_desc->end_of_packet)
continue;
work_done++;
+
+ if (!rx->ctx.skb_head)
+ continue;
+
pkt_bytes = rx->ctx.skb_head->len;
/* The ethernet header (first ETH_HLEN bytes) is snipped off
* by eth_type_trans.
--
2.55.0.691.gc56d675ccc-goog
next prev parent reply other threads:[~2026-08-14 23:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 23:48 [PATCH net 0/6] gve: various XDP fixes Joshua Washington
2026-08-14 23:48 ` Joshua Washington [this message]
2026-08-15 23:49 ` [PATCH net 1/6] gve: increment work_done for XDP and error packets sashiko-bot
2026-08-14 23:48 ` [PATCH net 2/6] gve: fix XSK buffer leak when rings are stopped Joshua Washington
2026-08-15 23:49 ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 3/6] gve: fix XSK buffer leak on error descriptor Joshua Washington
2026-08-15 23:49 ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 4/6] gve: don't register xsk pool on pre-existing queues in RDA mode Joshua Washington
2026-08-15 23:49 ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 5/6] gve: fix napi_disable deadlock when attempting to disable XSK pools Joshua Washington
2026-08-15 23:49 ` sashiko-bot
2026-08-14 23:48 ` [PATCH net 6/6] gve: fix NULL dereference from premature XSK pool DMA unmap Joshua Washington
2026-08-15 23:49 ` sashiko-bot
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=20260814234845.773189-2-joshwash@google.com \
--to=joshwash@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hramamurthy@google.com \
--cc=jeroendb@google.com \
--cc=jordanrhee@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nktgrg@google.com \
--cc=pabeni@redhat.com \
--cc=pkaligineedi@google.com \
--cc=sdf@fomichev.me \
--cc=stable@vger.kernel.org \
--cc=thostet@google.com \
--cc=willemb@google.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