diff options
author | Michael Brown <mcb30@ipxe.org> | 2024-03-18 15:21:04 +0000 |
---|---|---|
committer | Michael Brown <mcb30@ipxe.org> | 2024-03-18 15:36:15 +0000 |
commit | 8c7e2d6068e24e66bcb7e2b7f02c87d7aef32635 (patch) | |
tree | b9c08e325a36c0aba7dce6c31eb53c6cfc2e9381 /src/include/cpu.h | |
parent | c11734eee0fcaaf49f6f3f0342f928e1e5232560 (diff) | |
download | ipxe-snppad.zip ipxe-snppad.tar.gz ipxe-snppad.tar.bz2 |
[snp] Pad transmit buffer length to work around buggy vendor driverssnppad
The Mellanox/Nvidia UEFI SNP driver is built from the same codebase as
the iPXE driver, and appears to contain the bug that was fixed in
commit c11734e ("[golan] Use ETH_HLEN for inline header size"). This
results in identical failures when using the SNP interface (via e.g.
snponly.efi) to drive a Mellanox card while EAPoL is enabled.
Work around the underlying UEFI SNP driver bug by padding transmit I/O
buffers to the minimum Ethernet frame length before passing them to
the underlying SNP driver's Transmit() function.
This padding is not technically necessary, since almost all modern
hardware will insert transmit padding as necessary (and where the
hardware does not support doing so, the underlying SNP driver is
responsible for adding any necessary padding). However, it is
guaranteed to be harmless (other than a miniscule performance impact):
the Ethernet specification requires zero padding up to the minimum
frame length for packets that are transmitted onto the wire, and so
the receiver will see the same packet whether or not we manually
insert this padding in software.
The additional padding causes the underlying Mellanox SNP driver to
avoid its faulty code path, since it will never be asked to transmit a
very short packet.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Diffstat (limited to 'src/include/cpu.h')
0 files changed, 0 insertions, 0 deletions