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

[Przemek Kitszel <przemyslaw.kitszel@intel.com>]

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