Re: Boot delay due to network devices

[Laszlo Ersek <lersek@redhat.com>]

On 03/23/18 12:58, Wasim Khan wrote:
> Hi Laszlo,
> 
> I want to re-discuss this thread with you.
> 
> So as you mentioned that we can define a platform policy to connect
> to only intended devices (Say Network (PXE) and Removable Media
> devices).
> 
> But when I say boot from Network devices, we have to scan all the
> devices as all devices are legal candidate for booting.
> 
> Its only matter of setup that which network interfaces are currently
> connected via cable which can change from one setup to another setup.
> So interfaces which are not connected currently in some setup will
> waste time in auto-neg as driver's Start will be called for each
> interface instance before trying to boot starting from 1st boot
> option.
> 
> Ex: if auto-neg timeout is 5 seconds and if we have 10 network
> interfaces (all are legal candidate for booting), and cable is
> connected to 3rd interface only then 45 seconds will be wasted (5
> seconds each for 9 interfaces) in auto-neg of interfaces which are
> not connected via cable.
> 
> We want to save this time by skipping calling ConnectController
> before trying boot from available boot options starting from 1st boot
> option.
> 
> Ex: if auto-neg timeout is 5 seconds and if we have 10 network
> interfaces (all are legal candidate for booting), and cable is
> connected to 3rd interface only, then 10 seconds will be wasted (in
> auto-neg of 1st and 2nd interface) and boot will success when boot
> from 3rd interfaces is tried. Now (in same/different setup) if I
> plug-in the cable to 1st interface, boot will success in 1st attempt
> and we will not waste any time.
> 
> But as per the current implementation (PlatformBootManagerLib),
> ConnectController is called from BdsLib before trying to boot from a
> boot entry. Which looks logical to me because all ( or platform
> policy specific) drivers should be scanned to find new/update boot
> options and add their entries in BootOrder.
If you think that netboot should work (a) regardless of which NIC the
user connects to the network *and* (b) without requiring any interaction
from the user (in the firmware Setup utility), then you have to call
ConnectController() on all the possible NICs.

If at least one of (a) and (b) is permitted to be "false", then you can
call ConnectController() on the NICs selectively. You can have an HII
setup page (installed by a PlatformDxe driver, for example) that lists
ten checkboxes, one checkbox per NIC (hopefully with a label that is
visibly assignable to the physical ports). The checkbox states can be
stored in a shared non-volatile UEFI variable. You can consult that
variable in your PlatformBootManagerLib instance (generally starting
with the next boot), and only call ConnectController() on those NICs
that were selected. This can save boot time, but it also requires the
user to go into the Setup utility if they plug the cable into another port.


The management of Boot#### options is a separate step, as far as
PlatformBootManagerLib is concerned. It might make sense (in your
PlatformBootManagerLib instance) to remove the Boot#### options that
refer to NICs "foo" and "bar", if "foo" and "bar" are unchecked in your
UEFI variable. It also makes sense to call
EfiBootManagerRefreshAllBootOption() so that Boot#### options exist for
those NICs that you *did* connect.


As a reminder, some PlatformBootManagerLib instances don't even connect
various *console* devices (such as USB keyboards) in order to save boot
time, thus you can't even interrupt the fw boot process from the
keyboard. You have to use an OS facility to signal the firmware to enter
the Setup utility at the next boot.

This is just to show that there's a connection between firmware boot
time and boot (or even console) device selection by the user. The more
devices the user selects (or the more devices PlatformBootManagerLib
selects for the user), the longer the boot might take.

I apologize if I failed to clarify; I don't know what other comments I
could make.

Thanks
Laszlo