From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ml01.01.org (Postfix) with ESMTP id 433111A1DEB for ; Thu, 11 Aug 2016 18:32:00 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP; 11 Aug 2016 18:32:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,507,1464678000"; d="scan'208";a="154559545" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 11 Aug 2016 18:32:00 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 11 Aug 2016 18:31:59 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.181]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.116]) with mapi id 14.03.0248.002; Fri, 12 Aug 2016 09:31:57 +0800 From: "Wu, Jiaxin" To: "Cohen, Eugene" , "Ye, Ting" , "edk2-devel@lists.01.org" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hg Date: Fri, 12 Aug 2016 01:31:57 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B7274137C63EC@SHSMSX103.ccr.corp.intel.com> References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTg1YTQ4MzgtZjM5ZC00OGQ5LWE0ZTktODAxZGE3MGY1OTJkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImxUbGJiN1BhMjBaWCtQK1cxendaU0RcL0UrS1pqaEYzdytTYUNQd005YVBnPSJ9 x-ctpclassification: CTP_IC 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: Fri, 12 Aug 2016 01:32:00 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > In our situation DHCP is being set on a previous boot and we are now > observing 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 configur= ed > DHCP once causes this to be stored to NVRAM and perform dhcp process at > every boot. Yes, that's because you have changed the policy to DHCP. >=20 > 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 e= ach > boot is problematic because our requirement is only to enable the network > interface when directed to by an application. In my memory, we only talked about the performance issue before. Here, I un= derstand your requirement: 1) The network interface should be in *un-config= ured* status at each boot time until the third part configuration; 2) the p= olicy setting should be ignored, right? I don't think it's reasonable. I kn= ow the old Ip4Config did as you said here, but currently, the IPv4 default = policy concept is new enrolled by Ip4Config2 protocol, the device policy sh= ould be in one state no matter static or DHCP.=20 >=20 > Modifying the IP configuration dynamically to suppress the interface comi= ng > up at every boot is also problematic because it means we would need to st= ore > the IP address configuration in another NVRAM location. In other words, = the > combining of the IP address settings storage *and* the policy of whether = to > configure at boot or wait until explicitly requested is problematic - we = really > would like to control these settings independently. Is that possible wit= hin the > scope of the spec? Could we just have a PCD that suppresses the automati= c > configure at boot under any circumstance? Actually, if you want to recover the Ipv4 setting to the *un-configured* st= atus (Note here: policy should be always set, *un-configured* means no IP a= ddress configuration), Ip4Config2 provide the ability to change the default= policy. As git commit version SHA-1: 7648748e99eeeadec38fda7568adb260c4acc= 861 described, "This update let the other platform drivers have chance to c= hange the default config data by consume Ip4Config2Protocol. " So, you don= 't need to set another NVRAM location to do that, that means additional DXE= _DRIVER can add in your platform ahead to change the default config data. T= he only operation in this DXE_DRIVER is to register a notify for Ip4Config2= protocol to change the default policy. That's also the reason why we don't= want to enroll PCD to change it, you know two interface to do the same thi= ng is not a good idea. =20 Thanks, Jiaxin > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Cohen, Eugene > Sent: Thursday, August 11, 2016 10:23 PM > To: Wu, Jiaxin ; Ye, Ting ; edk2- > devel@lists.01.org > Subject: Re: [edk2] DHCP Automatic Configure at Driver Connect >=20 > Ting and Jiaxin, thank you both for clarifying. >=20 > In our situation DHCP is being set on a previous boot and we are now > observing 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 configur= ed > DHCP once causes this to be stored to NVRAM and perform dhcp process at > every boot. >=20 > 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 e= ach > boot is problematic because our requirement is only to enable the network > interface when directed to by an application. >=20 > Modifying the IP configuration dynamically to suppress the interface comi= ng > up at every boot is also problematic because it means we would need to st= ore > the IP address configuration in another NVRAM location. In other words, = the > combining of the IP address settings storage *and* the policy of whether = to > configure at boot or wait until explicitly requested is problematic - we = really > would like to control these settings independently. Is that possible wit= hin the > scope of the spec? Could we just have a PCD that suppresses the automati= c > configure at boot under any circumstance? >=20 > Thanks, >=20 > Eugene >=20 > > -----Original Message----- > > From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com] > > Sent: Thursday, August 11, 2016 12:00 AM > > To: Ye, Ting ; Cohen, Eugene ; > > edk2-devel@lists.01.org > > Subject: RE: DHCP Automatic Configure at Driver Connect > > > > Thanks Ting's more background clarification. > > > > I assume the difference you mentioned is between "SHA-1: > > 3d0a49ad47619c30c84bbee8a33f54b64dddbcec" and "SHA-1: > > 7648748e99eeeadec38fda7568adb260c4acc861". The two commits does > cause > > the different behavior as Ting said below. Git version 3d0a49ad will > > only set the policy to dhcp but don't trigger D.O.R.A while 7648748e > > always trigger D.O.R.A if policy is DHCP. > > > > 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 > > Ip4Config behavior. The version 3d0a49ad did was trying to resolve the > > Ip4Dxe performance but it's not workable for IPv6, so we reverted it. > > > > Thanks, > > Jiaxin > > > > > -----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 > > > 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 > > > 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 > > > 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 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel