Trying to understand precisely the intent of txbuf in the SNP->GetStatus part of the uefi spec broke by brain, but it seems I'm in good company judging by vendor behavior and iPXE comments...<br><br>So snpnet polls *until* null txbuf (which is the opposite of the use cases that efi_snp was looking at).  It also seems to expect that txbuf pointer will match up to something in tx_queue.  Considering iPXE's own GetStatus will only ever return or a pointer to "Which idiot designed this API?", one doesn't look far to see this expectation doesn't match reality.  It appears the side effect of this will be some lost memory but no hang, which may be the realistic scenario to deal with when faced with the limitations of efi_snp impelementation.  I will say that Intel's EFI network driver development guide suggests that the point of txbuf is to let upper layers free the memory, so efi_snp doesn't quite align with that recommendation.<br>
<br>The other oddity is that some SNP interfaces (Emulex) seem to *always* return non-null txbuf, meaning the snpnet looping will never exit.  The good news being that with Emulex's SNP, the txbuf addresses returned actually line up in a way that causes netdev_tx_complete to be called on the appropriate iobuf.  In the Emulex case, the last transmitted buffer is returned repeatedly instead of reverting back to NULL as some other vendors (and iPXE) would do.<br>
<br>Is the best course for the snpnet poll to terminate when as many non-null returns come back as ipxe has transmitted, regardless of the value of the txbuf pointer, freeing if possible as it does today?  Should efi_snp somehow change to point at an address that was transmitted previously?<br>