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. -- Best wishes Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
