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 hesitation 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 smahm...@lenovo.com Lenovo.com /us Twitter | Facebook | Instagram | Blogs | Forums -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, Eugene Sent: Thursday, August 11, 2016 10:23 AM To: Wu, Jiaxin <jiaxin...@intel.com>; Ye, Ting <ting...@intel.com>; edk2-devel@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 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 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 each 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 store 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 within the scope of the spec? Could we just have a PCD that suppresses the automatic configure at boot under any circumstance? Thanks, Eugene > -----Original Message----- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Thursday, August 11, 2016 12:00 AM > To: Ye, Ting <ting...@intel.com>; Cohen, Eugene <eug...@hp.com>; > 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 <eug...@hp.com>; edk2-devel@lists.01.org; > Wu, Jiaxin > > <jiaxin...@intel.com> > > 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-boun...@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...@intel.com> > > Subject: [edk2] DHCP Automatic Configure at Driver Connect > > > > With this commit: > > > > Revision: 1f6729ffe98095107ce82e67a4a0209674601a90 > > Author: jiaxinwu <jiaxin...@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 _______________________________________________ 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
