[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[V2] Implementing the receive buffer for ofnet

From: Stanislav Kholmanskikh
Subject: [V2] Implementing the receive buffer for ofnet
Date: Fri, 2 Dec 2016 18:10:01 +0300


This is V2 of the series:

with the final aim of enabling the receive buffer in the ofnet module.

The first version received a number of comments:

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

+  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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]