public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ye, Ting" <ting.ye@intel.com>
To: "Cohen, Eugene" <eugene@hp.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Wu, Jiaxin" <jiaxin.wu@intel.com>
Subject: Re: DHCP Automatic Configure at Driver Connect
Date: Thu, 11 Aug 2016 03:03:29 +0000	[thread overview]
Message-ID: <BC0C045B0E2A584CA4575E779FA2C12A17D9B04C@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <AT5PR84MB02917CE953A461F419CC0A2EB41D0@AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM>

Hi Eugene,

Actually this is exactly the problem Samer raised to the mailing list in Aug 2015. We ever fixed it with following patch:

SHA-1: 3d0a49ad47619c30c84bbee8a33f54b64dddbcec

* MdeModulePkg: Fix issue about current Ip4Dxe implementation for DHCP DORA process

DHCP policy is applied as default at boot time on all NICs in the system, which results
in all NIC ports attempting DHCP and trying to acquire IP addresses during boot.
Ip4 driver should only set dhcp as default policy, and not trigger DORA at driver binding
start(). We should start DORA until one IP child is configured to use default address.

Later HP raised the same performance impact in IPv6 stack. We realized we couldn't use the same logic to defer DHCP6 SARR process.
Instead, we discussed the issue in spec group and we removed the restriction from UEFI specification that the default policy should be Ip4Config2PolicyDhcp or Ip6ConfigPolicyAutomatic. It's up to implementation's choice.
The EDKII implementation was later updated that the default policy was changed to Ip4Config2PolicyStatic and IP6ConfigPolicyManual. Also the previous change was reverted, in order to keep IP4/IP6 solution consistent. See patch (also reviewed by Samer):

SHA-1: 7648748e99eeeadec38fda7568adb260c4acc861

* MdeModulePkg: Change the default IPv4 config policy

Git version '3d0a49ad' commit provided a scenario to resolve the
performance issue for IPv4, but it's not workable for IPv6. To
avoid IPv4 and IPv6 inconsistency, we decided to revert that version
fix.

If so, the default policy for Ip4Config2 is Ip4Config2PolicyDhcp,
which results in all NIC ports attempting DHCP. So, this patch is
used to changes the the default IPv4 config policy to
Ip4Config2PolicyStatic and also defer the SetData operation after
Ip4Config2Protocol installed. This update let the other platform
drivers have chance to change the default config data by consume
Ip4Config2Protocol.


Current implementation recommends that the system should stay in default policy - static to not initialize DHCP process, unless the system needs to start DHCP -- it should change the policy to IP4Config2PolicyDhcp.

Best Regards,
Ye Ting


-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
Sent: Thursday, August 11, 2016 2:17 AM
To: edk2-devel@lists.01.org; Wu, Jiaxin <jiaxin.wu@intel.com>
Subject: [edk2] DHCP Automatic Configure at Driver Connect

With this commit:

Revision: 1f6729ffe98095107ce82e67a4a0209674601a90
Author: jiaxinwu <jiaxin.wu@intel.com>
Date: 7/7/2015 2:19:55 AM
Message:
MdeModulePkg: Update Ip4Dxe driver to support Ip4Config2 protocol,

a new behavior seemed to come in to the network stack that was not present before: It appears now that as soon as the DHCP Service Binding protocol is installed the DHCP process will be initiated (see Ip4Config2OnDhcp4SbInstalled).  This differs from past behavior where DHCP would only occur if a driver or application specifically did Configure() on the network interface.

For some systems this is problematic because they need to defer DHCP until it is certain that the network interface will be used for something.

Can you provide the reason for this change?  Can we have a policy (PCD) to disable this mode of operation?

Thanks,

Eugene


_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


  parent reply	other threads:[~2016-08-11  3:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-10 18:17 DHCP Automatic Configure at Driver Connect Cohen, Eugene
2016-08-11  1:50 ` Wu, Jiaxin
2016-08-11  3:03 ` Ye, Ting [this message]
2016-08-11  5:59   ` Wu, Jiaxin
2016-08-11 14:22     ` Cohen, Eugene
2016-08-11 15:20       ` Samer El Haj Mahmoud
2016-08-12  1:31       ` Wu, Jiaxin
2016-08-12 12:31         ` Cohen, Eugene
2016-08-13  2:37           ` Wu, Jiaxin
2016-08-15 14:40             ` Cohen, Eugene
2016-08-16  3:05               ` Wu, Jiaxin
2016-08-16 19:41                 ` Cohen, Eugene
2016-08-17  5:50                   ` Wu, Jiaxin
2016-08-17 12:17                     ` Cohen, Eugene
2016-08-18  2:48                       ` Wu, Jiaxin
2016-08-18  3:10                         ` Ye, Ting
2016-08-18 14:30                           ` Cohen, Eugene
2016-08-16  1:14       ` Ye, Ting
2016-08-16 19:19         ` Cohen, Eugene

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=BC0C045B0E2A584CA4575E779FA2C12A17D9B04C@SHSMSX103.ccr.corp.intel.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