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 3474E211B5074 for ; Mon, 28 Jan 2019 03:24:23 -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 B8341BC0071; Mon, 28 Jan 2019 11:24:22 +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; Mon, 28 Jan 2019 03:24:19 -0800 To: "Fu, Siyuan" , "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> <642a0352-e098-dc90-c9aa-89443a7dde04@solarflare.com> From: "Tomas Pilar (tpilar)" Message-ID: <8ef796a4-c3f1-d97a-03c8-add7ff6430b6@solarflare.com> Date: Mon, 28 Jan 2019 11:24:17 +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-24394.005 X-TM-AS-Result: No-31.453900-4.000000-10 X-TMASE-MatchedRID: qsaWi0FWcYtHJXeB0puIo4oFxrBKEta+kl4MQpJlkCeNWmd/X7Lsp2ci CXrpX1+MN6E3uBquixR27XFnI6Ei9EsObkHGCTItgOqr/r0d+CwrHkgIan9a0W3D6f6IpbLIlkM AUyMNwq1wIeCaHTsQe+5W/id0aKy288yy6w9hfpXpnOP6QxEGtoyzstdwoG+P2nVuImEjI1Fdrb 7MTVw/5cBru+dXHVeTuH6butSFa9hmiY/RUC4RXsWUKBjERoYTCt59Uh3p/NUNht78/JfyBNoaO geQoofzqucTI3xqim4szNg2yd3iUBKz3vhHKFOLw69AIwXJn0Zeu73mFK6GNGGVufr+eY4vuwhq yc+q/JB1eyBHqyG9N2MuidnbeZKRfamNiXdYMbVTdqZ2L9mRu74HS0k2HeOoftq1M+x2V25BuMv AeJg95cxnxEmdJwsWryQEGJSaI1q+insCPcWTgeYAh37ZsBDCGbJMFqqIm9yjzLkLKlTV4QJa2X d8YTV/or8neCbzSXmSbrMwz/bWNgzT4Da6T1Ad7TLIvnWov9GBHKTJ+sfXGTopMvfWgSSuAAYph KUA0Ktfl+0NHEzGvJ6q+LdvVyEWYWo9dIuk10Ac8J6ZrWP/q30tCKdnhB58vqq8s2MNhPCy5/tF Zu9S3K85Gjho6PlWC24oEZ6SpSk+Mqg+CyrtwA== X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--31.453900-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24394.005 X-MDID: 1548674662-4TnnrGmmOV_G 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: Mon, 28 Jan 2019 11:24:24 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US Hi Siyuan, I had to do some tweaks due to the fact that people in the wild want to PXE boot whole WDS installations which are upwards of 300MB. I have an internal set of queues where the NIC receives into. Snp.Receive() will get a packet from this store. I had to implement a separate queue for unicast/multicast/broadcast traffic so that I could reprioritise and deliver unicast traffic while under ARP spam. I tied internal poll to receive and transmit, so Snp.Receive() will poll the NIC and then dequeue a packet while Snp.Transmit() will transmit the packet and then poll the NIC to get a completion. I also implemented a busy poll for 100us or until the next packet comes in when the NIC is polled. Otherwise I have seen a pathological case where the TFTP client would pull one packet per second but the TFTP_RETRANSMIT interval on the server was also one second and everything was awful. In theory the busy poll moderator might cause an issue in a pathological case, if it stalls the machine for 100us for each packet - with 100 packets per second this would eat only 10ms. Cheers, Tom On 27/01/2019 14:28, Fu, Siyuan wrote: > Hi, Tom > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tomas >> Pilar (tpilar) >> Sent: Friday, January 25, 2019 8:09 PM >> To: Wu, Jiaxin ; Laszlo Ersek ; edk2- >> devel@lists.01.org >> Cc: Ye, Ting >> Subject: Re: [edk2] Network Stack Budgeting >> >> 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). > It's true that a configured MNP will start a background system poll to receive > network packets, but normally it won't lead to a DoS, because the receive frequency > is actually very low. The MNP driver only tries to receive 1 packet from SNP for every > 10 milliseconds (see MNP_SYS_POLL_INTERVAL, MnpSystemPoll() and related timer event). > So no matter how heavy the network is, MNP driver (and upper layer stack) will > only process at most 100 packets per second, all other packets should be dropped > by UNDI driver directly. > > So if there is nobody doing busy network receiving, the network stack cost will be > at most 100 packets per NIC device and per second. > > In your first email you mentioned "some performance improvements to my network driver", > may I know what's the improvement method you are using? > > Best Regards, > Siyuan > >> 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 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel