iPXE currently calls cpu_nap() while performing DHCP, in order to reduce CPU utilisation on virtual machines. Under mild broadcast load (~100 packets per second), this can cause received packets to be dropped because the receive descriptor ring is overrun before the next 18Hz timer interrupt wakes up the CPU. The result is that DHCP is likely to intermittently fail on networks with appreciable amounts of broadcast (or multicast) traffic. This behaviour was introduced in the series of commits which generalised the "dhcp" command to the "ifconf" command. The earlier code (which did not handle IPv6 configuration) had no call to cpu_nap() and so did not suffer from this problem. Fix by removing the call to cpu_nap() in ifpoller_progress(). This has the undesirable side effect that CPU utilisation will remain at 100% while waiting for DHCP to complete (which can take several seconds, if we have to wait around for potential ProxyDHCP offers to arrive). Reported-by: Alex Davies <adavies@jumptrading.com> Reported-by: Christoffer Stokbæk <christoffers@easyspeedy.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>tags/v1.20.1
|
||
28 | 28 |
|
29 | 29 |
|
30 | 30 |
|
31 |
|
|
32 | 31 |
|
33 | 32 |
|
34 | 33 |
|
|
||
142 | 141 |
|
143 | 142 |
|
144 | 143 |
|
145 |
|
|
146 |
|
|
147 |
|
|
148 | 144 |
|
149 | 145 |
|
150 | 146 |
|