lkml.org 
[lkml]   [2018]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context
    From
    Date
    On Tue, 2018-01-09 at 10:02 -0800, Eric Dumazet wrote:
    > On Tue, Jan 9, 2018 at 5:36 AM, Dmitry Safonov <dima@arista.com>
    > wrote:
    > > Warning: Not merge-ready
    > >
    > > I. Current workflow of ksoftirqd.
    > > Softirqs are processed in the context of ksoftirqd iff they are
    > > being raised very frequently. How it works:
    > > do_softirq() and invoke_softirq() deffer pending softirq iff
    > >
    >
    > ...
    >
    > >
    > > Note, that I tested in VMs and I've found that if I produce more
    > > hw irqs on the host, than the results for master are not that
    > > dramatically bad, but still much worse then with RFC.
    > > By that reason I have qualms if my test's results are correct.
    >
    > Note that deferring all NET RX/TX to ksoftirqd is going to
    > dramatically hurt tail latencies.
    >
    > You really should test with RPC like workloads (netperf -t TCP_RR)
    > and
    > hundred of threads per cpu :/

    Yeah, thanks for the reply, will give that a shot.

    >
    > It seems we are going to revert/adapt 4cd13c21b2 , not defer more
    > stuff to ksoftirqd.

    Hmm, what if we use some other logic for deferring/non-deferring
    like checking how many softirqs where serviced during process's
    timeslice and decide if proceed with __do_softirq() or defer it
    not to starve a task? Might that make sense?

    --
    Thanks,
    Dmitry

    \
     
     \ /
      Last update: 2018-01-14 23:22    [W:2.903 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site