From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4a::70c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 103BD1A1E04 for ; Thu, 18 Aug 2016 07:30:05 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Thu, 18 Aug 2016 14:30:02 +0000 Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) with mapi id 15.01.0587.009; Thu, 18 Aug 2016 14:30:02 +0000 From: "Cohen, Eugene" To: "Ye, Ting" , "Wu, Jiaxin" , "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Fu, Siyuan" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hgABh+18AAGhwegACBdhLAABj3DZAAI4TcYAANnL8wABWc93AAGZHCgAAFmxSAABgEkzA= Date: Thu, 18 Aug 2016 14:30:02 +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: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eugene@hp.com; x-originating-ip: [15.65.254.4] x-ms-office365-filtering-correlation-id: 41204262-a33e-46b2-f4a1-08d3c774245b x-microsoft-exchange-diagnostics: 1; AT5PR84MB0291; 6:WUjmiteG0LFqNEite/1h327b+OXvXTd4EhiDn+MLogKajWtSOvzwNqLNQIa+uy0S0Fw19ZBUlliaqFm+FRbfPEJ4W2/vL8ZzJv5doMhF9CRqS/xwD/ajfy8waaOK+vIgUqQP8KXL8XCb9jPgGUPttT1d4Wkif1EbionvrmakU+Jo1XiQmIf8k0CQzATAjhGHUwdm0THYYsyY17hFrgQNrGy7Fv4HNCVoip04v4pmYSBM8AmtUHkkhwgzE4wSdcMUrbWS/b0neGoY4Yd/fDwVzImtWL2GQ0JT/WOgLRX2dkw=; 5:Uz7YfYMGAJbq6q87cH3MUfgl3tHzFzByEjzXbrD6Szrmr9+Umc2jjhCtw4EB753kqEFoRNEm3AX1Tv6SyrYtIbBS2aZMv61xGRsHlmKa63PqfYC2V0Xg7etSWktnIaf3NvIn4XSW3Eky7pWzpJn3Cg==; 24:iFS4BDp2mBzQA2j+y783n+iZt0U2GV+AwdhoTpwesNzrIeGl1w63R6POqC9tz/SLdQy0jjuiR58qibuDKSoe7XBgD0dlqcnI6P/RQpCwLRs=; 7:V+L/LlML+oaJxdfrjKnA6ZoCJihzfAMFTQCwL/c3Kf6qsRD5ccgaj5xD+Fmg++zmgXmNTFgZq+7yhoKHl3h680pu726+ZticB19Dx6/ghb+hJdiXjwMaoqzFNqvyXVHIUjs0Sic/VdR499QExGhqNx00671YsTMB8LmkhLbG3eVZlMuXSLhjGORNsM2FHbjjGCvXwqMpapvaS89VOSj7/bxSHBIb2LIN/m1qLFwGP9P6JWSAvx4rMr69B9D0t3nv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0291; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(162533806227266)(21532816269658)(228905959029699)(73583498263828); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AT5PR84MB0291; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0291; x-forefront-prvs: 0038DE95A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(6602003)(13464003)(377454003)(189002)(76176999)(105586002)(345774005)(3900700001)(99286002)(189998001)(5002640100001)(87936001)(54356999)(19580405001)(19580395003)(5001770100001)(97736004)(33656002)(74316002)(50986999)(11100500001)(68736007)(7696003)(305945005)(7736002)(107886002)(7846002)(8676002)(122556002)(10400500002)(2950100001)(586003)(102836003)(3846002)(6116002)(77096005)(2900100001)(3660700001)(3280700002)(66066001)(101416001)(92566002)(86362001)(2501003)(2906002)(8936002)(9686002)(81166006)(81156014)(93886004)(106356001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0291; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2016 14:30:02.6419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0291 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 14:30:05 -0000 Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ting, sounds good to me - the discussion here seems to be growing increasin= gly unproductive. I'll tee this up with UNST. Eugene > -----Original Message----- > From: Ye, Ting [mailto:ting.ye@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 >=20 > Hi Eugene, >=20 > 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? >=20 > 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 >=20 > Eugene, >=20 > > > 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? >=20 > 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. >=20 > 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 sta= te. > 2) If the policy is static, it will depend on the third part configurati= on. > 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. >=20 > 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), bu= t > if not, how can we reach such a un-configured state since the data > already saved? >=20 >=20 > > 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. > > >=20 > Yeah. >=20 > > > 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? > > >=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 separate the D.O.R.A process with DHCP policy or not". >=20 > 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). >=20 > 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,...:). >=20 >=20 >=20 > > Thank you for patiently helping me with this - it's been enlightening > > to learn the history and thinking behind the config process. > >