From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 DCDE2211B5A21 for ; Wed, 23 Jan 2019 14:18:47 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 707963E2B7; Wed, 23 Jan 2019 22:18:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-117.rdu2.redhat.com [10.10.120.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id B84EA2655A; Wed, 23 Jan 2019 22:18:46 +0000 (UTC) To: "Tomas Pilar (tpilar)" Cc: "edk2-devel@lists.01.org" References: <6029fb15-3820-0f05-f02a-577e99592bbc@solarflare.com> <32137552-e2b0-4392-17c7-dedaa1f05244@redhat.com> <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> From: Laszlo Ersek Message-ID: <67f8fb4a-5e1b-8bbc-90d4-670ff7e3bfe8@redhat.com> Date: Wed, 23 Jan 2019 23:18:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 23 Jan 2019 22:18:47 +0000 (UTC) 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 22:18:48 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/23/19 17:27, 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. Yes, I agree. As far as I remember, UefiBootManagerLib is compatible with that idea (it makes sure the device path is connected before the boot is attempted). So again, the deferral you suggest applies to platform BDS. > 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? That's a good question; if someone finds the answer, please let me too know! :) > In other words, ConnectController() should not immediately result in > Snp.Start() being called. Hmm, now that you put it like this, it's hard for me to comment on this specific statement. I'm unsure if the higher level network drivers can do their jobs (i.e. just bind the device) without calling Snp.Start(). I haven't implemented anything higher level than SNP; I'm not sure about MNP etc. internals. I do admit your original point makes a lot more sense to me now. Can you capture a call stack when Snp.Start() is invoked for the very first time (which, IIUC, is a call that should not happen, in your opinion)? Thanks Laszlo