From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 03BBE223E0B90 for ; Fri, 23 Mar 2018 06:55:43 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BE9B677068; Fri, 23 Mar 2018 14:02:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-180.rdu2.redhat.com [10.10.120.180]) by smtp.corp.redhat.com (Postfix) with ESMTP id DC7F310B2B26; Fri, 23 Mar 2018 14:02:14 +0000 (UTC) To: Wasim Khan , Pankaj Bansal Cc: "edk2-devel@lists.01.org" , Udit Kumar References: <65ceafe9-5cb2-6642-f3d0-71f37b020937@redhat.com> <8c4e2221-3f0f-e1f8-be40-9c18fa886be9@redhat.com> From: Laszlo Ersek Message-ID: <011a56bd-b05d-9695-f898-7ecf537b6c01@redhat.com> Date: Fri, 23 Mar 2018 15:02:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 23 Mar 2018 14:02:15 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 23 Mar 2018 14:02:15 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' 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 13:55:44 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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