From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B154921EA15C5 for ; Fri, 6 Oct 2017 06:06:36 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D146847A; Fri, 6 Oct 2017 13:09:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D146847A Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-219.rdu2.redhat.com [10.10.120.219]) by smtp.corp.redhat.com (Postfix) with ESMTP id EC6646F12D; Fri, 6 Oct 2017 13:09:58 +0000 (UTC) To: Pankaj Bansal Cc: "edk2-devel@lists.01.org" References: <65ceafe9-5cb2-6642-f3d0-71f37b020937@redhat.com> From: Laszlo Ersek Message-ID: <8c4e2221-3f0f-e1f8-be40-9c18fa886be9@redhat.com> Date: Fri, 6 Oct 2017 15:09:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 06 Oct 2017 13:09:59 +0000 (UTC) Subject: Re: Boot delay due to network devices X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 13:06:36 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 > 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 >