From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.151; helo=mga17.intel.com; envelope-from=siyuan.fu@intel.com; receiver=edk2-devel@lists.01.org Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 C17CA211B6C38 for ; Sun, 27 Jan 2019 06:28:18 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2019 06:28:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,530,1539673200"; d="scan'208";a="139194108" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 27 Jan 2019 06:28:17 -0800 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 27 Jan 2019 06:28:17 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 27 Jan 2019 06:28:16 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.194]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.190]) with mapi id 14.03.0415.000; Sun, 27 Jan 2019 22:28:15 +0800 From: "Fu, Siyuan" To: "Tomas Pilar (tpilar)" , "Wu, Jiaxin" , Laszlo Ersek , "edk2-devel@lists.01.org" CC: "Ye, Ting" Thread-Topic: [edk2] Network Stack Budgeting Thread-Index: AQHUswuHflmTSIZRT0GRThV4ftMA96W8f6AAgAAFHoCAAGJEgIAA3z4AgAANYgCAAAkvAIAAB4QAgAA46ICAAA8rAIAA+62AgAA5I4CAA8xroA== Date: Sun, 27 Jan 2019 14:28:14 +0000 Message-ID: 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> In-Reply-To: <642a0352-e098-dc90-c9aa-89443a7dde04@solarflare.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWI5MWQyYzQtYjlhZC00ZTllLTk5YTYtZTZiODM4NmNlM2YyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidzZWc0l0cFZVUG9kOEhiRENIWm1IaW5OMjg0am9xSkhOZ3NWblBcLzVpbzhNVXpkQ05pU3o2aE9xZGE5Q1NpeFYifQ== dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.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: Sun, 27 Jan 2019 14:28:19 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Tom > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of To= mas > Pilar (tpilar) > Sent: Friday, January 25, 2019 8:09 PM > To: Wu, Jiaxin ; Laszlo Ersek ; e= dk2- > devel@lists.01.org > Cc: Ye, Ting > Subject: Re: [edk2] Network Stack Budgeting >=20 > Yeah, that makes sense I suppose. The end result is however that the netw= ork > device is 'opened' as soon as ConnectController() is called rather than w= hen > 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 budgetin= g 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 rece= ive network packets, but normally it won't lead to a DoS, because the receive f= requency=20 is actually very low. The MNP driver only tries to receive 1 packet from SN= P for every 10 milliseconds (see MNP_SYS_POLL_INTERVAL, MnpSystemPoll() and related tim= er event). So no matter how heavy the network is, MNP driver (and upper layer stack) w= ill only process at most 100 packets per second, all other packets should be dr= opped 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 netw= ork driver", may I know what's the improvement method you are using? Best Regards, Siyuan >=20 > How do you suggest we solve this problem? >=20 > Cheers, > Tom >=20 > 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 no= t > 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 th= ese. > >> 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 s= hould > >> 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 actu= ally > 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 >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel