All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Harshitha Ramamurthy <hramamurthy@google.com>
Cc: <netdev@vger.kernel.org>, <joshwash@google.com>,
	<andrew+netdev@lunn.ch>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<willemb@google.com>, <jordanrhee@google.com>,
	<nktgrg@google.com>, <maolson@google.com>, <thostet@google.com>,
	<csully@google.com>, <bcf@google.com>,
	<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>,
	Eddie Phillips <eddiephillips@google.com>
Subject: Re: [PATCH net v2] gve: fix Rx queue stall on alloc failure
Date: Fri, 10 Jul 2026 12:13:59 +0200	[thread overview]
Message-ID: <alDF5//N4cP2sCYK@boxer> (raw)
In-Reply-To: <20260709211906.3322883-1-hramamurthy@google.com>

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
> 

  reply	other threads:[~2026-07-10 10:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 21:19 [PATCH net v2] gve: fix Rx queue stall on alloc failure Harshitha Ramamurthy
2026-07-10 10:13 ` Maciej Fijalkowski [this message]
2026-07-10 14:24 ` Przemek Kitszel
2026-07-10 17:23   ` Eddie Phillips
2026-07-11  4:11     ` Przemek Kitszel

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=alDF5//N4cP2sCYK@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bcf@google.com \
    --cc=csully@google.com \
    --cc=davem@davemloft.net \
    --cc=eddiephillips@google.com \
    --cc=edumazet@google.com \
    --cc=hramamurthy@google.com \
    --cc=jordanrhee@google.com \
    --cc=joshwash@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maolson@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=nktgrg@google.com \
    --cc=pabeni@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.