mirror of
https://github.com/ipxe/ipxe
synced 2026-01-25 07:31:04 +03:00
d2e1e591ab
When operating in the DQO operating mode, the device will defer writing transmit and receive completions until an entire internal cacheline (128 bytes) is full, or until an associated interrupt is asserted. Since each receive descriptor is 32 bytes, this will cause received packets to be effectively delayed until up to three further packets have arrived. When network traffic volumes are very low (such as during DHCP, DNS lookups, or TCP handshakes), this typically induces delays of up to 30 seconds and results in a very poor user experience. Work around this hardware problem in the same way as for the Intel 40GbE and 100GbE NICs: by enabling dummy MSI-X interrupts to trick the hardware into believing that it needs to write out completions to host memory. There is no documentation around the interrupt rearming mechanism. The value written to the interrupt doorbell does not include a consumer counter value, and so must be relying on some undocumented ordering constraints. Comments in the Linux driver source suggest that the authors believe that the device will automatically and atomically mask an MSI-X interrupt at the point of asserting it, that any further interrupts arriving before the doorbell is written will be recorded in the pending bit array, and that writing the doorbell will therefore immediately assert a new interrupt if needed. In the absence of any documentation, choose to rearm the interrupt once per observed completion. This is overkill, but is less impactful than the alternative of rearming the interrupt unconditionally on every poll. Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE README File Quick start guide: cd src make For any more detailed instructions, see http://ipxe.org