From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::708]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E454A1A1E3B for ; Mon, 15 Aug 2016 07:40:32 -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_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 15 Aug 2016 14:40:30 +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.0549.027; Mon, 15 Aug 2016 14:40:30 +0000 From: "Cohen, Eugene" To: "Wu, Jiaxin" , "Ye, Ting" , "edk2-devel@lists.01.org" , "Kinney, Michael D" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hgABh+18AAGhwegACBdhLA Date: Mon, 15 Aug 2016 14:40:29 +0000 Message-ID: References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C63EC@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C677D@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B7274137C677D@SHSMSX103.ccr.corp.intel.com> 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: [174.19.99.119] x-ms-office365-filtering-correlation-id: e48ff2db-aad1-4769-7558-08d3c51a1ae3 x-microsoft-exchange-diagnostics: 1; AT5PR84MB0291; 6:lv/IpZAB/jagREcT9QTVq+THR5qY63Okq09nrBw0Jr62LY9TAeAJWmvHtEb0XRpspCHU4nwP2J4TIVQwk9lASHKTBchTFT7mfVLoc+jA5gHKHuGaFKYO/pI7jNgCNa8Vodmv6QXoY/9vNojZNcT2j/XWWMlN+j89XG1zXdNQ3TKDUlQ52300X6O/jPjptjk5m0RmsDWdEPCLDj3HF0PZF0SYzGUY2fQcvLfcN/9CxlB0oNLFjrlriWRAyWfc4v4O63gS6W/jcNgIVzBaW9pWZGKSdFzOobEvz1TtT0u72Lg=; 5:CRqEmIN3T+kSKxZfoJqcerb1zXo/gKOqAHtgsOMTkwbkcQuC72asVraSXIYYdKqq1qm30Au3+YiljG6KuVVhRZZxBXRwPNjNw4Oi07SdL9JqoCIR0/DXs+OGwY/dRVEMVhd5AdYEbZU2esqXYAKhlQ==; 24:63oKCNbVHxH2n4gR2CRu/SSNaGP5aiXZEHvgt5WwOCStOR6xoGOachRY+udhIsrdn5el8Yy6AdcGTgkvLwUIPDPt19kd+vu/UVYwNppO10o=; 7:enoceHVcdRE6AIRRPn+TOvWyhqjR5FhvxmB//0qqVj+HSdI9wqPSiIU1vfx58K6OHMCzw9N3bUhYeG6Rkphn160zz8cDe3FGa4Nzqi/Ge+yaH+hkYau7E4saWXEbfRHpcR8ippyrLa1WGX/ELwy1oLty8OiMtUgCb0FQRAqXccJjBHLSlras1ovj2wSs6nf0INYPqmvCmvNYkvpNqY0rx3O1CTwC/EbnqyI1Wh7bSNhjQ96EQfvMQDJ8FshWEcE4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0291; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AT5PR84MB0291; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0291; x-forefront-prvs: 0035B15214 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(6602003)(189002)(199003)(81156014)(97736004)(11100500001)(81166006)(9686002)(3660700001)(99286002)(8936002)(92566002)(106356001)(66066001)(107886002)(101416001)(3280700002)(86362001)(2906002)(3846002)(93886004)(305945005)(10400500002)(2900100001)(5002640100001)(7736002)(7696003)(2950100001)(77096005)(74316002)(586003)(7846002)(122556002)(189998001)(102836003)(87936001)(5001770100001)(68736007)(50986999)(6116002)(33656002)(105586002)(8676002)(54356999)(2501003)(76176999)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0291; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: 15 Aug 2016 14:40:29.8926 (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: Mon, 15 Aug 2016 14:40:33 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 neces= sarily be ignored but if the interface is not yet configured (i.e. the IP l= ayer won't respond to packets) then the static/dhcp policy doesn't really m= atter until some component calls Configure() for the first time. > This is what I want to confirm with you that my understanding is right? Y= ou > 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/rec= eiving packets using the IP address. What we are asking for is a policy wh= ere we can suppress this behavior until the first Configure() call like bef= ore. > Of course not. I mean if my guessing 2) is correct, it's not reasonable b= ecause > UEFI 2.6 spec only defined Static/DHCP policy. The policy should be in on= e of > them. I just recalled the old Ip4Config behavior: no policy assigned defa= ult (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 consistenc= y since we've built up years of expectations from the previous implementati= on. > First, *based on the current UEFI Spec (only static / dhcp policy)*, I wa= nt to > highlight my understanding of *un-configured* status you mentioned: polic= y > 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: >=20 > First, register a notify for Ip4Config2 protocol in your Dxe Driver Entr= yPoint: > EfiCreateProtocolNotifyEvent ( > &gEfiIp4Config2ProtocolGuid, > TPL_CALLBACK, > Ip4Config2InstalledCallback, > NULL, > &Registration > ); >=20 > Then, In your Ip4Config2InstalledCallback() function, you can change the > default policy for the current boot: > Ip4Config2InstalledCallback () { > gBS->LocateProtocol ( > &gEfiIp4Config2ProtocolGuid, > Registration, > (VOID **) &Ip4Config2Instance > ); >=20 > // > // Change the policy to Ip4Config2PolicyDhcp to clean the static= setting. > // > Policy =3D Ip4Config2PolicyDhcp; > Ip4Config2Instance->SetData( > Ip4Config2Instanc= e, > Ip4Config2DataTyp= ePolicy, > sizeof (EFI_IP4_C= ONFIG2_POLICY), > &Policy > ); >=20 > // > // Change the policy to Ip4Config2PolicyStatic to clean the DHCP= policy > setting. > // > Policy =3D Ip4Config2PolicyStatic; > Ip4Config2Instance->SetData( > Ip4Config2Instanc= e, > Ip4Config2DataTyp= ePolicy, > sizeof (EFI_IP4_C= ONFIG2_POLICY), > &Policy > ); > } >=20 > 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 m= eet > 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 c= urrent 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 t= he PCD thing since we can do it now where the protocol approach will requir= e spec modification. Let me know if that makes sense - I'm prepared to provide a patch for the P= CD option if/when you're ready. Eugene