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 CBE79223E0B98 for ; Fri, 23 Mar 2018 07:22:11 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A5284070212; Fri, 23 Mar 2018 14:28:44 +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 8AF752166BAE; Fri, 23 Mar 2018 14:28:43 +0000 (UTC) To: Wasim Khan , Michael Brown Cc: "edk2-devel@lists.01.org" References: <65ceafe9-5cb2-6642-f3d0-71f37b020937@redhat.com> <8c4e2221-3f0f-e1f8-be40-9c18fa886be9@redhat.com> From: Laszlo Ersek Message-ID: <637459c8-5d53-ba09-687a-7e463981e978@redhat.com> Date: Fri, 23 Mar 2018 15:28:42 +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.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 23 Mar 2018 14:28:44 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 23 Mar 2018 14:28:44 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.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 14:22:12 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 ; Laszlo Ersek ; >> Pankaj Bansal >> 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