[PATCH net v2] gve: fix Rx queue stall on alloc failure

[PATCH net v2] gve: fix Rx queue stall on alloc failure

[Harshitha Ramamurthy]

From: Eddie Phillips <eddiephillips@google.com>

When the system is under extreme memory pressure, page allocations can
fail during the Rx buffer refill loop. If the number of buffers posted
to hardware falls below a critical low threshold and the refill loop
exits due to allocation failures, the queue can stall:

1. The device drops incoming packets because there are no descriptors.
2. Since no packets are processed, no Rx completions are generated.
3. Because no completions occur, NAPI is never scheduled, preventing
   the refill loop from running again even after memory is freed.

This results in a permanent queue stall.

Resolve this by introducing a starvation recovery timer for each Rx queue.
If the number of buffers posted to hardware falls below a critical low
threshold, start a timer to periodically reschedule NAPI. Once NAPI runs
and successfully refills the queue above the threshold, the timer is
not rescheduled.

The threshold is set to 32 because a single maximum-sized Receive Segment
Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path.
Lower thresholds (such as 8 or 16) would be insufficient to process a
complete maximum-sized RSC packet, risking packet drops or unexpected
hardware behavior under memory pressure. Setting the threshold to 32
guarantees a safe margin to handle at least one full RSC packet.

Cc: stable@vger.kernel.org
Fixes: 9b8dd5e5ea48 ("gve: DQO: Add RX path")
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Eddie Phillips <eddiephillips@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
Changes in v2:
- Link to v1: https://lore.kernel.org/netdev/20260701005341.3699161-1-hramamurthy@google.com/
- Relocated the starvation timer to the end of gve_rx_ring to avoid polluting
hotpath cachelines
- Decoupled timer lifecycle from allocation cycles by moving initialization
and shutdown to start/stop pathways instead of setup/remove pathways.
- Added explicit rationale for the 32-descriptor threshold
(GVE_RX_BUF_THRESH_DQO) ensuring it is safe for maximum-sized RSC packets.
- Removed addition of a stat tracking critical low buffer events

 drivers/net/ethernet/google/gve/gve.h        |  3 +++
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 34 ++++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git a/drivers/net/ethernet/google/gve/gve.h b/drivers/net/ethernet/google/gve/gve.h
index 2f7bd330..bdd53d08 100644
--- a/drivers/net/ethernet/google/gve/gve.h
+++ b/drivers/net/ethernet/google/gve/gve.h
@@ -13,6 +13,7 @@
 #include <linux/netdevice.h>
 #include <linux/net_tstamp.h>
 #include <linux/pci.h>
+#include <linux/timer.h>
 #include <linux/ptp_clock_kernel.h>
 #include <linux/u64_stats_sync.h>
 #include <net/page_pool/helpers.h>
@@ -41,6 +42,7 @@
 
 /* Interval to schedule a stats report update, 20000ms. */
 #define GVE_STATS_REPORT_TIMER_PERIOD	20000
+#define GVE_RX_NAPI_RESCHED_MS 20 /* msecs */
 
 /* Numbers of NIC tx/rx stats in stats report. */
 #define NIC_TX_STATS_REPORT_NUM	0
@@ -341,6 +343,7 @@ struct gve_rx_ring {
 	struct xdp_rxq_info xdp_rxq;
 	struct xsk_buff_pool *xsk_pool;
 	struct page_frag_cache page_cache; /* Page cache to allocate XDP frames */
+	struct timer_list starvation_timer; /* for queue starvation recovery */
 };
 
 /* A TX desc ring entry */
diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 02cba280..8271f731 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -18,6 +18,16 @@
 #include <net/tcp.h>
 #include <net/xdp_sock_drv.h>
 
+static void gve_rx_starvation_timer(struct timer_list *t)
+{
+	struct gve_rx_ring *rx = timer_container_of(rx, t, starvation_timer);
+	struct gve_priv *priv = rx->gve;
+	struct gve_notify_block *block;
+
+	block = &priv->ntfy_blocks[rx->ntfy_id];
+	napi_schedule(&block->napi);
+}
+
 static void gve_rx_free_hdr_bufs(struct gve_priv *priv, struct gve_rx_ring *rx)
 {
 	struct device *hdev = &priv->pdev->dev;
@@ -120,6 +130,7 @@ void gve_rx_stop_ring_dqo(struct gve_priv *priv, int idx)
 
 	if (rx->dqo.page_pool)
 		page_pool_disable_direct_recycling(rx->dqo.page_pool);
+	timer_shutdown_sync(&rx->starvation_timer);
 	gve_remove_napi(priv, ntfy_idx);
 	gve_rx_remove_from_block(priv, idx);
 	gve_rx_reset_ring_dqo(priv, idx);
@@ -208,8 +219,10 @@ static int gve_rx_alloc_hdr_bufs(struct gve_priv *priv, struct gve_rx_ring *rx,
 void gve_rx_start_ring_dqo(struct gve_priv *priv, int idx)
 {
 	int ntfy_idx = gve_rx_idx_to_ntfy(priv, idx);
+	struct gve_rx_ring *rx = &priv->rx[idx];
 
 	gve_rx_add_to_block(priv, idx);
+	timer_setup(&rx->starvation_timer, gve_rx_starvation_timer, 0);
 	gve_add_napi(priv, ntfy_idx, gve_napi_poll_dqo);
 }
 
@@ -365,6 +378,7 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
 	struct gve_rx_compl_queue_dqo *complq = &rx->dqo.complq;
 	struct gve_rx_buf_queue_dqo *bufq = &rx->dqo.bufq;
 	struct gve_priv *priv = rx->gve;
+	u32 num_bufs_avail_to_hw;
 	u32 num_avail_slots;
 	u32 num_full_slots;
 	u32 num_posted = 0;
@@ -400,6 +414,26 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
 	}
 
 	rx->fill_cnt += num_posted;
+
+	/* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
+	 * visible to the hardware, the hardware is in danger of starving
+	 * and cannot trigger interrupts.
+	 *
+	 * We use a threshold of 32 because a single maximum-sized RSC
+	 * packet can consume up to 19 descriptors in the Rx path. Lower
+	 * thresholds (e.g., 8 or 16) would be unsafe as they could cause
+	 * the device to drop/stall on a maximum-sized RSC packet.
+	 *
+	 * Start the timer to periodically reschedule NAPI and recover.
+	 */
+	num_bufs_avail_to_hw =
+		((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
+		 bufq->head) & bufq->mask;
+
+	if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
+		mod_timer(&rx->starvation_timer,
+			  jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
+	}
 }
 
 static void gve_rx_skb_csum(struct sk_buff *skb,
-- 
2.55.0.795.g602f6c329a-goog

Re: [PATCH net v2] gve: fix Rx queue stall on alloc failure

[Maciej Fijalkowski]

On Thu, Jul 09, 2026 at 09:19:06PM +0000, Harshitha Ramamurthy wrote:
> From: Eddie Phillips <eddiephillips@google.com>
> 
> When the system is under extreme memory pressure, page allocations can
> fail during the Rx buffer refill loop. If the number of buffers posted
> to hardware falls below a critical low threshold and the refill loop
> exits due to allocation failures, the queue can stall:
> 
> 1. The device drops incoming packets because there are no descriptors.
> 2. Since no packets are processed, no Rx completions are generated.
> 3. Because no completions occur, NAPI is never scheduled, preventing
>    the refill loop from running again even after memory is freed.
> 
> This results in a permanent queue stall.
> 
> Resolve this by introducing a starvation recovery timer for each Rx queue.
> If the number of buffers posted to hardware falls below a critical low
> threshold, start a timer to periodically reschedule NAPI. Once NAPI runs
> and successfully refills the queue above the threshold, the timer is
> not rescheduled.
> 
> The threshold is set to 32 because a single maximum-sized Receive Segment
> Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path.
> Lower thresholds (such as 8 or 16) would be insufficient to process a
> complete maximum-sized RSC packet, risking packet drops or unexpected
> hardware behavior under memory pressure. Setting the threshold to 32
> guarantees a safe margin to handle at least one full RSC packet.
> 
> Cc: stable@vger.kernel.org
> Fixes: 9b8dd5e5ea48 ("gve: DQO: Add RX path")
> Reviewed-by: Jordan Rhee <jordanrhee@google.com>
> Signed-off-by: Eddie Phillips <eddiephillips@google.com>
> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> ---
> Changes in v2:
> - Link to v1: https://lore.kernel.org/netdev/20260701005341.3699161-1-hramamurthy@google.com/
> - Relocated the starvation timer to the end of gve_rx_ring to avoid polluting
> hotpath cachelines
> - Decoupled timer lifecycle from allocation cycles by moving initialization
> and shutdown to start/stop pathways instead of setup/remove pathways.
> - Added explicit rationale for the 32-descriptor threshold
> (GVE_RX_BUF_THRESH_DQO) ensuring it is safe for maximum-sized RSC packets.
> - Removed addition of a stat tracking critical low buffer events
> 
>  drivers/net/ethernet/google/gve/gve.h        |  3 +++
>  drivers/net/ethernet/google/gve/gve_rx_dqo.c | 34 ++++++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+)
> 

[...]

>  	rx->fill_cnt += num_posted;
> +
> +	/* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
> +	 * visible to the hardware, the hardware is in danger of starving
> +	 * and cannot trigger interrupts.
> +	 *
> +	 * We use a threshold of 32 because a single maximum-sized RSC
> +	 * packet can consume up to 19 descriptors in the Rx path. Lower
> +	 * thresholds (e.g., 8 or 16) would be unsafe as they could cause
> +	 * the device to drop/stall on a maximum-sized RSC packet.
> +	 *
> +	 * Start the timer to periodically reschedule NAPI and recover.
> +	 */
> +	num_bufs_avail_to_hw =
> +		((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
> +		 bufq->head) & bufq->mask;
> +
> +	if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
> +		mod_timer(&rx->starvation_timer,
> +			  jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
> +	}

nit: redundant braces

>  }
>  
>  static void gve_rx_skb_csum(struct sk_buff *skb,
> -- 
> 2.55.0.795.g602f6c329a-goog
> 

Re: [PATCH net v2] gve: fix Rx queue stall on alloc failure

[Przemek Kitszel]

> @@ -400,6 +414,26 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
>   	}
>   
>   	rx->fill_cnt += num_posted;
> +
> +	/* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
> +	 * visible to the hardware, the hardware is in danger of starving
> +	 * and cannot trigger interrupts.
> +	 *
> +	 * We use a threshold of 32 because a single maximum-sized RSC
> +	 * packet can consume up to 19 descriptors in the Rx path. Lower
> +	 * thresholds (e.g., 8 or 16) would be unsafe as they could cause
> +	 * the device to drop/stall on a maximum-sized RSC packet.
> +	 *
> +	 * Start the timer to periodically reschedule NAPI and recover.
> +	 */
> +	num_bufs_avail_to_hw =
> +		((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
> +		 bufq->head) & bufq->mask;
> +
> +	if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {

nice bit-arith tricks, but perhaps a simpler condiion like:
	if (num_avail_slots + num_posted < GVE_RX_BUF_THRESH_DQO)
would be sufficient?

> +		mod_timer(&rx->starvation_timer,
> +			  jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
> +	}
>   }

Re: [PATCH net v2] gve: fix Rx queue stall on alloc failure

[Eddie Phillips]

On Fri, Jul 10, 2026 at 7:24 AM Przemek Kitszel
<przemyslaw.kitszel@intel.com> wrote:
>
>
> > @@ -400,6 +414,26 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
> >       }
> >
> >       rx->fill_cnt += num_posted;
> > +
> > +     /* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
> > +      * visible to the hardware, the hardware is in danger of starving
> > +      * and cannot trigger interrupts.
> > +      *
> > +      * We use a threshold of 32 because a single maximum-sized RSC
> > +      * packet can consume up to 19 descriptors in the Rx path. Lower
> > +      * thresholds (e.g., 8 or 16) would be unsafe as they could cause
> > +      * the device to drop/stall on a maximum-sized RSC packet.
> > +      *
> > +      * Start the timer to periodically reschedule NAPI and recover.
> > +      */
> > +     num_bufs_avail_to_hw =
> > +             ((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
> > +              bufq->head) & bufq->mask;
> > +
> > +     if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
>
> nice bit-arith tricks, but perhaps a simpler condiion like:
>         if (num_avail_slots + num_posted < GVE_RX_BUF_THRESH_DQO)
> would be sufficient?
>

Descriptors are only committed to the hardware in batches matching the
doorbell notification stride. Masking is necessary because `num_avail_slots
+ num_posted` falsely includes buffers that are written to the ring but not yet
doorbelled. We don't want the driver to overestimate the hardware's active
buffer count, fail to arm the watchdog timer, and trigger a silent rx deadlock
under memory pressure.

> > +             mod_timer(&rx->starvation_timer,
> > +                       jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
> > +     }
> >   }

Re: [PATCH net v2] gve: fix Rx queue stall on alloc failure

[Przemek Kitszel]

On 7/10/26 19:23, Eddie Phillips wrote:
> On Fri, Jul 10, 2026 at 7:24 AM Przemek Kitszel
> <przemyslaw.kitszel@intel.com> wrote:
>>
>>
>>> @@ -400,6 +414,26 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
>>>        }
>>>
>>>        rx->fill_cnt += num_posted;
>>> +
>>> +     /* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
>>> +      * visible to the hardware, the hardware is in danger of starving
>>> +      * and cannot trigger interrupts.
>>> +      *
>>> +      * We use a threshold of 32 because a single maximum-sized RSC
>>> +      * packet can consume up to 19 descriptors in the Rx path. Lower
>>> +      * thresholds (e.g., 8 or 16) would be unsafe as they could cause
>>> +      * the device to drop/stall on a maximum-sized RSC packet.
>>> +      *
>>> +      * Start the timer to periodically reschedule NAPI and recover.
>>> +      */
>>> +     num_bufs_avail_to_hw =
>>> +             ((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
>>> +              bufq->head) & bufq->mask;
>>> +
>>> +     if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
>>
>> nice bit-arith tricks, but perhaps a simpler condiion like:
>>          if (num_avail_slots + num_posted < GVE_RX_BUF_THRESH_DQO)
>> would be sufficient?
>>
> 
> Descriptors are only committed to the hardware in batches matching the
> doorbell notification stride. Masking is necessary because `num_avail_slots
> + num_posted` falsely includes buffers that are written to the ring but not yet
> doorbelled. We don't want the driver to overestimate the hardware's active
> buffer count, fail to arm the watchdog timer, and trigger a silent rx deadlock
> under memory pressure.

OK, makes sense, thank you for explanation.
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>

> 
>>> +             mod_timer(&rx->starvation_timer,
>>> +                       jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
>>> +     }
>>>    }