On 28.02.25 17:28, Florian Bezdeka wrote:
> On Thu, 2025-02-27 at 14:43 +0100, Sebastian Andrzej Siewior wrote:
>> On 2025-02-26 23:23:30 [+0100], Florian Bezdeka wrote:
>>>> NAPI threads? You have RPS enabled by any chance?
>>>> Would commit
>>>> dad6b97702639 ("net: Allow to use SMP threads for backlog NAPI.")
>>>> 80d2eefcb4c84 ("net: Use backlog-NAPI to clean up the defer_list.")
>>>
>>> With NAPI threads I meant the kernel threads driving the NAPI poll
>>> which can be activated by "echo 1 > /sys/class/net/$device/threaded"
>>>
>>> RPS is build configuration wise enabled but not configured.
>>
>> If RPS is disabled then this might be something else.
>>
>>> As Felix already reported, backporting the mentioned commits to 6.1
>>> would require some manual work. Simply picking all the dependencies
>>> seems too much for now. Will have a look again...
>>
>> Can you reproduce this on a later (more recent) kernel? What are the
>> steps to reproduce this?
>
> I haven't tried that yet but after some tracing I have a much better
> idea whats going on:
>
> Our RT tuning sets ksofirqd threads to FIFO, which seems not the best
> idea. I have to ask some colleagues why they thought this is necessary.
There are some remaining AF_PACKET workloads with RT needs, and NAPI
threading was probably not available yet when this was first configured.
That was at least one reason I heard.
Jan
> As those threads are driving the NAPI poll in my case they might run to
> infinity and with that into the RT throttling - forcing CPUs to idle
> with softirqs pending.
>
> Does that make sense for you as well?
>
> I can force the system into the same situation with threaded NAPI
> enabled and assigning FIFO to the NAPI threads.
>
> FIFO for threads driving network RX traffic doesn't seem wise. A DDoS
> should be quite easy...
>
> Florian
>
>>
>> Sebastian
>
--
Siemens AG, Foundational Technologies
Linux Expert Center
