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