[ipxe-devel] snpnet/efi_snp bad interaction?

[Jarrod Johnson]

Rather than my previous thought, I'm now thinking the best approach would
be:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/57a001bf360c00113cf745187992f52dfb8acbca

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.

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

> Incidentally, the implementation that I'm trying out for now consists of:
>
> https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/9dd1a8f1812c146fdf45c27a118e5a51e8a7d7ce
>
> https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/57a001bf360c00113cf745187992f52dfb8acbca
>
> 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/6351c883/attachment.htm>