The commit adds support to throttle the rate of the RX IRQs to a specified
value. The effect is, that no RX IRQs below the time threshold will fire and
therefore the CPU load gets reduced on the host. Trade-off gaming between
cpu load, throughput, overload.
Modular Sculpt 23.10 on S938 as testcase. In brackets the CPU affinity is
denoted.
ipxe (0,0) -> nic_router (1,0) -> Debian VM vbox6 (3,0) and (3,1)
VM: iperf -C X.X.X.X -t 60 -R
iperf server X.X.X.X is outside Sculpt and sends data due to '-R' to VM
Non representative measure points:
cpu load - ipxe - nic_router - iperf throughput
--------------------------------------------------
w/o patch - ~80% - ~50% - ~706 MBit/s - 0 -> throttling off by default on S938
patch 651 - ~20% - ~35% - ~763 MBit/s - 651 -> 0.166ms throttle RX IRQ
patch 5580 - ~15% - ~25% - ~650 MBit/s - 5580 -> 1.4ms throttle RX IRQ
Issue #5149
A bunch of transmit requests received by the Uplink server (nic_router)
are currently added one by one to the ring buffer and every time the hardware
is notified to process each single request.
Instead, add as many as possible transmit requests in the ring buffer of
the hardware and when done trigger the hardware to process the ring.
Additionally, don't receive an "processed" TX IRQ for each element in the
ring, which causes high CPU load.
With this commit the TX IRQs in the ipxe driver for a
iperf -c X.X.X.X -t 60
from within a VM to the outside iperf server is reduced from about
~2'600'000 IRQs to about ~200'000. The overall CPU load for the driver
(when executed alone on CPU 0) is reduced from ~85 percent load to ~45 percent
load.
Issue #5149
Also, the repository URL was adapted to the permanent redirect to github
to prevent the following warning.
dde_ipxe download http://git.ipxe.org/ipxe.git
dde_ipxe git Cloning into 'src/lib/dde_ipxe'...
dde_ipxe git warning: redirecting to https://github.com/ipxe/ipxe/
dde_ipxe update src/lib/dde_ipxe
Inspired by the mailing-list posting [1], this commit removes the
MAC/PHY reset for all Intel cards and effectively prevents the bandwidth
drop to 10 MBit/s (e.g., on i217lm). I understand it as preliminary fix
for practical reasons - a real fix would be to update the ipxe port and
monitor for more postings like the one mentioned.
[1] http://lists.ipxe.org/pipermail/ipxe-devel/2015-December/004511.html
