From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=148.163.129.52; helo=dispatch1-us1.ppe-hosted.com; envelope-from=tpilar@solarflare.com; receiver=edk2-devel@lists.01.org Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5F6E22194D387 for ; Thu, 24 Jan 2019 09:43:30 -0800 (PST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 2F7CA80077; Thu, 24 Jan 2019 17:43:29 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Jan 2019 09:43:26 -0800 To: Laszlo Ersek , References: <6029fb15-3820-0f05-f02a-577e99592bbc@solarflare.com> <32137552-e2b0-4392-17c7-dedaa1f05244@redhat.com> <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> <67f8fb4a-5e1b-8bbc-90d4-670ff7e3bfe8@redhat.com> <5185c0b2-031f-ec50-b273-2665d83ef38a@solarflare.com> <923ebd9f-ef26-c96d-37cc-5cc76f88fea1@solarflare.com> <770c5b55-32b1-c2f3-f3de-b25de5f2b37d@solarflare.com> From: "Tomas Pilar (tpilar)" Message-ID: <841c4437-ad73-64d5-0eb8-cfc0220cc55d@solarflare.com> Date: Thu, 24 Jan 2019 17:43:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.17.20.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24386.005 X-TM-AS-Result: No-7.889200-4.000000-10 X-TMASE-MatchedRID: cgbqQT5W8hcOwH4pD14DsPHkpkyUphL9RoVmvTpct19zwVmY5TMrNp9Z IgQn42BdDaGRBuA6l4p0zaPZZ+rssIYVwcymvpbabc297PAGtWaBHKTJ+sfXGTCmUYns3FLTG0A D4IFm/o+kOly3J8TT9gMISN0gIPIo9IFaGoD8AGe3UCG/IQp2PrfoYZ/CMuhlmyiLZetSf8nJ4y 0wP1A6AEl4W8WVUOR/9xS3mVzWUuCgZHIBpyeFpi+bVt8ApQenYyRlzAIHNfZl1XgVt87yRa3/U eweOmDeftwZ3X11IV0= X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--7.889200-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24386.005 X-MDID: 1548351809-o8w4Qces_JUG 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: Thu, 24 Jan 2019 17:43:30 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US On 24/01/2019 16:49, Laszlo Ersek wrote: > On 01/24/19 14:25, Tomas Pilar (tpilar) wrote: >> Hmm, >> >> Mnp->Configure() will eventually call MnpStartSnp(). >> >> A grep for Mnp->Configure shows that: >> * ArpDxe performs this on DriverBinding.Start() >> * Ip6Dxe performs this on DriverBinding.Start() >> >> Ipv4 and DnsDhcp do this as a part of their Configure() they expose in the API. > Yes, that makes sense. All of the above drivers are UEFI drivers that > follow the UEFI driver model, AIUI. As long as the controller is not > connected from BDS, no BindingStart() function should be called in these. Ah, but I would expect the BDS to call ConnectController() on the NIC, but I would not expect the network stack to be started unless the device is actually chosen for PXE booting. In other words, the above protocols should follow the example of EFI_DNS4_PROTOCOL that binds against the device during BDS but .Configure() is not automatically called by DriverBinding.Start(). .Configure() should be called by the BootManager if networking is actually to be done. That in turn will configure Mnp and start Snp. Cheers, Tom