[ipxe-devel] snpnet/efi_snp bad interaction?

Jarrod Johnson jarrod.b.johnson at gmail.com
Sat Jan 14 17:48:07 UTC 2012

Incidentally, the implementation that I'm trying out for now consists of:

The first being getting Emulex to work, the second being less picky when I
realized that iPXE and probably others do very odd things with txbuf that
would have caused my first change to have infinite transmit loops.

On Sat, Jan 14, 2012 at 12:39 PM, Jarrod Johnson <
jarrod.b.johnson+ipxe at gmail.com> wrote:

> 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/809e6938/attachment.htm>

More information about the ipxe-devel mailing list