From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ml01.01.org (Postfix) with ESMTP id 0AD2C1A1E12 for ; Mon, 15 Aug 2016 20:05:17 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 15 Aug 2016 20:05:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,528,1464678000"; d="scan'208";a="1014967990" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 15 Aug 2016 20:05:15 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 15 Aug 2016 20:05:15 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 15 Aug 2016 20:05:15 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.181]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.150]) with mapi id 14.03.0248.002; Tue, 16 Aug 2016 11:05:14 +0800 From: "Wu, Jiaxin" To: "Cohen, Eugene" , "Ye, Ting" , "edk2-devel@lists.01.org" , "Kinney, Michael D" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hgABh+18AAGhwegACBdhLAABj3DZA= Date: Tue, 16 Aug 2016 03:05:14 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B7274137C7D82@SHSMSX103.ccr.corp.intel.com> References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C63EC@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C677D@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: 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: Tue, 16 Aug 2016 03:05:17 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; >=20 > Yes, we would like a policy setting (either runtime/protocol or build- > time/PCD is fine) for this. >=20 > 2) the policy setting should be ignored, right? I > > > > don't >=20 > 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. t= he IP > layer won't respond to packets) then the static/dhcp policy doesn't reall= y > matter until some component calls Configure() for the first time. I mean I didn't know whether the *un-configured* status you want contain *n= o policy setting * or not. But it doesn't matter now, from your statement h= ere, I know you don't care the policy setting. >=20 > > 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). >=20 > And I tried to clarify what I meant. Another way of saying it is by bein= g "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 w= e > can suppress this behavior until the first Configure() call like before. As I said in previous email, " The current behavior of Ip4Config2: DHCP pol= icy together with D.O.R.A process, which is the same case as the old Ip4Con= fig 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. >=20 > > 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*. >=20 > 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 consiste= ncy* you want here. Can you describe it more detail? I know the one differe= nce between the old Ip4Config and Ip4Config2 is about the policy assignment= . The old Ip4Config has no policy assigned default but currently we have th= e 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). =20 >=20 > > 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*. >=20 > Correct, in that the device will neither transmit or respond at an IP lay= er > initially. Ok, that's fine. >=20 > > 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 En= tryPoint: > > 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 stat= ic setting. > > // > > Policy =3D Ip4Config2PolicyDhcp; > > Ip4Config2Instance->SetData( > > Ip4Config2Insta= nce, > > Ip4Config2DataT= ypePolicy, > > sizeof (EFI_IP4= _CONFIG2_POLICY), > > &Policy > > ); > > > > // > > // Change the policy to Ip4Config2PolicyStatic to clean the > > DHCP policy setting. > > // > > Policy =3D Ip4Config2PolicyStatic; > > Ip4Config2Instance->SetData( > > Ip4Config2Insta= nce, > > Ip4Config2DataT= ypePolicy, > > 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. >=20 > There's two issues I see with this approach: >=20 > 1. It destroys any previous configuration data that the user may have mad= e > (static IP entry or explicit selection of DHCP) 2. It's a hack where we'r= e 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 >=20 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 configura= tion. 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". Perhap= s you have more detailed requirements we don't know clearly. > So I'd like to propose again that we define another, separate, policy val= ue 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 PC= D > thing since we can do it now where the protocol approach will require spe= c > modification. >=20 > Let me know if that makes sense - I'm prepared to provide a patch for the > PCD option if/when you're ready. >=20 > Eugene >=20