[ipxe-devel] snpnet/efi_snp bad interaction?

[Jarrod Johnson]

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...

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.

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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20120114/4a3369b0/attachment.htm>