[ipxe-devel] snpnet/efi_snp bad interaction?

[Jarrod Johnson]

Sorry, I meant
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/03281fe80a9346acdd6f34f8744740520017113b

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

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