Messages in this thread | | | Subject | Re: [PATCH] softirq: let ksoftirqd do its job | From | Eric Dumazet <> | Date | Wed, 31 Aug 2016 16:11:06 -0700 |
| |
On Wed, 2016-08-31 at 15:47 -0700, Rick Jones wrote: > With regard to drops, are both of you sure you're using the same socket > buffer sizes?
Does it really matter ?
I used the standard /proc/sys/net/core/rmem_default, but under flood receive queue is almost always full, even if you make it bigger.
By varying its size, you only make batches bigger and number of context switches should be lower, if only two threads are competing for the cpu.
Exact 'optimal' size would depend on various factors, depending on application and platform constraints.
> > In the meantime, is anything interesting happening with TCP_RR or > TCP_STREAM?
TCP_RR is driven by the network latency, we do not drop packets in the socket itself.
TC_STREAM is normally paced by the ability of the receiver to send ACK packets. TCP has this auto regulating mode, unless the sender violates the RFC(s).
If your question is :
What happens if thousands of threads on the host want the cpu, and ksoftirqd gets not enough cycles by virtue of being a normal thread ?
Then, you are back to typical provisioning problems, and normally people play with priorities and containers/cgroups, and/or various techniques like RPS/RFS
(You can change ksoftirqd priority if you like)
| |