From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2FC561A1DF5 for ; Thu, 11 Aug 2016 08:20:44 -0700 (PDT) Received: from [216.82.249.35] by server-16.bemta-12.messagelabs.com id 41/E8-14081-BC79CA75; Thu, 11 Aug 2016 15:20:43 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRWlGSWpSXmKPExsWS8eIhk+6p6Wv CDe78MbHYc+gos0Xr5zdMFm0X17FaHDr4ntWBxWPXtp1MHov3vGTy6J79jyWAOYo1My8pvyKB NePQ1jNMBbesKi7vmMTawHjXoIuRk0NI4CmjRP9imS5GLiB7FaPE1T3b2SGcyYwS3U+Xs4BUs QkYSLx9Nx8sISIwj1Fi5b8eJpCEsIC5xMXJ5xhBbBEBC4nlC9eyQ9huEu9e7AWLswioSszbf5 uti5GDg1fAW2LmXE+IzQeYJJ69iwWxOQViJW60TAUbySggJvH91Bowm1lAXOLWk/lgtoSAgMS SPeeZIWxRiZeP/7FC2AoS80/8gqrXk7gxdQobhK0tsWzha7B6XgFBiZMzn7BA7FWQ2Pv6ANsE RtFZSFbMQtI+C0n7LCTtCxhZVjFqFKcWlaUW6RpZ6iUVZaZnlOQmZuboGhoa6eWmFhcnpqfmJ CYV6yXn525iBMZYPQMD4w7Gf198DzFKcjApifIKx6wOF+JLyk+pzEgszogvKs1JLT7EKMPBoS TB2zJtTbiQYFFqempFWmYOMNph0hIcPEoivK9B0rzFBYm5xZnpEKlTjIpS4rw1IAkBkERGaR5 cGyzBXGKUlRLmZWRgYBDiKUgtys0sQZV/xSjOwagkzNsFMoUnM68EbvoroMVMQItPmIEtLklE SEk1MPq+UN7Wa5+bdYj/g+7bP9entr9yeq5kGim/vGVyR+HNv+E+ruyT/Z+qZOuYB/zNNP2ws PxoV9v6jYuLHZf5TT/bYCXL966jymqPV+FCg90mwVPPLdGVbfcTaj2sXZFh6tgRl/pzzi+WBb HhZql3FaTOh4jKnBPYvzZe/8/2cJZl+1uqbh11UWIpzkg01GIuKk4EAPYscRMrAwAA X-Env-Sender: smahmoud@lenovo.com X-Msg-Ref: server-5.tower-138.messagelabs.com!1470928841!48948645!1 X-Originating-IP: [104.232.225.2] X-StarScan-Received: X-StarScan-Version: 8.77; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4194 invoked from network); 11 Aug 2016 15:20:42 -0000 Received: from unknown (HELO maesmtp01.lenovo.com) (104.232.225.2) by server-5.tower-138.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 11 Aug 2016 15:20:42 -0000 Received: from AEMAILCH03.lenovo.com (unknown [10.40.13.90]) by maesmtp01.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA) id 23f9_22dc_4c76c689_e77a_47e0_b5bf_41d111871a1d; Thu, 11 Aug 2016 15:20:33 +0000 Received: from USMAILCH01.lenovo.com (10.62.32.5) by AEMAILCH03.lenovo.com (10.40.13.90) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 11 Aug 2016 08:20:25 -0700 Received: from USMAILMBX02.lenovo.com ([10.62.32.2]) by USMAILCH01.lenovo.com ([::1]) with mapi id 14.03.0123.003; Thu, 11 Aug 2016 11:20:25 -0400 From: Samer El Haj Mahmoud To: "Cohen, Eugene" , "Wu, Jiaxin" , "Ye, Ting" , "edk2-devel@lists.01.org" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AACr5IQ Date: Thu, 11 Aug 2016 15:20:25 +0000 Message-ID: <54EF1A77C479D840AF005ED34A3DC6596AAC40@USMAILMBX02.lenovo.com> References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.38.100.30] 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: Thu, 11 Aug 2016 15:20:44 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that this is problematic. I thought last time we discussed this, we= did try to request a PCD to set the default policy. I recall some hesitati= on in introducing a new PCD, but do not remember the details. I will try to= dig up that thread. Thanks, --Samer Samer El-Haj-Mahmoud SESM - OS / SW Architect Systems Management Development, Data Center Group Lenovo United States +1.919.908.5833 +1.512.659.1523 smahmoud@lenovo.com =A0 Lenovo.com /us=A0 Twitter=A0|=A0Facebook=A0|=A0Instagram=A0|=A0Blogs=A0|=A0Forums -----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 AM 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