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@xxxxxxxxx> 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));
> > +     }
> >   }