Hi, Tom > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas > Pilar (tpilar) > Sent: Friday, January 25, 2019 8:09 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; Laszlo Ersek <ler...@redhat.com>; edk2- > de...@lists.01.org > Cc: Ye, Ting <ting...@intel.com> > 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-boun...@lists.01.org] On Behalf Of > >> Tomas Pilar (tpilar) > >> Sent: Friday, January 25, 2019 1:43 AM > >> To: Laszlo Ersek <ler...@redhat.com>; 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
