netdev - Re: [PATCH net-next] amd-xgbe: schedule NAPI on Rx Buffer Unavailable to prevent RX stalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b37d8fa8-04ba-409a-b79b-ebe3b3a76229@amd.com>
Date: Sat, 29 Nov 2025 07:04:10 +0530
From: "Rangoju, Raju" <raju.rangoju@....com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, edumazet@...gle.com,
 davem@...emloft.net, andrew+netdev@...n.ch, Shyam-sundar.S-k@....com
Subject: Re: [PATCH net-next] amd-xgbe: schedule NAPI on Rx Buffer Unavailable
 to prevent RX stalls



On 11/29/2025 12:08 AM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On Fri, 28 Nov 2025 11:20:09 +0530 Rangoju, Raju wrote:
>>> On Mon, 24 Nov 2025 15:41:11 +0530 Raju Rangoju wrote:
>>>> When Rx Buffer Unavailable (RBU) interrupt is asserted, the device can
>>>> stall under load and suffer prolonged receive starvation if polling is
>>>> not initiated. Treat RBU as a wakeup source and schedule the appropriate
>>>> NAPI instance (per-channel or global) to promptly recover from buffer
>>>> shortages and refill descriptors.
>>>
>>> You need to say more.. Under heavy load network devices will routinely
>>> run out of Rx buffers, it's expected if Rx processing is slower than
>>> the network. What hw condition and scenario exactly are you describing
>>> here?
>>
>> During the bi-directional traffic device is running out of RX buffers,
>> it could be because of slower rx processing. HW notifies this via Rx
>> Buffer Unavailable (RBU) interrupt. What is being described above is
>> that, driver should treat RBU interrupt as source to trigger the NAPI
>> poll immediately, rather than waiting for regular rx interrupts to
>> process the rx buffers.
> 
> Ack, all I'm saying is that the commit message seems to be overselling
> the impact of this change. Patch is very very unlikely to make anything
> more "prompt". 99% of the time if Rx buffers are not refilled we are
> either in OOM or Rx overload, so either we won't be able to alloc the
> buffers, or NAPI is already scheduled. But of course trying to schedule
> the NAPI does seem like the more correct reaction, in case we missed an
> IRQ or such. Maybe rephrase a little.. unless there's some magic here
> im not aware of

There's no magic as such. The patch is all about trying to schedule the 
NAPI when an RBU interrupt is received. I'll rephrase the message. Thx.