From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ml01.01.org (Postfix) with ESMTP id D1B2E1A1E0F for ; Mon, 15 Aug 2016 18:14:19 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 15 Aug 2016 18:14:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,527,1464678000"; d="scan'208";a="865980719" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 15 Aug 2016 18:14:21 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 15 Aug 2016 18:14:18 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 15 Aug 2016 18:14:18 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.181]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.150]) with mapi id 14.03.0248.002; Tue, 16 Aug 2016 09:14:16 +0800 From: "Ye, Ting" To: "Cohen, Eugene" , "Wu, Jiaxin" , "edk2-devel@lists.01.org" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8ADgbmcw Date: Tue, 16 Aug 2016 01:14:16 +0000 Message-ID: References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: DHCP Automatic Configure at Driver Connect X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 01:14:20 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eugene, I think we need fully understand your usage before analyzing the problem. C= ould you please explain more details? You mentioned you only wanted to enab= le the network interface when directed by an application. If so, is it poss= ible that you don't connect your network device until you really need that?= =20 Thanks, Ting -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohe= n, Eugene Sent: Thursday, August 11, 2016 10:23 PM To: Wu, Jiaxin ; Ye, Ting ; edk2-de= vel@lists.01.org Subject: Re: [edk2] DHCP Automatic Configure at Driver Connect Ting and Jiaxin, thank you both for clarifying. In our situation DHCP is being set on a previous boot and we are now observ= ing DHCP being attempted on every boot (since the controllers are connected= ). So this is consistent with the behavior you describe - even though the = default was originally static/manual the fact that we configured DHCP once = causes this to be stored to NVRAM and perform dhcp process at every boot. The issue is not just a performance issue around DHCP timing. Even with a = static IP address set the fact that the network interface comes "up" at eac= h boot is problematic because our requirement is only to enable the network= interface when directed to by an application. Modifying the IP configuration dynamically to suppress the interface coming= up at every boot is also problematic because it means we would need to sto= re the IP address configuration in another NVRAM location. In other words,= the combining of the IP address settings storage *and* the policy of wheth= er to configure at boot or wait until explicitly requested is problematic -= we really would like to control these settings independently. Is that pos= sible within the scope of the spec? Could we just have a PCD that suppress= es the automatic configure at boot under any circumstance? Thanks, Eugene > -----Original Message----- > From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com] > Sent: Thursday, August 11, 2016 12:00 AM > To: Ye, Ting ; Cohen, Eugene ;=20 > edk2-devel@lists.01.org > Subject: RE: DHCP Automatic Configure at Driver Connect >=20 > Thanks Ting's more background clarification. >=20 > I assume the difference you mentioned is between "SHA-1: > 3d0a49ad47619c30c84bbee8a33f54b64dddbcec" and "SHA-1: > 7648748e99eeeadec38fda7568adb260c4acc861". The two commits does cause=20 > the different behavior as Ting said below. Git version 3d0a49ad will=20 > only set the policy to dhcp but don't trigger D.O.R.A while 7648748e=20 > always trigger D.O.R.A if policy is DHCP. >=20 > Version 7648748e commit is also the current behavior of Ip4Config2: > DHCP policy together with D.O.R.A process, which is similar to the old=20 > Ip4Config behavior. The version 3d0a49ad did was trying to resolve the=20 > Ip4Dxe performance but it's not workable for IPv6, so we reverted it. >=20 > Thanks, > Jiaxin >=20 > > -----Original Message----- > > From: Ye, Ting > > Sent: Thursday, August 11, 2016 11:03 AM > > To: Cohen, Eugene ; edk2-devel@lists.01.org; > Wu, Jiaxin > > > > Subject: RE: DHCP Automatic Configure at Driver Connect > > > > Hi Eugene, > > > > Actually this is exactly the problem Samer raised to the mailing=20 > > 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=20 > > restriction from UEFI specification that the default policy should=20 > > be Ip4Config2PolicyDhcp or Ip6ConfigPolicyAutomatic. It's up to=20 > > 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=20 > > 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,=20 > > which > results > > in all NIC ports attempting DHCP. So, this patch is used to changes=20 > > the > the > > default IPv4 config policy to Ip4Config2PolicyStatic and also defer=20 > > 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=20 > > 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 > > Subject: [edk2] DHCP Automatic Configure at Driver Connect > > > > With this commit: > > > > Revision: 1f6729ffe98095107ce82e67a4a0209674601a90 > > Author: jiaxinwu > > 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=20 > > Ip4Config2OnDhcp4SbInstalled). This differs from past behavior > where DHCP > > would only occur if a driver or application specifically did=20 > > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel