Re: DHCP Automatic Configure at Driver Connect

["Wu, Jiaxin" <jiaxin.wu@intel.com>]

> 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.

Yes, that's because you have changed the policy to DHCP.

> 
> 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.

In my memory, we only talked about the performance issue before. Here, I understand your requirement: 1) The network interface should be in *un-configured* status at each boot time until the third part configuration; 2) the policy setting should be ignored, right? I don't think it's reasonable. I know the old Ip4Config did as you said here, but currently, the IPv4 default policy concept is new enrolled by Ip4Config2 protocol, the device policy should be in one state no matter static or DHCP. 

> 
> 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?

Actually, if you want to recover the Ipv4 setting to the *un-configured* status (Note here: policy should be always set, *un-configured* means no IP address configuration), Ip4Config2 provide the ability to change the default policy. As git commit version SHA-1: 7648748e99eeeadec38fda7568adb260c4acc861 described, "This update let the other platform drivers have chance to change 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. The 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 thing is not a good idea.  


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 <jiaxin.wu@intel.com>; Ye, Ting <ting.ye@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.wu@intel.com]
> > Sent: Thursday, August 11, 2016 12:00 AM
> > To: Ye, Ting <ting.ye@intel.com>; Cohen, Eugene <eugene@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 <eugene@hp.com>; edk2-devel@lists.01.org;
> > Wu, Jiaxin
> > > <jiaxin.wu@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-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 <jiaxin.wu@intel.com>
> > > Subject: [edk2] DHCP Automatic Configure at Driver Connect
> > >
> > > With this commit:
> > >
> > > Revision: 1f6729ffe98095107ce82e67a4a0209674601a90
> > > Author: jiaxinwu <jiaxin.wu@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