On 2023-07-05 12:59:28 [-0300], Wander Lairson Costa wrote: > Maybe, under RT, some softirq should run in the context of the "target" > process. For NET_RX, for example, the softirq's would run in the context > of the packet recipient process. Each task_struct would have a list of > pending softirq, which would be checked in a few points, like on scheduling, > when the process enters in the kernel, softirq raise, etc. The default > target process would be ksoftirqd. Does this idea make sense? We had something similar. The softirq runs in the context of the task that raised it. So the networking driver raised NET_RX and it was processed in its context (and still is). The only difference now is that we no longer have a task based "raised bit" but a per-CPU. For RPS you already pulled the skb from the NIC, you need to process it and this isn't handled in the task's context but on a specific CPU. Let me look at per-CPU backlog thread or ripping the warning out… Sebastian
