From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.60; helo=ma1-aaemail-dr-lapp01.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 349E6211B85C2 for ; Wed, 23 Jan 2019 09:47:34 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x0NHl3ht008877; Wed, 23 Jan 2019 09:47:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=r2aTxjriUFRWxbLgvcpUAgapVSvWsxndhTR2SXbQRzo=; b=EzhNHsKCbsDCVe4hpFil8LNaZZocRa1cNZClYe0qvxufrPWFzCHcux3R8td6hK7sDE/Z x1jnmnBmTEe47n0cSivg7dQvzeE12MHNkTHQXL0rpb84CuOVGBRvyUsQ9FWhgpcKnnH2 ssIggPI9lPuFd6l6ycQe4HuAvP83Z/T6ksi4k30yfqaKKGnof4G4pBL1s88L4nUNE9Jy +o0aGAXQSnN5lD/F8LYHJYA2Ox1AwuLwjgLqubjc3XQiZeekT9pXJQwzbzRsXA/QMBo2 FjGlk4uTeDsIH5v8qZ99HZw2jPFTY5tGUouJxe+LSuiz+itMjpi19dulhewK+3voGGi3 pw== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2q43eadvu4-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 Jan 2019 09:47:32 -0800 MIME-version: 1.0 Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PLS000YGPF8IJ70@ma1-mtap-s01.corp.apple.com>; Wed, 23 Jan 2019 09:47:32 -0800 (PST) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PLS00800ORS2E00@ma1-mmpp-sz09.apple.com>; Wed, 23 Jan 2019 09:47:32 -0800 (PST) X-Va-A: X-Va-T-CD: 57f65681c8f990e36c5c6358a8ab2ec3 X-Va-E-CD: d080515ea44876d110e33b50d2056f7c X-Va-R-CD: e019999c2a8d6011ae4b35d16aab8446 X-Va-CD: 0 X-Va-ID: 40d5c0cd-0aab-45f1-a175-e8727e139c08 X-V-A: X-V-T-CD: 57f65681c8f990e36c5c6358a8ab2ec3 X-V-E-CD: d080515ea44876d110e33b50d2056f7c X-V-R-CD: e019999c2a8d6011ae4b35d16aab8446 X-V-CD: 0 X-V-ID: eae9d4b0-5d38-4cfa-b862-3857c4908abd Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PLS00J00P21ZZ00@ma1-mmpp-sz09.apple.com>; Wed, 23 Jan 2019 09:47:32 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-23_09:,, signatures=0 Received: from [17.234.213.35] (unknown [17.234.213.35]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PLS009TCPF5TE20@ma1-mmpp-sz09.apple.com>; Wed, 23 Jan 2019 09:47:31 -0800 (PST) Sender: afish@apple.com From: Andrew Fish In-reply-to: <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> Date: Wed, 23 Jan 2019 09:47:00 -0800 Cc: Laszlo Ersek , "edk2-devel@lists.01.org" Message-id: References: <6029fb15-3820-0f05-f02a-577e99592bbc@solarflare.com> <32137552-e2b0-4392-17c7-dedaa1f05244@redhat.com> <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> To: "Tomas Pilar (tpilar)" X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-23_09:, , signatures=0 Subject: Re: Network Stack Budgeting X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 17:47:34 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Jan 23, 2019, at 8:27 AM, Tomas Pilar (tpilar) wrote: > > >> The set of devices connected during BDS is platform policy. It is not >> the "network stack" that calls Snp.Start(), but the platform BDS code >> that calls gBS->ConnectController() on the device, possibly without a >> good reason (e.g. without the device being present in a UEFI boot >> option). The network stack only "reacts" to that connection request. > Indeed, but even if a SNP handle is present as a boot option in a boot manager, surely the Snp.Start() should be deferred until the user actually chooses to boot from that handle. > Tom, You don't need to call gBS->ConnectController() on all possible boot options, just the one you are currently trying to boot. I mostly muck around in a non edk2 BDS, but in general what you do in a BDS is: 1) Connect your graphics console(s) (usually involves ConOut NVRAM) 3) Connect any serial consoles (ConIn/ConOut NVRAM). 2) Connect any built in keyboard, maybe SPI etc. (ConIn NVRAM). 4) Connect any hot pluggable console devices (Connect any existing USB HID devices). 5) Connect any other device required in the boot path (like the example entropy device. The platform can have policy to force values into ConIn/ConOut. For example on a laptop maybe you always want the built in keyboard active. As you attempt to boot a boot option you can recursively connect the device path for that boot option and attempt to boot it. If that option fails you can fall back to the next boot option and try to connect that device path and boot. Thus you don't need to start things before you are ready. If you launch Firmware Setup that usually does a Connect All. The same things happen when you launch the Shell. Also some drivers connect extra stuff. For example when you try to connect a specific PCI device all the PCI IO handles get created. This is just how you have to enumerate PCI. But the recursive connect should only happen on the PCI IO handle you care about. Thanks, Andrew Fish > A workaround that we have in the legacy implementation doesn't start the underlying hardware datapath until the platform tries to send the first packet (since PXE boot is always initiated by the client) but that is a horrible hack that should not be necessary. The distinction between Snp.Initialize() and Snp.Start() is there exactly for that reason, no? > > In other words, ConnectController() should not immediately result in Snp.Start() being called. > > Cheers, > Tom > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel