From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::724]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4DA5D1A1DF5 for ; Thu, 11 Aug 2016 07:22:54 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0292.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 14:22:50 +0000 Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) with mapi id 15.01.0549.025; Thu, 11 Aug 2016 14:22:50 +0000 From: "Cohen, Eugene" To: "Wu, Jiaxin" , "Ye, Ting" , "edk2-devel@lists.01.org" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8A== Date: Thu, 11 Aug 2016 14:22:50 +0000 Message-ID: References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eugene@hp.com; x-originating-ip: [15.65.254.4] x-ms-office365-filtering-correlation-id: 02d9a44f-a2b0-4bd8-9671-08d3c1f2f9f4 x-microsoft-exchange-diagnostics: 1; AT5PR84MB0292; 6:l1O6jgjZGCuL1Ildjja5chNtzhsB3OqP1vbka6W5+MlwXXzxU/1jWK5ZJ26puQNv9NfRK62jAZKydBz0miqOH3vQbMk90+Xkg/7UO7VQr48AiHzUQCncXFUpcyMkR8e36iXFZE1n/82kUhTj5s2Mx5UhcvtjBVaIa89z5TeMPNf3Yh4q45w4R//HINaZvXEho/CeplvvovLf30zjqwWbOYX6BYol3B88i3jQA+BboduCxvGdFlpgMIzLdUMq9lkbJX5Zid+DKvTWD0UCqh8qL9nqbNwTw077vsSO2EDsJL0=; 5:WF5gQWLpoCch/czZ6uMRjebq/McaI6UNvfnH1acqvvuqaCF2M/tSHPDLATBEsuf3GQp/FSfHtv6aW4vn2QcQLt/wDzC79EJB7wxj2WMNSjZQ2MLhQaKVBS7Q50qqmpW9jcLgQXeHtGmgjvXNXWdzBw==; 24:1F67+O3wE/f63iNcb626F3/hD0di1kWDJulWvaZg1HqQEu9e8qchGcrqRZtgfixStyAY5Rmp0o4v9i3e19Y15pMBOSR7iVipgDd0BoHdE54=; 7:pJKerbzAlxU9Q6MxVmeG12HF0miJ0QUBz5xVQ12vlPoO7gFDaNOUQxdhrVvID0RDBqMfBXPaRYKISamw1NRARVaC9m1RiPswDn+S7/QU0fN8WQ6pHMHTMx7TL1cphC7DpB6gOmH8QcljjUgGL7BfteDDUuRciRwxGXiSUDZsi4Znxci/7c2rvJ3O7rStK3Z5374YryeyrCg5pI8wlDWkR8vlgf2nzkMalHyq+ikfAiOTKDtYbCk/H1m6LmdYVWSI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(162533806227266)(21532816269658)(228905959029699)(73583498263828); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AT5PR84MB0292; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0292; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(189002)(6602003)(74316002)(81166006)(7846002)(3846002)(8936002)(81156014)(305945005)(68736007)(7696003)(2501003)(8676002)(5002640100001)(92566002)(66066001)(77096005)(6116002)(586003)(102836003)(189998001)(2900100001)(7736002)(122556002)(15975445007)(2950100001)(2906002)(3660700001)(9686002)(105586002)(3900700001)(107886002)(97736004)(11100500001)(5001770100001)(87936001)(106356001)(10400500002)(99286002)(101416001)(33656002)(86362001)(50986999)(54356999)(76176999)(19580405001)(575784001)(3280700002)(19580395003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0292; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 14:22:50.7953 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0292 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: Thu, 11 Aug 2016 14:22:54 -0000 Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 ; > 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 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. >=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 > Ip4Config behavior. The version 3d0a49ad did was trying to resolve the > 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 list i= n > 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