From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::72e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 792151A1E02 for ; Fri, 12 Aug 2016 05:31:27 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0290.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 12 Aug 2016 12:31:24 +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; Fri, 12 Aug 2016 12:31:24 +0000 From: "Cohen, Eugene" To: "Wu, Jiaxin" , "Ye, Ting" , "edk2-devel@lists.01.org" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hgABh+18A= Date: Fri, 12 Aug 2016 12:31:24 +0000 Message-ID: References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C63EC@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B7274137C63EC@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: 430f6114-84f4-4637-f67e-08d3c2ac9318 x-microsoft-exchange-diagnostics: 1; AT5PR84MB0290; 6:zsR0QqemZ7upte/Yjy3kodmHfkbHUip3Li6RoM8QqJKL4oWFa0ZLoSqE+4DwSArJ7MzP7bdxfDAxIacximph58sqdyM59vqSubUSbtFtVrHUkZzyAXtOmTBb0syinbXBsuQN7FQC8S7QMHpc/W3sbfYaQ8cJxIhf0u05aNHRzGmJwJB43ff6cCB/kXNbJWJ72QeIcldtfeFKG9/xHbXtcYyijdiJLRqTlaUgchzsqgyCnvjbxdUQynps/byEnMaX4NX3UehczhA4rJ1ye971MxFP9plX99qyKd+PoLeK5Ko=; 5:3nxiwhBpMgp4nTEtINFONE0ASuBVEs69jv/SgC46SD/Yypj0UHDjtMy6A7l/HrRpLztEvN5HhgQSO5m5dst/dk+jO84ap3oZzDYGwlQO6OevtvklmFHliAeC6NHsOShQCGNoqpEFijw5qv83H0bo0g==; 24:IQMpqrohUSIF4L4O70Yjo5PSP6bTXfdLD9+XE5bg6fmLuAejYR++P5YIZS3VB52uhd7HWPgLvH64VBpZysYMaNidAlGqfOC//98SKFRW5h4=; 7:ds5LURkeOqBJIZJi1LARWG9mz4bWTZcLgR9DAas6AtR/ypkYHMle1aeYvXgwaT+Zppl+T/m1OIqA0DPE/iaKN61MjQpLVyXYXEM6b1WWXbu3IEc/0r9v35D5X4osADxAYoZPZ7XQxMn701q4QwWuXDGvoDG23QRwHHT92/zRLT6IYzwhpijMKgu4ZTQMDPQxTELA+5HGnDLlSxxOLXHhYSbCPgBovp5HQOmZLFsBXkzHIxmfvqm591HwFlMV4DeP x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0290; 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)(8121501046)(5005006)(3002001)(10201501046); SRVR:AT5PR84MB0290; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0290; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(6602003)(199003)(189002)(9686002)(33656002)(106356001)(122556002)(105586002)(8936002)(561944003)(99286002)(101416001)(189998001)(107886002)(305945005)(97736004)(74316002)(7736002)(7696003)(5001770100001)(93886004)(5002640100001)(7846002)(3660700001)(10400500002)(2900100001)(87936001)(3280700002)(2950100001)(11100500001)(66066001)(2906002)(81156014)(8676002)(81166006)(50986999)(86362001)(92566002)(54356999)(76176999)(68736007)(3846002)(586003)(6116002)(102836003)(2501003)(77096005)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0290; 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: 12 Aug 2016 12:31:24.6210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0290 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: Fri, 12 Aug 2016 12:31:27 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 p= olicy > 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 co= nsistent with the original Ip4Config behavior? This seems like something t= hat should be doable - in my experiment suppressing the configuration in Ip= 4Config2OnDhcp4SbInstalled does exactly this so it seems like some addition= al 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? >=20 > 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 defa= ult > 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 t= his > 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 a= re saying that I should implement a platform policy driver that uses Ip4Con= fig2 to set an *unconfigured* state. But there is no definition for an "un= configured" state in UEFI 2.6 so how would one do this? Furthermore, would= n't this effectively delete the previous static IP data? Maybe I just don'= t understand what you're describing - perhaps some pseudocode for your prop= osal 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 setti= ngs, 2. automatic versus on-demand startup . Trying to to modify the IP ad= dress 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 swi= tch forums. Eugene