grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bean
Subject: Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour
Date: Fri, 27 Apr 2012 09:50:08 +0800

On Fri, Apr 27, 2012 at 1:10 AM, Seth Goldberg <address@hidden> wrote:
>
>
> On Apr 26, 2012, at 6:46 AM, Bean <address@hidden> wrote:
>
>> 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.
>
>  Sure!  Thanks!

Hi,

I sent it to your email yesterday but it seems the mail server blocks
binary attachment, anyway, i upload it here:

http://download.gna.org/grubutil/efitest.zip

The main program is efiload.efi, I also include edk driver snp, bc and
pxedhcp4 just in case the firmware doesn't contain them.

Loading imagefile using native tftp function:
efiload /imagename 0 1

Loading imagefile using custom tftp function
efiload /imagename 16

The third parameter here is the block size (in KB), you can set it as
large as 60, while native tftp normally support up to 8K.

-- 
Best wishes
Bean



reply via email to

[Prev in Thread] Current Thread [Next in Thread]