From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ml01.01.org (Postfix) with ESMTP id 2564A1A1DF7 for ; Wed, 17 Aug 2016 20:10:59 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 17 Aug 2016 20:10:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,537,1464678000"; d="scan'208";a="867331459" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga003.jf.intel.com with ESMTP; 17 Aug 2016 20:11:00 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 17 Aug 2016 20:10:57 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 17 Aug 2016 20:10:56 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.181]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.116]) with mapi id 14.03.0248.002; Thu, 18 Aug 2016 11:10:44 +0800 From: "Ye, Ting" To: "Wu, Jiaxin" , "Cohen, Eugene" , "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Fu, Siyuan" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hgABh+18AAGhwegACBdhLAABj3DZAAI4TcYAANnL8wABWc93AAGZHCgAAFmxSA Date: Thu, 18 Aug 2016 03:10:44 +0000 Message-ID: References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C63EC@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C677D@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C7D82@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C819F@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C85DE@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B7274137C85DE@SHSMSX103.ccr.corp.intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] 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, 18 Aug 2016 03:10:59 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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/IP6= Config of UEFI specification. How about we move the discussion to UNST foru= m, in order to draw more attention for the topic? Thanks, Ting -----Original Message----- From: Wu, Jiaxin=20 Sent: Thursday, August 18, 2016 10:49 AM To: Cohen, Eugene ; Ye, Ting ; edk2-devel= @lists.01.org; Kinney, Michael D ; Fu, Siyuan <= siyuan.fu@intel.com> Subject: RE: DHCP Automatic Configure at Driver Connect Eugene, > > Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not=20 > > accurate as you said "when the DHCP SB is installed you do a=20 > > configure > automatically". > > It's more proper to say "IPv4 driver is requiring DHCP SB due to it=20 > > detects the DHCP policy." In such a case, it's reasonable with the=20 > > function Ip4Config2OnDhcp4SbInstalled(). >=20 > I see - my observation was based on the fact that removing this=20 > prevented the undesirable automatic configuration, but what you say makes= sense. >=20 > > I agree with you this code did not exist in *Ip4Dxe* before. We=20 > > implemented this function because of we need start the AutoConfig=20 > > 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=20 > > AutoConfig straight away with DHCP SB if Ip4Dxe ahead of Dhcp4Dxe.=20 > > But the precondition is that the DHCP policy has been detected. If=20 > > the policy is not DHCP during the system boot, I think your concern=20 > > will not > appear. >=20 > 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/u= sed, we can say it's not come up. Once you get involved and do any IP assi= gnment, the default interface is only ready to use, we can say it has been = configured and it's available now.=20 For *Ip4Dxe*, I think no matter what kind of policy behavior will only affe= ct the default interface (configured or un-configured), currently :=20 1) If the policy is DHCP, Ip4Dxe will try his best to be in available state= .=20 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 th= ink to make it in un-configured state is leveraging the DXE_DRIVER (I menti= oned it before) to do some cleanup according the current implementation.=20 For #1, the DHCP process will be triggered automatically. For #2, I agree such a DXE_DRIVER driver will destroy the previous configur= ation 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=20 > this is because if there are no listeners or connections initiated=20 > it's kind of a don't-care - I think the only difference would be whether = responses to ARP are provided. >=20 > > Now, compared to old Ip4Config behavior, we take 'ifconfig' tool=20 > > 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=20 > > the system boot next time, the previous IP configuration will=20 > > cleaned and the interface will be in UN-CONFIG status again. =20 > > Current implementation don't have this clean-up operation no matter=20 > > Static/DHCP policy has been set. Is this the difference you mentioned? >=20 > Okay - this must be it - so DHCP magically turned back into "unconfigured= " > effectively creating the on-demand Configure() effect, at least for=20 > DHCP cases, that we now desire. Interesting. >=20 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=20 > > component calls Configure (). > > > > #1 is also the current implementation. For 2), I remember you have=20 > > one patch to do this implementation, can you share it to us for=20 > > better understanding? >=20 > Yes, my first thought was to make the handling of=20 > Ip4Config2OnDhcp4SbInstalled conditional based on a PCD value (the=20 > policy in this case, would be in the PCD value). Based on the limited=20 > experiment I did this seems to have the desired effect but based on=20 > your expertise perhaps there is a better location for such a check? >=20 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 s= eparate 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 th= e DHCP policy behavior. We should keep the DHCP policy behavior constant (n= o matter to separate the D.O.R.A process or keep the current implementation= ). =20 In my opinion or usage case, keep the current implementation is fine. But a= s you complained, it does trouble your previous usage. It will be appreciat= ed if you can describe your usage case here, for example, step1, step2,...:= ). > Thank you for patiently helping me with this - it's been enlightening=20 > to learn the history and thinking behind the config process. >=20