Rather than my previous thought, I'm now thinking the best approach would be:<br><a href="https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/57a001bf360c00113cf745187992f52dfb8acbca">https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/57a001bf360c00113cf745187992f52dfb8acbca</a><br>
<br>Strictly pair SNP->Transmit and SNP->GetStatus returns.  Given the iPXE example, I think this is the best way to reliably proceed without leaking iobufs.  No possible tx queue below iPXE, but I see no reliable alternative that would work with everything.<br>
<br><div class="gmail_quote">On Sat, Jan 14, 2012 at 12:48 PM, Jarrod Johnson <span dir="ltr"><<a href="mailto:jarrod.b.johnson@gmail.com">jarrod.b.johnson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Incidentally, the implementation that I'm trying out for now consists of:<br><a href="https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/9dd1a8f1812c146fdf45c27a118e5a51e8a7d7ce" target="_blank">https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/9dd1a8f1812c146fdf45c27a118e5a51e8a7d7ce</a><br>

<a href="https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/57a001bf360c00113cf745187992f52dfb8acbca" target="_blank">https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/57a001bf360c00113cf745187992f52dfb8acbca</a><br>
<br>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.<div class="HOEnZb">
<div class="h5"><br>
<br><div class="gmail_quote">On Sat, Jan 14, 2012 at 12:39 PM, Jarrod Johnson <span dir="ltr"><<a href="mailto:jarrod.b.johnson%2Bipxe@gmail.com" target="_blank">jarrod.b.johnson+ipxe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>


</blockquote></div><br>
</div></div></blockquote></div><br>