From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=40.107.1.57; helo=eur02-he1-obe.outbound.protection.outlook.com; envelope-from=wasim.khan@nxp.com; receiver=edk2-devel@lists.01.org Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10057.outbound.protection.outlook.com [40.107.1.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B1BC9223E0BA4 for ; Fri, 23 Mar 2018 04:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pEBxJEJrA4V/vVrUfI12E+u6BSjxGPbidSjO0bfOQM8=; b=CFyls8zgazXQtFRuWBDC02msZNeYGsBf9t+owGAW9LBY1PwbMzkvB/eAYBRkobJreGfuFVqEhuaAd2ZRMxdLZLFu5Q46F8o1AYRSC0Btlm5jZh7d0eCOedqZmbfaMkhk2vZCIQ2iT6uuuKkj3bhtaI3mCNCbFItAt50z25+7u5M= Received: from HE1PR0401MB2346.eurprd04.prod.outlook.com (10.168.32.153) by HE1PR0401MB2057.eurprd04.prod.outlook.com (10.166.123.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Fri, 23 Mar 2018 11:58:44 +0000 Received: from HE1PR0401MB2346.eurprd04.prod.outlook.com ([fe80::80d8:4751:51e5:95e3]) by HE1PR0401MB2346.eurprd04.prod.outlook.com ([fe80::80d8:4751:51e5:95e3%18]) with mapi id 15.20.0609.012; Fri, 23 Mar 2018 11:58:44 +0000 From: Wasim Khan To: Laszlo Ersek , Pankaj Bansal CC: "edk2-devel@lists.01.org" , Udit Kumar Thread-Topic: [edk2] Boot delay due to network devices Thread-Index: AdM+gW50TnWphq2DTISXvDd93ELcUgABsAEAAAI1TIAABNkrgCDx4UWA Date: Fri, 23 Mar 2018 11:58:44 +0000 Message-ID: References: <65ceafe9-5cb2-6642-f3d0-71f37b020937@redhat.com> <8c4e2221-3f0f-e1f8-be40-9c18fa886be9@redhat.com> In-Reply-To: <8c4e2221-3f0f-e1f8-be40-9c18fa886be9@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wasim.khan@nxp.com; x-originating-ip: [14.142.187.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0401MB2057; 7:cIL4ly5boirbaLo0+1bx7bA7NuzoDQmNpZPWdccwqEs2Ew7FUZvpjRwVvsyP+1+5G88OEIPtUUI16OuMUlCpAuZVfds9dkPih+Rtsro3lmL6j+zx/yRT/BIaEqolJzv6Y76Uz+CPC0a06hBPhGVsyIxFgK2QI5PHNw5Z2T0OgCtULpSNne+kdgCEMOi9jpLiC9waXmRZVd22eCIpfIa09DuyBSb6+3TFz4v+yyRXStOd8sM94Rq/c+qWc47ZmTZa x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ca51732d-b759-42d8-749d-08d590b56db6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0401MB2057; x-ms-traffictypediagnostic: HE1PR0401MB2057: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197)(788757137089)(162533806227266)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0401MB2057; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0401MB2057; x-forefront-prvs: 0620CADDF3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(396003)(366004)(39860400002)(376002)(13464003)(199004)(189003)(966005)(74316002)(14454004)(4326008)(6436002)(53936002)(3280700002)(25786009)(7736002)(55016002)(2906002)(9686003)(6306002)(66066001)(316002)(5250100002)(5660300001)(2900100001)(3846002)(6116002)(478600001)(3660700001)(93886005)(110136005)(54906003)(305945005)(59450400001)(97736004)(81166006)(81156014)(8676002)(8936002)(55236004)(53546011)(68736007)(86362001)(33656002)(345774005)(105586002)(106356001)(102836004)(26005)(6246003)(99286004)(6636002)(76176011)(7696005)(11346002)(446003)(229853002)(186003)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0401MB2057; H:HE1PR0401MB2346.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: X1Pj7ebK/AKLuqYTeF2rT9krxsholQ7EwoIsxO3g7LytbDxRoILVJuCq2FZcBHlR431PGGDISS5ntTI8HMRIqvPrw/8G2N9MrPTmmliRpH9yQWxx38+q0Ht29aIxw34AUCuhl6m36WAak46VDmcNDo5j0WRvW+vF8BkqWsSaUigq7vIqRiQrHX/HJTQt8qtHHPHJW+CMlg9yKUynJx6FHycsHE8B0rzPynAv8tQfZNzqtHMamjlrmB14mkAPWUHuI6MrYYxDj4HS4ikBwZXCetYVJh03mw7XwyXI1Wfb2BxImmGfWNxZmF7Fn/PsIW+UbwlmG5jP4aipTrRZwBcH1Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca51732d-b759-42d8-749d-08d590b56db6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2018 11:58:44.5697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0401MB2057 Subject: Re: Boot delay due to network devices X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 11:52:23 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 a= s all devices are legal candidate for booting.=20 Its only matter of setup that which network interfaces are currently connec= ted via cable which can change from one setup to another setup. So interfac= es 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 try= ing 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 interfa= ce 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 tryi= ng boot from available boot options starting from 1st boot option.=20 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 interfa= ce only, then 10 seconds will be wasted (in auto-neg of 1st and 2nd interfa= ce) and boot will success when boot from 3rd interfaces is tried.=20 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), ConnectCont= roller is called from BdsLib before trying to boot from a boot entry. Which= looks logical to me because all ( or platform policy specific) drivers sho= uld be scanned to find new/update boot options and add their entries in Boo= tOrder. Regards, Wasim > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of La= szlo > Ersek > Sent: Friday, October 06, 2017 6:40 PM > To: Pankaj Bansal > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] Boot delay due to network devices >=20 > 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 booti= ng > the kernel. > > We do not know which one of the eight devices, would be connected to > network when system is in use. >=20 > Sure; the user of the system should configure the NIC used for booting in= the > Setup utility. >=20 >=20 > > Moreover network configuration can be changed, when the system is runni= ng. > 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. >=20 > 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. >=20 > 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 en= tered -- > because otherwise the user can't even interrupt the boot process (with th= e USB > keyboard not being connectd). >=20 > 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). >=20 >=20 > > However the network device initialization (Snp->Initialize) expects the= link > status of network device to be updated after phy auto negotiation. >=20 > (IMO this is a separate topic.) >=20 > 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). >=20 >=20 > > 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. >=20 > I don't understand why. >=20 > (1) If you try to determine the link status in DriverBindingStart(), then= the delay is > only present if BDS calls ConnectController() on the NIC. >=20 > So, don't connect the NIC indiscriminately. >=20 >=20 > (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 on= ly connect > the NIC in BDS, but connect it *recursively*. >=20 > This is because in practice, SNP.Start() and SNP.Initialize() are only ca= lled by > higher level network drivers (MnpDxe, namely). >=20 > So, assuming you connect the NIC in BDS, then at least don't connect it > recursively. >=20 >=20 > > Can we attempt phy auto negotiation for only those network devices, > > which we will be using for booting (or for any network activity for tha= t matter) > In other words for only those devices, for which we will be calling Snp->= Transmit > and Snp->Receive functions? >=20 > A call to SNP.Initialize() means that the caller intends to transmit and = receive on > the NIC. >=20 > Furthermore, after SNP.Initialize() returns, the caller is definitely all= owed to call > SNP.GetStatus() -- without ever having called Transmit() or Receive() -- = and look > at MediaPresent right after (assuming MediaPresentSupported is TRUE). >=20 >=20 > Thus, in my opinion, you shouldn't try to determine the link status in la= ter and > later stages of SNP usage. Instead, it should be done as early as possibl= e (no > later than SNP.Start()); and your PlatformBootManagerLib instance should = be a > lot more selective regarding the NICs that it connects. >=20 > 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 HO= B, > 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 total= ly > frugal considering the devices it connects. IIRC, UefiBootManagerLib / Bd= sDxe > will connect any device that underlies the currently attempted Boot#### o= ption, > so IMO it's possible that you don't have to connect *any* NICs in > PlatformBootManagerLib, explicitly. >=20 > 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 generate= d for all > bootable devices (so you can establish a new boot order). This does take = long, > but it does not happen for normal boots. >=20 > Thanks, > Laszlo >=20 > > -----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 netwo= rk 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 driv= er waits > for auto negotiation to complete for maximum of 5 seconds. > >> For each network device that is not connected, the system spends 5 sec= onds > 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 d= uring > 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 > > >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel