[adding Paolo, Eric] Alexei Starovoitov <alexei.starovoi...@gmail.com> writes:
> On Thu, Sep 28, 2017 at 02:57:08PM +0200, Jesper Dangaard Brouer wrote: [...] >> + wake_up_process(rcpu->kthread); > > In general the whole thing looks like 'threaded NAPI' that Hannes was > proposing some time back. I liked it back then and I like it now. > I don't remember what were the objections back then. > Something scheduler related? > Adding Hannes. Yes. The main objection from Eric at that time was that user space now starts to compete with the threaded NAPI threads depending on process priorities, which are under control of user space. Softirq always runs first to end. Networking could starve because a process with higher priority is runnable. At that time Eric found a way to fix the particular problem, which resulted in commit 4cd13c21b207e80d. Pinning and other control is also possible from user space, causing more complex tuning set ups and problems will be harder to debug. In particular after Eric's patch threaded NAPI proofed itself to be not useful anymore, because his patch successfully deferred work to the ksoftirqd more reliable thus allowing the UDP rx queue to get drained by user space. > Still curious about the questions I asked in the other thread > on what's causing it to be so much better than RPS My guess is that RPS uses expensive IPI to notify the remote softirq. The batching size on RPS depends on how many packets could get worked on during one softirq invocation on the source CPU until we wake up remote CPU(s!), if they are not constantly running.
