On 1.7.2019. 3:16, David Gwynne wrote:
> interface rx queue processing includes detection of when the stack
> becomes too busy to process packets.
>
> there's three stages to this mechanism. firstly, everything is fine
> and the packets are simply queued for processing. the second is the
> "pressure_return" stage where the interface has queued a few times,
> but the stack hasn't run to process them. ifiq_input returns 1 in
> this situation to notify the nic that it should start to slow down.
> the last stage is the "pressure_drop" stage where the nic has
> continued to queue packets and the stack still hasnt run. in this
> stage it drops the packets and returns 1.
>
> independently, the stack looks for lost clock ticks (because the stack
> traditionally blocked softclock ticks) as a livelock detection
> mechanism. this no longer works that well now we're in an MP worls.
> firstly, the stack could be running on a different cpu to the clock and
> therefore wont block it. secondly, the stack runs in a thread and doesnt
> raise the spl, so it shouldnt be blocking clock interrupts even if it is
> sharing a cpu now.
>
> therefore the traditional livelock detection mechanism doesnt work and
> should be moved away from. the replacement is getting nics that
> implement rx ring moderation to look at the return value of the rx queue
> input function and telling the rings to slow down. that is what this
> diff does.
>
> i've compiled it on amd64, which covers most of the drivers, but there's
> a few in fdt that i did blind and havent tested. ive tested a couple of
> the interfaces, but more testing would be appreciated.
Hi,
without this diff when box is under pressure ifconfig output can take up
from 10 to 20 min to finish...
11m26.31s real 0m00.01s user 1m37.16s system
with this diff and
net.link.ifrxq.pressure_return=4
net.link.ifrxq.pressure_drop=8
it takes under minute
0m40.55s real 0m00.00s user 0m00.80s system
every time numbers will be different, but this diff makes my test box
smoother under pressure ...
