Boot delay due to network devices

Boot delay due to network devices

[Pankaj Bansal]

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 ?

Thanks & Regards,
Pankaj Bansal

Re: Boot delay due to network devices

[Laszlo Ersek]

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

Re: Boot delay due to network devices

[Pankaj Bansal]

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.
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.

However the network device initialization (Snp->Initialize) expects the link status of network device to be updated after phy auto negotiation.
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.
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?

Thanks & Regards,
Pankaj Bansal

-----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

Re: Boot delay due to network devices

[Laszlo Ersek]

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
> 

Re: Boot delay due to network devices

[Wasim Khan]

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.


Regards,
Wasim


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Friday, October 06, 2017 6:40 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 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
> >
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: Boot delay due to network devices

[Michael Brown]

On 23/03/18 11:58, Wasim Khan wrote:
> 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.

There is no need for drivers to block in the Start() method waiting for 
link-up detection.  Link detection can happen entirely asynchronously, 
thereby reducing your wasted time from 45 seconds to zero.

Michael

Re: Boot delay due to network devices

[Wasim Khan]

Hi Michael,

Thank you for your prompt reply. 

Yes, in one of our implementation we are doing the same in our network driver (without DriverBinding protocol support).

We were thinking to update our network driver to support DriverBinding Protocol and explore if we can get a boot call for boot options one by one starting from 1st boot option.
If making the auto-neg asynchronous is the only option, then we don’t see any profit by updating our network driver to support DriverBinding protocol.


Regards,
Wasim

> -----Original Message-----
> From: Michael Brown [mailto:mcb30@ipxe.org]
> Sent: Friday, March 23, 2018 5:52 PM
> To: Wasim Khan <wasim.khan@nxp.com>; Laszlo Ersek <lersek@redhat.com>;
> Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Boot delay due to network devices
> 
> On 23/03/18 11:58, Wasim Khan wrote:
> > 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.
> 
> There is no need for drivers to block in the Start() method waiting for link-up
> detection.  Link detection can happen entirely asynchronously, thereby reducing
> your wasted time from 45 seconds to zero.
> 
> Michael

Re: Boot delay due to network devices

[Laszlo Ersek]

On 03/23/18 14:01, Wasim Khan wrote:
> Hi Michael,
> 
> Thank you for your prompt reply. 
> 
> Yes, in one of our implementation we are doing the same in our network driver (without DriverBinding protocol support).
> 
> We were thinking to update our network driver to support DriverBinding Protocol and explore if we can get a boot call for boot options one by one starting from 1st boot option.
> If making the auto-neg asynchronous is the only option, then we don’t see any profit by updating our network driver to support DriverBinding protocol.

The point of a UEFI device driver that follows the UEFI driver model is
that platform BDS may elect *not* to connect the driver to various
devices. This is unlike your DXE driver that probably binds all of the
devices immediately at dispatch.

In order to benefit from the flexibility of the above UEFI drivers, your
platform BDS must actually be *capable* of not calling
ConnectController() on those devices that you don't intend to boot off of.

How about this: simply don't connect *any* NICs -- either via
EfiBootManagerConnectAll() or EfiBootManagerConnectDevicePath() -- in
your PlatformBootManagerLib. When a Boot#### option is being booted, the
core UefiBootManagerLib / BdsDxe driver should connect the device
automatically.

- When the user enters the Setup utility, all devices are automatically
connected with EfiBootManagerConnectAll().

- This way Boot#### options can be created by the user, simply by
pointing to / selecting some devices. (Because all devices have been
connected.)

- At next boot, the user doesn't enter Setup, and your
PlatformBootManagerLib doesn't connect any boot devices explicitly
(NICs, disks, etc); only consoles.

- Boot#### processing will take care of connecting boot devices,
strictly as necessary.

- If the user plugs the ethernet cable into another NIC, they'll have to
enter Setup again, and update their Boot#### options.

Thanks
Laszlo

>> -----Original Message-----
>> From: Michael Brown [mailto:mcb30@ipxe.org]
>> Sent: Friday, March 23, 2018 5:52 PM
>> To: Wasim Khan <wasim.khan@nxp.com>; Laszlo Ersek <lersek@redhat.com>;
>> Pankaj Bansal <pankaj.bansal@nxp.com>
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] Boot delay due to network devices
>>
>> On 23/03/18 11:58, Wasim Khan wrote:
>>> 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.
>>
>> There is no need for drivers to block in the Start() method waiting for link-up
>> detection.  Link detection can happen entirely asynchronously, thereby reducing
>> your wasted time from 45 seconds to zero.
>>
>> Michael

Re: Boot delay due to network devices

[Laszlo Ersek]

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