> it does not, please read the code again. We iterate over all active bits
> in the 'pending' bitmask.
OK.
> net_rx_action() stops spinning if 1) a jiffy has passed 2) 300 packets
> have been processed. [the jiffy test is not completely accurate
It is. The break is forced not earlier than after one jiffie, but
it may loop for up to 2 jiffies.
> there is nothing sacred about the old method of processing NET_RX_SOFTIRQ,
> then NET_TX_SOFTIRQ, then breaking out of do_softirq() (the mechanizm was
> a bit more complex than that, but in insignificant ways). It's just as
> arbitrary as 10 loops - with the difference that 10 loops perform better.
Do not cheat yourself. 10 is more than 1 by order of magnitude.
I would eat this argument if the limit was 2. :-)
> > Most likely, your problem will disappear when you renice ksoftirqd
> > to higher priority f.e. equal to priority of tux threads.
>
> (no. see the previous mails.)
But I do not know what exactly to look for there.
Please, explain who exactly obtains an advantage of looping.
net_rx_action()? Do you see drops in backlog?
Actually, I could see a sense in your approach if you said
something sort of: "I see drops in backlog, I want to increase
it to 3000, but it breaks latency, so that let it remain 300,
but instead I will make 10 loops". This would be sane justification
at least.
net_tx_action()? It does not look critical.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/