Re: Boot delay due to network devices

[Laszlo Ersek <lersek@redhat.com>]

On 10/06/17 13:07, Pankaj Bansal wrote:
> Hi Laszlo,
> 
> Thank you for your prompt reply.
> But it's not like that we do not want to boot from network device ever.
> We have eight network devices, out of which one would be used for booting the kernel.
> We do not know which one of the eight devices, would be connected to network when system is in use.

Sure; the user of the system should configure the NIC used for booting
in the Setup utility.


> Moreover network configuration can be changed, when the system is running. i.e. we can disconnect one device and connect other and try to boot from it.
> Therefore we need to initialize all the network devices.

I disagree; if the hardware configuration (or the environment of the
hardware) changes, then the user may be expected to tweak the firmware
configuration in the Setup utility.

Some systems don't even enable the USB keyboard during boot (for the
sake of fast boot), and the OS or the boot loader offer an option to set
the OsIndications UEFI variable, so that at next boot the Setup utility
be entered -- because otherwise the user can't even interrupt the boot
process (with the USB keyboard not being connectd).

Your use case is also similar to a configuration where a DVD-ROM drive
is generally not connected during boot (again in the name of speed), but
now the user wants to boot a DVD-ROM. They have to enter Setup and
change the configuration (add a new Boot#### option).


> However the network device initialization (Snp->Initialize) expects the link status of network device to be updated after phy auto negotiation.

(IMO this is a separate topic.)

I think once a NIC is connected, the MediaPresentSupported, MediaPresent
and CurrentAddress fields in EFI_SIMPLE_NETWORK_MODE may be expected to
contain valid values before Initialize() is called (e.g., right after
the NIC is connected, or after Start() is called).


> For devices which are not connected to network, this will result in phy auto negotiation timeout after 5 seconds.
> I want to reduce this delay.

I don't understand why.

(1) If you try to determine the link status in DriverBindingStart(),
then the delay is only present if BDS calls ConnectController() on the NIC.

So, don't connect the NIC indiscriminately.


(2) If you determine the link status in SNP.Start(), or -- which I think
might be too late -- in SNP.Initialize(), then the delay is only present
if you not only connect the NIC in BDS, but connect it *recursively*.

This is because in practice, SNP.Start() and SNP.Initialize() are only
called by higher level network drivers (MnpDxe, namely).

So, assuming you connect the NIC in BDS, then at least don't connect it
recursively.


> Can we attempt phy auto negotiation for only those network devices, which we will be using for booting (or for any network activity for that matter)
> In other words for only those devices, for which we will be calling Snp->Transmit and Snp->Receive functions?

A call to SNP.Initialize() means that the caller intends to transmit and
receive on the NIC.

Furthermore, after SNP.Initialize() returns, the caller is definitely
allowed to call SNP.GetStatus() -- without ever having called Transmit()
or Receive() -- and look at MediaPresent right after (assuming
MediaPresentSupported is TRUE).


Thus, in my opinion, you shouldn't try to determine the link status in
later and later stages of SNP usage. Instead, it should be done as early
as possible (no later than SNP.Start()); and your PlatformBootManagerLib
instance should be a lot more selective regarding the NICs that it connects.

The PI spec defines a number of boot modes (see "10 Boot Paths" in
Volume 1 of PI-1.6); you may have a platform-specific PEIM that sets the
Boot Mode HOB, and then PlatformBootManagerLib can decide what devices
it should connect automatically. But, even if you only support one boot
mode (i.e., there's no way to distinguish different boot paths),
PlatformBootManagerLib can be totally frugal considering the devices it
connects. IIRC, UefiBootManagerLib / BdsDxe will connect any device that
underlies the currently attempted Boot#### option, so IMO it's possible
that you don't have to connect *any* NICs in PlatformBootManagerLib,
explicitly.

Now, if you enter the Setup utility, then *all* devices will be
connected (at least if you use edk2's UiApp as setup), plus Boot####
options will be generated for all bootable devices (so you can establish
a new boot order). This does take long, but it does not happen for
normal boots.

Thanks,
Laszlo

> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com] 
> Sent: Friday, October 06, 2017 3:18 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Boot delay due to network devices
> 
> On 10/06/17 11:23, Pankaj Bansal wrote:
>> Hello edk2 team,
>>
>> We are getting boot time delay in edk2 in our armv8 based platform due to network devices.
>> We have implemented the network device drivers in our platform as SNP device drivers.
>> We have total of eight network interfaces (eight SNP protocols).
>> Out of eight only one or two network interfaces are connected to network at a time; rest are disconnected.
>> When we boot the system then all the devices are detected (Snp->Start) and initialized (Snp->Initialize).
>> During Snp->Initialize(), the phy auto negotiation is started and driver waits for auto negotiation to complete for maximum of 5 seconds.
>> For each network device that is not connected, the system spends 5 seconds before exiting out of Initialize.
>>
>> We don't want to use these network devices for boot, still the time is being spent to check their status.
>> Is there some way we can skip this delay due to phy auto negotiation during boot ?
>> If I move phy auto negotiation to Snp->Transmit and Snp->Receive, will this violate the SNP protocol guidelines ?
> 
> Do not connect the devices that you don't intend to boot off of -- avoid calling gBS->ConnectController() on them. (Equivalently, don't call
> EfiBootManagerConnectXxx() functions from  UefiBootManagerLib that result in such gBS->ConnectController() calls internally.)
> 
> What devices are connected at boot is platform policy, implemented in the platform's PlatformBootManagerLib instance. In your PlatformBootManagerLib instance, you probably call
> EfiBootManagerConnectAll() somewhere.
> 
> Replace it with various, more specific, EfiBootManagerConnectXxx() calls, as appropriate, from
> "MdeModulePkg/Include/Library/UefiBootManagerLib.h":
> 
> - EfiBootManagerConnectDevicePath()
> - EfiBootManagerConnectAllDefaultConsoles()
> - EfiBootManagerConnectConsoleVariable()
> - EfiBootManagerConnectVideoController()
> 
> Thanks
> Laszlo
>