[ipxe-devel] Failed file transfers for iSCSI protocol

Michael Brown mcb30 at ipxe.org
Sun Dec 15 11:45:27 UTC 2019


On 15/12/2019 04:19, Heinrich Schuchardt wrote:
> The failure starts when the receive buffer is filled up. No message is
> sent by iPXE for a few seconds. Afterwords a new login to the iSCSI
> server occurs.

This is curious.  The iSCSI receive datapath is essentially zero-copy: 
U-Boot provides the destination buffer when issuing the 
EFI_BLOCK_IO_PROTOCOL.ReadBlocks() call, and iPXE will copy data to this 
buffer as each new packet arrives.  There is no internal iSCSI- or 
SCSI-level buffer that could be filling up.

The only plausible place I can find in which buffering would occur is in 
the TCP receive queue.  It's very likely that the difference in speeds 
would cause iPXE to essentially suffer from a high received packet loss 
rate, in which case it will end up maintaining a queue of what are 
effectively packets received out of order.  This would be visible in a 
detailed packet trace from the presence of TCP SACKs sent by iPXE.

However, the TCP SACK mechanism should already be robust enough to 
recover from this situation.  iPXE will discard packets from the receive 
queue if it runs out of memory for any reason, so the network driver 
will always be able to allocate space for newly received packets, 
allowing forward progress to be made once the server retransmits the 
missing packets (which happens almost immediately when using SACK).

Could you publish the full .pcap file for your reproducible failure case?

Thanks,

Michael



More information about the ipxe-devel mailing list