Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour

[Bean]

On Thu, Apr 26, 2012 at 12:59 PM, Seth Goldberg
<address@hidden> wrote:
>
>
> On Apr 25, 2012, at 11:22 PM, Bean <address@hidden> wrote:
>
>> On Thu, Apr 26, 2012 at 12:10 PM, Seth Goldberg
>> <address@hidden> wrote:
>>>  How does this work around the issue?  I'm not seeing it -- we call SNP 
>>> directly.  We don't go through UDP or any other upper layers in efinet.  
>>> When I did the investigation, I removed ALL other consumers of SNP manually 
>>> via the efi shell before loading GRUB 2 and still saw packet loss.
>>
>> Hi,
>>
>> Normal OS has interrupt handler that removes the packet from nic
>> buffer as soon as possible, but grub2 is basically single thread and
>> use pull mode. So we should make the pulling loop as short as
>> possible. In async mode, if a packet is not found, it has to returned
>> to upper layer and retry, while in sync mode, the loop is inside the
>> driver which make it more efficient. It's something like reading 100
>> bytes from disk is much faster than 100 x 1 byte.
>>
>
>  Marginally.  We still need to handle that packet inside grub once it is 
> received.  Besides, modern nic hardware has receive rings and overrun is rare 
> especially with non-pipelined tftp (unless there is a ton of broadcast or 
> unicast packets sent to the client while in grub which is unlikely in 
> practice, so I'm not seeing where the real benefit is here.  I can definitely 
> understand your finding inefficiencies in the uefi udp-snp (or in systems 
> I've seen it's more like UDP-MNP-SNP), so no argument there, but for grub 2, 
> it's already using the lowest level interface it can (without calling undi 
> directly).

Hi,

Well, it's possible that different uefi implementation has different
issues, but at least this method works quite well for the machines I
tested. I can send you a test program if you want to give it a try.

-- 
Best wishes
Bean