Messages in this thread | | | Subject | Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context | From | Dmitry Safonov <> | Date | Wed, 10 Jan 2018 21:48:00 +0000 |
| |
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
| |