On Fri, 25 Sep 2020 20:23:37 +0200 Eric Dumazet <eduma...@google.com> wrote:
> On Fri, Sep 25, 2020 at 8:16 PM Stephen Hemminger > <step...@networkplumber.org> wrote: > > > > On Fri, 25 Sep 2020 10:15:25 -0700 > > Wei Wang <wei...@google.com> wrote: > > > > > > > In terms of performance, I ran tcp_rr tests with 1000 flows with > > > > > various request/response sizes, with RFS/RPS disabled, and compared > > > > > performance between softirq vs kthread. Host has 56 hyper threads and > > > > > 100Gbps nic. > > > > It would be good to similar tests on othere hardware. Not everyone has > > server class hardware. There are people running web servers on untuned > > servers over 10 years old; this may cause a regression there. > > > > Not to mention the slower CPU's in embedded systems. How would this > > impact OpenWrt or Android? > > Most probably you won't notice a significant difference. > > Switching to a kthread is quite cheap, since you have no MMU games to play > with. That makes sense, and in the past when doing stress tests the napi work was mostly on the kthread already. > > > > Another potential problem is that if you run real time (SCH_FIFO) > > threads they have higher priority than kthread. So for that use > > case, moving networking to kthread would break them. > > Sure, playing with FIFO threads is dangerous. > > Note that our plan is still to have softirqs by default. > > If an admin chose to use kthreads, it is its choice, not ours. > > This is also why I very much prefer the kthread approach to the work > queue, since the work queue could not be fine tuned. Agree with you, best to keep this as opt-in.
