On Fri, Apr 27, 2012 at 1:10 AM, Seth Goldberg <seth.goldb...@oracle.com> wrote: > > > On Apr 26, 2012, at 6:46 AM, Bean <bean12...@gmail.com> wrote: > >> On Thu, Apr 26, 2012 at 12:59 PM, Seth Goldberg >> <seth.goldb...@oracle.com> wrote: >>> >>> >>> On Apr 25, 2012, at 11:22 PM, Bean <bean12...@gmail.com> wrote: >>> >>>> On Thu, Apr 26, 2012 at 12:10 PM, Seth Goldberg >>>> <seth.goldb...@oracle.com> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
