From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=67.231.154.164; 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 [67.231.154.164]) (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 9F354211BA46A for ; Fri, 25 Jan 2019 04:08:49 -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-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 3E570980067; Fri, 25 Jan 2019 12:08:48 +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; Fri, 25 Jan 2019 04:08:44 -0800 To: "Wu, Jiaxin" , Laszlo Ersek , "edk2-devel@lists.01.org" CC: "Ye, Ting" 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> <841c4437-ad73-64d5-0eb8-cfc0220cc55d@solarflare.com> <895558F6EA4E3B41AC93A00D163B727416ECCDAA@SHSMSX107.ccr.corp.intel.com> From: "Tomas Pilar (tpilar)" Message-ID: <642a0352-e098-dc90-c9aa-89443a7dde04@solarflare.com> Date: Fri, 25 Jan 2019 12:08:41 +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: <895558F6EA4E3B41AC93A00D163B727416ECCDAA@SHSMSX107.ccr.corp.intel.com> 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-19.789100-4.000000-10 X-TMASE-MatchedRID: fE0JoqABJp0rQ4Lf8bCdwcWUKBjERoYTCt59Uh3p/NWCsBeCv8CM/aih IMAiqqaO2z651pu/qKDZPgFjQ9UkP5Rho78T5P9D2OSj4qJA9QYxRS4RlA/AFg1xyQQ/F/PYg/5 gNr8OG71dF+U7o9Hw5+j8qvLSpEcnTU8AcGDtvC9K2kj7j4ouAJsqkCVjbLpJbcPp/oilssjldO a+b1x+LDFxJ+DPhnFrECCKlTUA4sGXbmjEpvtB85VRzPxemJL0RoVmvTpct19zwVmY5TMrNp9ZI gQn42BdDaGRBuA6l4p0zaPZZ+rssIYVwcymvpbaVU3yVpaj3QyVq+okl1rYDzopMvfWgSSuAAYp hKUA0Ktfl+0NHEzGvJ6q+LdvVyEWYWo9dIuk10Ac8J6ZrWP/q30tCKdnhB58vqq8s2MNhPCy5/t FZu9S3Ku6xVHLhqfxwrbXMGDYqV8CpgETeT0ynA== X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--19.789100-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24386.005 X-MDID: 1548418128-w5l71QBCD7sl 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: Fri, 25 Jan 2019 12:08:49 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US Yeah, that makes sense I suppose. The end result is however that the network device is 'opened' as soon as ConnectController() is called rather than when someone wants to do networking. This seems wrong and directly leads to a DoS of a platform in case of heavy network load (unless we implement budgeting in the network driver, which is a really not what it should be doing). How do you suggest we solve this problem? Cheers, Tom On 25/01/2019 08:44, Wu, Jiaxin wrote: > Hi Tom, > > One thing I want to highlight is that our design of network stack is not only for the PXE/HTTP boot trigged in BootManager, but also to make sure it's workable once there is any MNP instance configured by upper drivers (ARP/IPv4/IPv6). > > Take ARP/IP as an example, once ARP/IP are started, we need a heartbeat to process any ARP requests, which is required by ARP functionality. In such a case, SNP must be started to make ARP/IP drivers works well. > > Thanks, > Jiaxin > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >> Tomas Pilar (tpilar) >> Sent: Friday, January 25, 2019 1:43 AM >> To: Laszlo Ersek ; edk2-devel@lists.01.org >> Subject: Re: [edk2] Network Stack Budgeting >> >> >> >> 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 >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel