Re: Boot delay due to network devices

[Wasim Khan <wasim.khan@nxp.com>]

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