Hi! This is V2 of the series:
http://lists.gnu.org/archive/html/grub-devel/2016-04/msg00015.html with the final aim of enabling the receive buffer in the ofnet module. The first version received a number of comments: http://lists.gnu.org/archive/html/grub-devel/2016-11/msg00054.html http://lists.gnu.org/archive/html/grub-devel/2016-11/msg00057.html and I tried to address them all in this new version. Summary of changes: 1. The error check for grub_netbuff_reserve() moved into a separate patch. 2. Previously, ofnet_alloc_netbuf() and ofnet_free_netbuf() were in one patch. I decided to split this patch into two: - one is for ofnet_alloc_netbuf() - the other is for ofnet_free_netbuf() + freeing memory on module onload This looks logical. The (IEEE1275..... || args.catch) expressions were made one-line. 3. Added a patch to free the card memory on module unload 4. In the last patch in get_card_packet() I decided to follow my original proposal: + if (grub_netbuff_put (nb, actual)) { - grub_netbuff_put (nb, actual); - return nb; + grub_netbuff_free (nb); + return NULL; } - grub_netbuff_free (nb); - return NULL; + + return nb; This, in my opinion, makes the code flow to be more consistent. Each 'if' in this function checks for an error and its code block is the code to be executed when the error happens. If everything is fine we reach the final statement of the function. 5. As for the perfomance impact of the last patch in the series. On one LDOM I setup a TFTP server and put an initrd image of 1.1G size there. A different LDOM was used as a host to boot GRUB and ofnet. This LDOM had a network interface: {0} ok cd net0 {0} ok .properties local-mac-address 00 14 4f f8 a9 dd max-frame-size 00004000 address-bits 00000030 reg 00000000 compatible SUNW,sun4v-network device_type network name network {0} ok i.e. the MTU is 0x4000. The two LDOMs were located at one physical host. Both were connected to one virtual switch. The test scenario was: 1. Boot grub2 in the latter ldom 2. Execute set root=tftp,ip_of_the_former_host 3. Execute linux /vmlinuz Otherwise the 'initrd' command won't work. 4. Measure the time required for command: initrd /initrd.img to complete. This test scenario was executed when the grub2 was compiled with the last patch in the series and when it was compiled without the patch. 3 iterations for each case. In both the cases the aveage time to load the 1.1G initrd was ~68 sec. I could not perform ths test scenario on my bare-metal machines. Their network adapters have the MTU of 0x10000 and even booting of core grub2 modules, like normal.mod, results in a series of: error: out of memory. error: out of memory. error: out of memory. This is without the receive buffer. With the receive buffer booting goes fine and loading of initrd also goes fine. Thanks. _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
