[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour
From: |
Seth Goldberg |
Subject: |
Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour |
Date: |
Thu, 26 Apr 2012 12:10:00 -0500 |
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!
--S
>
> --
> Best wishes
> Bean
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, (continued)
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Bean, 2012/04/25
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Vladimir 'φ-coder/phcoder' Serbinenko, 2012/04/25
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Bean, 2012/04/25
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Seth Goldberg, 2012/04/26
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Bean, 2012/04/26
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Seth Goldberg, 2012/04/26
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Bean, 2012/04/26
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour,
Seth Goldberg <=
- Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour, Bean, 2012/04/26