public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Wasim Khan <wasim.khan@nxp.com>, Michael Brown <mcb30@ipxe.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: Boot delay due to network devices
Date: Fri, 23 Mar 2018 15:28:42 +0100	[thread overview]
Message-ID: <637459c8-5d53-ba09-687a-7e463981e978@redhat.com> (raw)
In-Reply-To: <HE1PR0401MB23467D044714B21F4B4D056C90A80@HE1PR0401MB2346.eurprd04.prod.outlook.com>

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 <wasim.khan@nxp.com>; Laszlo Ersek <lersek@redhat.com>;
>> Pankaj Bansal <pankaj.bansal@nxp.com>
>> 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



  reply	other threads:[~2018-03-23 14:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06  9:23 Boot delay due to network devices Pankaj Bansal
2017-10-06  9:47 ` Laszlo Ersek
2017-10-06 11:07   ` Pankaj Bansal
2017-10-06 13:09     ` Laszlo Ersek
2018-03-23 11:58       ` Wasim Khan
2018-03-23 12:22         ` Michael Brown
2018-03-23 13:01           ` Wasim Khan
2018-03-23 14:28             ` Laszlo Ersek [this message]
2018-03-23 14:02         ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=637459c8-5d53-ba09-687a-7e463981e978@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox