[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
Re: [edk2] DHCP Automatic Configure at Driver Connect
Eugene, The default policy is static, DHCPSB will not be installed automatically. Currently, there are only two cases that DHCP process will be triggered. One is Ip4Config2 policy change to DHCP, and another one is any IP4 configure instance set UseDefaultAddress to TRUE, detailed see Ip4StartAutoConfig(). So, I don't quite understand your question about the differs behavior compared to before. I think the current behavior of Ip4Config2 DHCP also need the third specifically configuration. Thanks, Jiaxin > -Original Message- > From: Cohen, Eugene [mailto:eug...@hp.com] > Sent: Thursday, August 11, 2016 2:17 AM > To: edk2-devel@lists.01.org; Wu, Jiaxin > Subject: 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
Re: [edk2] 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 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
Re: [edk2] 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-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 > 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
Re: [edk2] DHCP Automatic Configure at Driver Connect
t 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 > > 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
Re: [edk2] DHCP Automatic Configure at Driver Connect
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 ; Ye, Ting ; 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 ; 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. > >
Re: [edk2] DHCP Automatic Configure at Driver Connect
> 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-boun...@lists.01.org] On Behalf Of > Cohen, Eugene > Sent: Thursday, August 11, 2016 10:23 PM > To: Wu, Jiaxin ; Ye, Ting ; edk2- > de...@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 ; Cohen, Eugene ; > > edk2-devel@lists.01.org > > Subject: RE: DHCP Automatic Configure at Driver Connect > > > > Thanks Ting's more background clarification. > > > > I assume th
Re: [edk2] DHCP Automatic Configure at Driver Connect
Jiaxin, > > 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. Sorry I'm having trouble understanding what you meant - can you rephrase or expand this? Are you saying that it is not reasonable to want behavior consistent with the original Ip4Config behavior? This seems like something that should be doable - in my experiment suppressing the configuration in Ip4Config2OnDhcp4SbInstalled does exactly this so it seems like some additional policy (automatic versus on-demand) could be defined to handle this. > > > > 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. Let's say I have configured a static IP of 192.168.0.1. But since I don't want the network interface to automatically configure at boot I think you are saying that I should implement a platform policy driver that uses Ip4Config2 to set an *unconfigured* state. But there is no definition for an "unconfigured" state in UEFI 2.6 so how would one do this? Furthermore, wouldn't this effectively delete the previous static IP data? Maybe I just don't understand what you're describing - perhaps some pseudocode for your proposal that accomplishes the use case I'm describing would help. Again, I think this is just two different pieces of information that needs to be stored separately: 1. static vs dhcp vs unconfigured IP address settings, 2. automatic versus on-demand startup . Trying to to modify the IP address settings as an indirect way of communicating whether the stack should be configured seems far more troublesome than just storing another policy variable. If you feel this should be brought to UNST instead let me know and I'll switch forums. Eugene ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DHCP Automatic Configure at Driver Connect
> Jiaxin,
>
> > > 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
This is what I want to confirm with you that my understanding is right? You
complained the network interface comes "up" at each boot, what does "comes up"
exactly mean? So, I gave the above two guesses 1) and 2).
> > 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.
>
> Sorry I'm having trouble understanding what you meant - can you rephrase
> or expand this? Are you saying that it is not reasonable to want behavior
> consistent with the original Ip4Config behavior? This seems like something
Of course not. I mean if my guessing 2) is correct, it's not reasonable because
UEFI 2.6 spec only defined Static/DHCP policy. The policy should be in one of
them. I just recalled the old Ip4Config behavior: no policy assigned default
(if I remember correctly). So, don't misunderstand my truly means. It's
unrelated to the *behavior consistency*.
> that should be doable - in my experiment suppressing the configuration in
> Ip4Config2OnDhcp4SbInstalled does exactly this so it seems like some
> additional policy (automatic versus on-demand) could be defined to handle
> this.
>
> > >
> > > 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.
>
> Let's say I have configured a static IP of 192.168.0.1. But since I don't
> want
> the network interface to automatically configure at boot I think you are
> saying that I should implement a platform policy driver that uses Ip4Config2
> to set an *unconfigured* state. But there is no definition for an
> "unconfigured" state in UEFI 2.6 so how would one do this? Furthermore,
> wouldn't this effectively delete the previous static IP data? Maybe I just
> don't understand what you're describing - perhaps some pseudocode for
> your proposal that accomplishes the use case I'm describing would help.
>
First, *based on the current UEFI Spec (only static / dhcp policy)*, I want to
highlight my understanding of *un-configured* status you mentioned: policy
should be always set, *un-configured* means *no IP address configuration*.
If we want to implement such a *un-configured* state, one *DXE_DRIVER* can be
used with Ip4Config2 protocol. Detailed see below pseudocode:
First, register a notify for Ip4Config2 protocol in your Dxe Driver EntryPoint:
EfiCreateProtocolNotifyEvent (
&gEfiIp4Config2ProtocolGuid,
TPL_CALLBACK,
Ip4Config2InstalledCallback,
NULL,
&Registration
);
Then, In your Ip4Config2InstalledCallback() function, you can change the
default policy for the current boot:
Ip4Config2InstalledCallback () {
gBS->LocateProtocol (
&gEfiIp4Config2ProtocolGuid,
Registration,
(VOID **) &Ip4Config2Instance
);
Re: [edk2] DHCP Automatic Configure at Driver Connect
Jiaxin,
> > > 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;
Yes, we would like a policy setting (either runtime/protocol or build-time/PCD
is fine) for this.
2) the policy setting should be ignored, right? I
> > > don't
I don't know what you mean by this. The static/dhcp policy shouldn't
necessarily be ignored but if the interface is not yet configured (i.e. the IP
layer won't respond to packets) then the static/dhcp policy doesn't really
matter until some component calls Configure() for the first time.
> This is what I want to confirm with you that my understanding is right? You
> complained the network interface comes "up" at each boot, what does
> "comes up" exactly mean? So, I gave the above two guesses 1) and 2).
And I tried to clarify what I meant. Another way of saying it is by being "up"
it means performing DHCP (if that is the setting) and transmitting/receiving
packets using the IP address. What we are asking for is a policy where we can
suppress this behavior until the first Configure() call like before.
> Of course not. I mean if my guessing 2) is correct, it's not reasonable
> because
> UEFI 2.6 spec only defined Static/DHCP policy. The policy should be in one of
> them. I just recalled the old Ip4Config behavior: no policy assigned default
> (if
> I remember correctly). So, don't misunderstand my truly means. It's
> unrelated to the *behavior consistency*.
Perhaps not spec consistency but we need this for implementation consistency
since we've built up years of expectations from the previous implementation.
> First, *based on the current UEFI Spec (only static / dhcp policy)*, I want to
> highlight my understanding of *un-configured* status you mentioned: policy
> should be always set, *un-configured* means *no IP address configuration*.
Correct, in that the device will neither transmit or respond at an IP layer
initially.
> If we want to implement such a *un-configured* state, one *DXE_DRIVER*
> can be used with Ip4Config2 protocol. Detailed see below pseudocode:
>
> First, register a notify for Ip4Config2 protocol in your Dxe Driver
> EntryPoint:
> EfiCreateProtocolNotifyEvent (
> &gEfiIp4Config2ProtocolGuid,
> TPL_CALLBACK,
> Ip4Config2InstalledCallback,
> NULL,
> &Registration
> );
>
> Then, In your Ip4Config2InstalledCallback() function, you can change the
> default policy for the current boot:
> Ip4Config2InstalledCallback () {
> gBS->LocateProtocol (
> &gEfiIp4Config2ProtocolGuid,
> Registration,
> (VOID **) &Ip4Config2Instance
> );
>
> //
> // Change the policy to Ip4Config2PolicyDhcp to clean the static
> setting.
> //
> Policy = Ip4Config2PolicyDhcp;
> Ip4Config2Instance->SetData(
> Ip4Config2Instance,
>
> Ip4Config2DataTypePolicy,
> sizeof
> (EFI_IP4_CONFIG2_POLICY),
> &Policy
> );
>
> //
> // Change the policy to Ip4Config2PolicyStatic to clean the DHCP
> policy
> setting.
> //
> Policy = Ip4Config2PolicyStatic;
> Ip4Config2Instance->SetData(
> Ip4Config2Instance,
>
> Ip4Config2DataTypePolicy,
> sizeof
> (EFI_IP4_CONFIG2_POLICY),
> &Policy
> );
> }
>
> After that, your previous setting will be cleaned, and reach a *un-
> configured* state. I know the addition Dxe Driver is an indirect way to meet
> your requirement, but based on current UEFI Spec, it's one-time event if you
> added in your platform ahead.
There's two issues I see with this approach:
1. It destroys any previous configuration data that the user may have made
(static IP entry or explicit selection of DHCP)
2. It's a hack where we're using one policy interface to try to accomplish
something unrelated (auto vs on-demand config) based on attributes of the
current implementation and not the spec
So I'd like to propose again that we define another, separate, policy value for
automatic versus on-demand IP configuration. It can be either through a PCD or
a protocol interface. My preference in the short term is to do the PCD thing
since we can do it now where the protocol approach will require spec
modification.
Let m
Re: [edk2] DHCP Automatic Configure at Driver Connect
Hi Eugene, I think we need fully understand your usage before analyzing the problem. Could you please explain more details? You mentioned you only wanted to enable the network interface when directed by an application. If so, is it possible that you don't connect your network device until you really need that? Thanks, Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@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 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 ; 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
Re: [edk2] DHCP Automatic Configure at Driver Connect
Eugene,
> > > > 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;
>
> Yes, we would like a policy setting (either runtime/protocol or build-
> time/PCD is fine) for this.
>
> 2) the policy setting should be ignored, right? I
> > > > don't
>
> I don't know what you mean by this. The static/dhcp policy shouldn't
> necessarily be ignored but if the interface is not yet configured (i.e. the IP
> layer won't respond to packets) then the static/dhcp policy doesn't really
> matter until some component calls Configure() for the first time.
I mean I didn't know whether the *un-configured* status you want contain *no
policy setting * or not. But it doesn't matter now, from your statement here, I
know you don't care the policy setting.
>
> > This is what I want to confirm with you that my understanding is
> > right? You complained the network interface comes "up" at each boot,
> > what does "comes up" exactly mean? So, I gave the above two guesses 1)
> and 2).
>
> And I tried to clarify what I meant. Another way of saying it is by being
> "up" it
> means performing DHCP (if that is the setting) and transmitting/receiving
> packets using the IP address. What we are asking for is a policy where we
> can suppress this behavior until the first Configure() call like before.
As I said in previous email, " The current behavior of Ip4Config2: DHCP policy
together with D.O.R.A process, which is the same case as the old Ip4Config
behavior ". From the case you described here, are you want to separate the DHCP
policy setting and D.O.R.A process? We don't know.
>
> > Of course not. I mean if my guessing 2) is correct, it's not
> > reasonable because UEFI 2.6 spec only defined Static/DHCP policy. The
> > policy should be in one of them. I just recalled the old Ip4Config
> > behavior: no policy assigned default (if I remember correctly). So,
> > don't misunderstand my truly means. It's unrelated to the *behavior
> consistency*.
>
> Perhaps not spec consistency but we need this for implementation
> consistency since we've built up years of expectations from the previous
> implementation.
We also don't know what is the *specific/explicit* *implementation consistency*
you want here. Can you describe it more detail? I know the one difference
between the old Ip4Config and Ip4Config2 is about the policy assignment. The
old Ip4Config has no policy assigned default but currently we have the default
one according the UEFI2.6. I think this difference is enrolled by the Spec
updated. And this is also why I have the guess 2).
>
> > First, *based on the current UEFI Spec (only static / dhcp policy)*, I
> > want to highlight my understanding of *un-configured* status you
> > mentioned: policy should be always set, *un-configured* means *no IP
> address configuration*.
>
> Correct, in that the device will neither transmit or respond at an IP layer
> initially.
Ok, that's fine.
>
> > If we want to implement such a *un-configured* state, one *DXE_DRIVER*
> > can be used with Ip4Config2 protocol. Detailed see below pseudocode:
> >
> > First, register a notify for Ip4Config2 protocol in your Dxe Driver
> > EntryPoint:
> > EfiCreateProtocolNotifyEvent (
> > &gEfiIp4Config2ProtocolGuid,
> > TPL_CALLBACK,
> > Ip4Config2InstalledCallback,
> > NULL,
> > &Registration
> > );
> >
> > Then, In your Ip4Config2InstalledCallback() function, you can change
> > the default policy for the current boot:
> > Ip4Config2InstalledCallback () {
> > gBS->LocateProtocol (
> > &gEfiIp4Config2ProtocolGuid,
> > Registration,
> > (VOID **) &Ip4Config2Instance
> > );
> >
> > //
> > // Change the policy to Ip4Config2PolicyDhcp to clean the static
> > setting.
> > //
> > Policy = Ip4Config2PolicyDhcp;
> > Ip4Config2Instance->SetData(
> > Ip4Config2Instance,
> >
> > Ip4Config2DataTypePolicy,
> > sizeof
> > (EFI_IP4_CONFIG2_POLICY),
> > &Policy
> > );
> >
> > //
> > // Change the policy to Ip4Config2PolicyStatic to clean the
> > DHCP policy setting.
> > //
> > Policy = Ip4Config2PolicyStatic;
> > Ip4Config2Instance->SetData(
> > Ip4Config2Instance,
> >
> > Ip4Config2DataTypePolicy,
> > sizeof
Re: [edk2] DHCP Automatic Configure at Driver Connect
> Hi Eugene, > > I think we need fully understand your usage before analyzing the > problem. Could you please explain more details? You mentioned you > only wanted to enable the network interface when directed by an > application. If so, is it possible that you don't connect your network > device until you really need that? > > Thanks, > Ting Ting, I agree that if we could suppress driver connection for the network devices then that would result in the network being disabled. Our use case is that we still want to connect all drivers but not have the network start until directed through a Configure() call. Thanks, Eugene ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DHCP Automatic Configure at Driver Connect
Jiaxin, > I mean I didn't know whether the *un-configured* status you want > contain *no policy setting * or not. But it doesn't matter now, from > your statement here, I know you don't care the policy setting. Correct the static vs dhcp is irrelevant - it's the fact that the IP layer comes up that is the issue. > As I said in previous email, " The current behavior of Ip4Config2: DHCP > policy together with D.O.R.A process, which is the same case as the old > Ip4Config behavior ". I'm confused by this statement because I can see a distinct difference in behavior from the past. I can see the new code which enables the new behavior as well Ip4Config2OnDhcp4SbInstalled- when the DHCP SB is installed you do a configure automatically - this code simply did not exist before -- see Ip4Config2OnDhcp4SbInstalled. > From the case you described here, are you want > to separate the DHCP policy setting and D.O.R.A process? We don't > know. Yes, You could say I want to separate the DHCP vs static policy from D.O.R.A. but I don't think that's a good way to state it - I would state that we don't want the IP protocol (whether it be DHCP or statically configured) to be "up" until a piece of UEFI calls Configure(). > The provided solution for you (such a DXE Driver) is only based on you > want an *un-configured* status at each boot time until the third part > configuration. I think it does an approach for this. But I think Ting is > right, "we need fully understand your usage case before analyzing the > problem". Perhaps you have more detailed requirements we don't > know clearly. We want the IP config information stored in NVRAM (dhcp or static) to be preserved but want a separate policy choice to delay the IP interface coming "up" until a component calls Configure(). Eugene ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DHCP Automatic Configure at Driver Connect
Eugene,
> > I mean I didn't know whether the *un-configured* status you want
> > contain *no policy setting * or not. But it doesn't matter now, from
> > your statement here, I know you don't care the policy setting.
>
> Correct the static vs dhcp is irrelevant - it's the fact that the IP layer
> comes up
> that is the issue.
>
> > As I said in previous email, " The current behavior of Ip4Config2:
> > DHCP policy together with D.O.R.A process, which is the same case as
> > the old Ip4Config behavior ".
>
> I'm confused by this statement because I can see a distinct difference in
> behavior from the past. I can see the new code which enables the new
> behavior as well Ip4Config2OnDhcp4SbInstalled- when the DHCP SB is
> installed you do a configure automatically - this code simply did not exist
> before -- see Ip4Config2OnDhcp4SbInstalled.
>
Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not accurate as you
said "when the DHCP SB is installed you do a configure automatically". It's
more proper to say "IPv4 driver is requiring DHCP SB due to it detects the DHCP
policy." In such a case, it's reasonable with the function
Ip4Config2OnDhcp4SbInstalled().
Status = NetLibCreateServiceChild (
IpSb->Controller,
IpSb->Image,
&gEfiDhcp4ServiceBindingProtocolGuid,
&Instance->Dhcp4Handle
);
if (Status == EFI_UNSUPPORTED) {
//
// No DHCPv4 Service Binding protocol, register a notify.
//
if (Instance->Dhcp4SbNotifyEvent == NULL) {
Instance->Dhcp4SbNotifyEvent = EfiCreateProtocolNotifyEvent (
&gEfiDhcp4ServiceBindingProtocolGuid,
TPL_CALLBACK,
Ip4Config2OnDhcp4SbInstalled,
(VOID *) Instance,
&Instance->Registration
);
}
}
I agree with you this code did not exist in *Ip4Dxe* before. We implemented
this function because of we need start the AutoConfig due to the DHCP policy is
detected by Ip4Dxe driver (DHCP policy (note: NOT DHCP SB) together with
D.O.R.A process). It does may appear AutoConfig straight away with DHCP SB if
Ip4Dxe ahead of Dhcp4Dxe. But the precondition is that the DHCP policy has been
detected. If the policy is not DHCP during the system boot, I think your
concern will not appear.
Now, compared to old Ip4Config behavior, we take 'ifconfig' tool command as
example - "ifconfig -s eth0 dhcp":
The Ip4Config->Start will be invoked to start the auto configuration. It was
implemented in the deprecated driver -- Ip4ConfigDxe. When the system boot next
time, the previous IP configuration will cleaned and the interface will be in
UN-CONFIG status again. Current implementation don't have this clean-up
operation no matter Static/DHCP policy has been set. Is this the difference you
mentioned?
> > From the case you described here, are you want to separate the DHCP
> > policy setting and D.O.R.A process? We don't know.
>
> Yes, You could say I want to separate the DHCP vs static policy from D.O.R.A.
> but I don't think that's a good way to state it - I would state that we don't
> want the IP protocol (whether it be DHCP or statically configured) to be "up"
> until a piece of UEFI calls Configure().
>
> > The provided solution for you (such a DXE Driver) is only based on you
> > want an *un-configured* status at each boot time until the third part
> > configuration. I think it does an approach for this. But I think Ting
> > is right, "we need fully understand your usage case before analyzing
> > the problem". Perhaps you have more detailed requirements we don't
> > know clearly.
>
> We want the IP config information stored in NVRAM (dhcp or static) to be
> preserved but want a separate policy choice to delay the IP interface coming
> "up" until a component calls Configure().
Now, let us consider your requirement:
1) The IP config information stored in NVRAM
2) A separate policy to delay the IP interface coming up until a component
calls Configure ().
#1 is also the current implementation. For 2), I remember you have one patch to
do this implementation, can you share it to us for better understanding?
>
> 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
Re: [edk2] DHCP Automatic Configure at Driver Connect
Jiaxin, > Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not accurate > as you said "when the DHCP SB is installed you do a configure automatically". > It's more proper to say "IPv4 driver is requiring DHCP SB due to it detects > the > DHCP policy." In such a case, it's reasonable with the function > Ip4Config2OnDhcp4SbInstalled(). I see - my observation was based on the fact that removing this prevented the undesirable automatic configuration, but what you say makes sense. > I agree with you this code did not exist in *Ip4Dxe* before. We implemented > this function because of we need start the AutoConfig due to the DHCP > policy is detected by Ip4Dxe driver (DHCP policy (note: NOT DHCP SB) > together with D.O.R.A process). It does may appear AutoConfig straight away > with DHCP SB if Ip4Dxe ahead of Dhcp4Dxe. But the precondition is that the > DHCP policy has been detected. If the policy is not DHCP during the system > boot, I think your concern will not appear. Are you saying the IP4 interface will not come "up" even for a static IP policy? I was assuming it would in this case. I'm not sure how big a deal this is because if there are no listeners or connections initiated it's kind of a don't-care - I think the only difference would be whether responses to ARP are provided. > Now, compared to old Ip4Config behavior, we take 'ifconfig' tool command > as example - "ifconfig -s eth0 dhcp": > The Ip4Config->Start will be invoked to start the auto configuration. It was > implemented in the deprecated driver -- Ip4ConfigDxe. When the system > boot next time, the previous IP configuration will cleaned and the interface > will be in UN-CONFIG status again. Current implementation don't have this > clean-up operation no matter Static/DHCP policy has been set. Is this the > difference you mentioned? Okay - this must be it - so DHCP magically turned back into "unconfigured" effectively creating the on-demand Configure() effect, at least for DHCP cases, that we now desire. Interesting. > Now, let us consider your requirement: > 1) The IP config information stored in NVRAM > 2) A separate policy to delay the IP interface coming up until a component > calls Configure (). > > #1 is also the current implementation. For 2), I remember you have one > patch to do this implementation, can you share it to us for better > understanding? Yes, my first thought was to make the handling of Ip4Config2OnDhcp4SbInstalled conditional based on a PCD value (the policy in this case, would be in the PCD value). Based on the limited experiment I did this seems to have the desired effect but based on your expertise perhaps there is a better location for such a check? Thank you for patiently helping me with this - it's been enlightening to learn the history and thinking behind the config process. Eugene ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DHCP Automatic Configure at Driver Connect
Eugene, > > Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not > > accurate as you said "when the DHCP SB is installed you do a configure > automatically". > > It's more proper to say "IPv4 driver is requiring DHCP SB due to it > > detects the DHCP policy." In such a case, it's reasonable with the > > function Ip4Config2OnDhcp4SbInstalled(). > > I see - my observation was based on the fact that removing this prevented the > undesirable automatic configuration, but what you say makes sense. > > > I agree with you this code did not exist in *Ip4Dxe* before. We > > implemented this function because of we need start the AutoConfig due > > to the DHCP policy is detected by Ip4Dxe driver (DHCP policy (note: > > NOT DHCP SB) together with D.O.R.A process). It does may appear > > AutoConfig straight away with DHCP SB if Ip4Dxe ahead of Dhcp4Dxe. But > > the precondition is that the DHCP policy has been detected. If the > > policy is not DHCP during the system boot, I think your concern will not > appear. > > Are you saying the IP4 interface will not come "up" even for a static IP > policy? If the policy is static and the default interface has not been referenced/used, we can say it's not come up. Once you get involved and do any IP assignment, the default interface is only ready to use, we can say it has been configured and it's available now. For *Ip4Dxe*, I think no matter what kind of policy behavior will only affect the default interface (configured or un-configured), currently : 1) If the policy is DHCP, Ip4Dxe will try his best to be in available state. 2) If the policy is static, it will depend on the third part configuration. After the default interface is ready and available, the only way I can think to make it in un-configured state is leveraging the DXE_DRIVER (I mentioned it before) to do some cleanup according the current implementation. For #1, the DHCP process will be triggered automatically. For #2, I agree such a DXE_DRIVER driver will destroy the previous configuration data (Actually, the old Ip4Config behavior also did it), but if not, how can we reach such a un-configured state since the data already saved? > I was assuming it would in this case. I'm not sure how big a deal this is > because > if there are no listeners or connections initiated it's kind of a don't-care > - I > think the only difference would be whether responses to ARP are provided. > > > Now, compared to old Ip4Config behavior, we take 'ifconfig' tool > > command as example - "ifconfig -s eth0 dhcp": > > The Ip4Config->Start will be invoked to start the auto configuration. > > It was implemented in the deprecated driver -- Ip4ConfigDxe. When the > > system boot next time, the previous IP configuration will cleaned and > > the interface will be in UN-CONFIG status again. Current > > implementation don't have this clean-up operation no matter > > Static/DHCP policy has been set. Is this the difference you mentioned? > > Okay - this must be it - so DHCP magically turned back into "unconfigured" > effectively creating the on-demand Configure() effect, at least for DHCP > cases, > that we now desire. Interesting. > Yeah. > > Now, let us consider your requirement: > > 1) The IP config information stored in NVRAM > > 2) A separate policy to delay the IP interface coming up until a > > component calls Configure (). > > > > #1 is also the current implementation. For 2), I remember you have one > > patch to do this implementation, can you share it to us for better > > understanding? > > Yes, my first thought was to make the handling of > Ip4Config2OnDhcp4SbInstalled conditional based on a PCD value (the policy in > this case, would be in the PCD value). Based on the limited experiment I did > this seems to have the desired effect but based on your expertise perhaps > there is a better location for such a check? > Ok, understand your purpose. So, It's not related to the IP protocol to be "up" or not , and also not related to *reach un-configured state* if policy is *static*. Right? If so, we can only focus on the question "whether to separate the D.O.R.A process with DHCP policy or not". In addition, I don't think it's a good idea to use PCD to decide/control the DHCP policy behavior. We should keep the DHCP policy behavior constant (no matter to separate the D.O.R.A process or keep the current implementation). In my opinion or usage case, keep the current implementation is fine. But as you complained, it does trouble your previous usage. It will be appreciated if you can describe your usage case here, for example, step1, step2,...:). > Thank you for patiently helping me with this - it's been enlightening to learn > the history and thinking behind the config process. > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DHCP Automatic Configure at Driver Connect
Hi Eugene, If you propose separating DHCP process from DHCP policy setting, I think it is more like to update/clarify existing behavior defined in IP4Config2/IP6Config of UEFI specification. How about we move the discussion to UNST forum, in order to draw more attention for the topic? Thanks, Ting -Original Message- From: Wu, Jiaxin Sent: Thursday, August 18, 2016 10:49 AM To: Cohen, Eugene ; Ye, Ting ; edk2-devel@lists.01.org; Kinney, Michael D ; Fu, Siyuan Subject: RE: DHCP Automatic Configure at Driver Connect Eugene, > > Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not > > accurate as you said "when the DHCP SB is installed you do a > > configure > automatically". > > It's more proper to say "IPv4 driver is requiring DHCP SB due to it > > detects the DHCP policy." In such a case, it's reasonable with the > > function Ip4Config2OnDhcp4SbInstalled(). > > I see - my observation was based on the fact that removing this > prevented the undesirable automatic configuration, but what you say makes > sense. > > > I agree with you this code did not exist in *Ip4Dxe* before. We > > implemented this function because of we need start the AutoConfig > > due to the DHCP policy is detected by Ip4Dxe driver (DHCP policy (note: > > NOT DHCP SB) together with D.O.R.A process). It does may appear > > AutoConfig straight away with DHCP SB if Ip4Dxe ahead of Dhcp4Dxe. > > But the precondition is that the DHCP policy has been detected. If > > the policy is not DHCP during the system boot, I think your concern > > will not > appear. > > Are you saying the IP4 interface will not come "up" even for a static IP > policy? If the policy is static and the default interface has not been referenced/used, we can say it's not come up. Once you get involved and do any IP assignment, the default interface is only ready to use, we can say it has been configured and it's available now. For *Ip4Dxe*, I think no matter what kind of policy behavior will only affect the default interface (configured or un-configured), currently : 1) If the policy is DHCP, Ip4Dxe will try his best to be in available state. 2) If the policy is static, it will depend on the third part configuration. After the default interface is ready and available, the only way I can think to make it in un-configured state is leveraging the DXE_DRIVER (I mentioned it before) to do some cleanup according the current implementation. For #1, the DHCP process will be triggered automatically. For #2, I agree such a DXE_DRIVER driver will destroy the previous configuration data (Actually, the old Ip4Config behavior also did it), but if not, how can we reach such a un-configured state since the data already saved? > I was assuming it would in this case. I'm not sure how big a deal > this is because if there are no listeners or connections initiated > it's kind of a don't-care - I think the only difference would be whether > responses to ARP are provided. > > > Now, compared to old Ip4Config behavior, we take 'ifconfig' tool > > command as example - "ifconfig -s eth0 dhcp": > > The Ip4Config->Start will be invoked to start the auto configuration. > > It was implemented in the deprecated driver -- Ip4ConfigDxe. When > > the system boot next time, the previous IP configuration will > > cleaned and the interface will be in UN-CONFIG status again. > > Current implementation don't have this clean-up operation no matter > > Static/DHCP policy has been set. Is this the difference you mentioned? > > Okay - this must be it - so DHCP magically turned back into "unconfigured" > effectively creating the on-demand Configure() effect, at least for > DHCP cases, that we now desire. Interesting. > Yeah. > > Now, let us consider your requirement: > > 1) The IP config information stored in NVRAM > > 2) A separate policy to delay the IP interface coming up until a > > component calls Configure (). > > > > #1 is also the current implementation. For 2), I remember you have > > one patch to do this implementation, can you share it to us for > > better understanding? > > Yes, my first thought was to make the handling of > Ip4Config2OnDhcp4SbInstalled conditional based on a PCD value (the > policy in this case, would be in the PCD value). Based on the limited > experiment I did this seems to have the desired effect but based on > your expertise perhaps there is a better location for such a check? > Ok, understand your purpose. So, It's not related to the IP protocol to be "up" or not , and also not related to *reach un-configured state* if policy is *static*. Right? If so, we can only focus on the question "whether to separate the D.O.R.A process with DHCP policy or not". In addition, I don't think it's a good idea to use PCD to decide/control the DHCP policy behavior. We should keep the DHCP policy behavior constant (no matter to separate the D.O.R.A process or keep the current implementation). In my
Re: [edk2] DHCP Automatic Configure at Driver Connect
Ting, sounds good to me - the discussion here seems to be growing increasingly unproductive. I'll tee this up with UNST. Eugene > -Original Message- > From: Ye, Ting [mailto:ting...@intel.com] > Sent: Wednesday, August 17, 2016 9:11 PM > To: Wu, Jiaxin ; Cohen, Eugene > ; edk2-devel@lists.01.org; Kinney, Michael D > ; Fu, Siyuan > Subject: RE: DHCP Automatic Configure at Driver Connect > > Hi Eugene, > > If you propose separating DHCP process from DHCP policy setting, I > think it is more like to update/clarify existing behavior defined in > IP4Config2/IP6Config of UEFI specification. How about we move the > discussion to UNST forum, in order to draw more attention for the > topic? > > Thanks, > Ting > -Original Message- > From: Wu, Jiaxin > Sent: Thursday, August 18, 2016 10:49 AM > To: Cohen, Eugene ; Ye, Ting ; > edk2-devel@lists.01.org; Kinney, Michael D > ; Fu, Siyuan > Subject: RE: DHCP Automatic Configure at Driver Connect > > Eugene, > > > > Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not > > > accurate as you said "when the DHCP SB is installed you do a > > > configure > > automatically". > > > It's more proper to say "IPv4 driver is requiring DHCP SB due to it > > > detects the DHCP policy." In such a case, it's reasonable with the > > > function Ip4Config2OnDhcp4SbInstalled(). > > > > I see - my observation was based on the fact that removing this > > prevented the undesirable automatic configuration, but what you > say makes sense. > > > > > I agree with you this code did not exist in *Ip4Dxe* before. We > > > implemented this function because of we need start the > AutoConfig > > > due to the DHCP policy is detected by Ip4Dxe driver (DHCP policy > (note: > > > NOT DHCP SB) together with D.O.R.A process). It does may appear > > > AutoConfig straight away with DHCP SB if Ip4Dxe ahead of > Dhcp4Dxe. > > > But the precondition is that the DHCP policy has been detected. If > > > the policy is not DHCP during the system boot, I think your concern > > > will not > > appear. > > > > Are you saying the IP4 interface will not come "up" even for a static > IP policy? > > If the policy is static and the default interface has not been > referenced/used, we can say it's not come up. Once you get involved > and do any IP assignment, the default interface is only ready to use, > we can say it has been configured and it's available now. > > For *Ip4Dxe*, I think no matter what kind of policy behavior will only > affect the default interface (configured or un-configured), currently : > 1) If the policy is DHCP, Ip4Dxe will try his best to be in available state. > 2) If the policy is static, it will depend on the third part configuration. > After the default interface is ready and available, the only way I can > think to make it in un-configured state is leveraging the DXE_DRIVER (I > mentioned it before) to do some cleanup according the current > implementation. > > For #1, the DHCP process will be triggered automatically. > For #2, I agree such a DXE_DRIVER driver will destroy the previous > configuration data (Actually, the old Ip4Config behavior also did it), but > if not, how can we reach such a un-configured state since the data > already saved? > > > > I was assuming it would in this case. I'm not sure how big a deal > > this is because if there are no listeners or connections initiated > > it's kind of a don't-care - I think the only difference would be > whether responses to ARP are provided. > > > > > Now, compared to old Ip4Config behavior, we take 'ifconfig' tool > > > command as example - "ifconfig -s eth0 dhcp": > > > The Ip4Config->Start will be invoked to start the auto configuration. > > > It was implemented in the deprecated driver -- Ip4ConfigDxe. > When > > > the system boot next time, the previous IP configuration will > > > cleaned and the interface will be in UN-CONFIG status again. > > > Current implementation don't have this clean-up operation no > matter > > > Static/DHCP policy has been set. Is this the difference you > mentioned? > > > > Okay - this must be it - so DHCP magically turned back into > "unconfigured" > > effectively creating the on-demand Configure() effect, at least for > > DHCP cases, that we now desire. Interesting. > > > > Yeah. > > > > Now, let us consider your requirement: > > > 1) The IP config information stored in NVRAM > > > 2) A separate policy to delay the IP interface coming up until a > > > component calls Configure (). > > > > > > #1 is also the current implementation. For 2), I remember you have > > > one patch to do this implementation, can you share it to us for > > > better understanding? > > > > Yes, my first thought was to make the handling of > > Ip4Config2OnDhcp4SbInstalled conditional based on a PCD value (the > > policy in this case, would be in the PCD value). Based on the limited > > experiment I did this seems to have the desired effect but based on > > your expertise perhaps there is a b
