From: "Fu, Siyuan" <siyuan.fu@intel.com>
To: "Tomas Pilar (tpilar)" <tpilar@solarflare.com>,
"Wu, Jiaxin" <jiaxin.wu@intel.com>,
Laszlo Ersek <lersek@redhat.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Ye, Ting" <ting.ye@intel.com>
Subject: Re: Network Stack Budgeting
Date: Sun, 27 Jan 2019 14:28:14 +0000 [thread overview]
Message-ID: <B1FF2E9001CE9041BD10B825821D5BC58B6DF0DF@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <642a0352-e098-dc90-c9aa-89443a7dde04@solarflare.com>
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 <jiaxin.wu@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
> devel@lists.01.org
> Cc: Ye, Ting <ting.ye@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-bounces@lists.01.org] On Behalf Of
> >> Tomas Pilar (tpilar)
> >> Sent: Friday, January 25, 2019 1:43 AM
> >> To: Laszlo Ersek <lersek@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
next prev parent reply other threads:[~2019-01-27 14:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 10:55 Network Stack Budgeting Tomas Pilar (tpilar)
2019-01-23 14:14 ` Ye, Ting
2019-01-23 14:51 ` Tomas Pilar (tpilar)
2019-01-23 16:08 ` Laszlo Ersek
2019-01-23 16:27 ` Tomas Pilar (tpilar)
2019-01-23 17:47 ` Andrew Fish
2019-01-23 22:18 ` Laszlo Ersek
2019-01-24 11:37 ` Tomas Pilar (tpilar)
2019-01-24 12:25 ` Laszlo Ersek
2019-01-24 12:58 ` Tomas Pilar (tpilar)
2019-01-24 13:25 ` Tomas Pilar (tpilar)
2019-01-24 16:49 ` Laszlo Ersek
2019-01-24 17:43 ` Tomas Pilar (tpilar)
2019-01-25 8:44 ` Wu, Jiaxin
2019-01-25 12:08 ` Tomas Pilar (tpilar)
2019-01-27 14:28 ` Fu, Siyuan [this message]
2019-01-28 11:24 ` Tomas Pilar (tpilar)
2019-01-29 3:20 ` Fu, Siyuan
2019-01-29 10:54 ` Tomas Pilar (tpilar)
2019-01-29 13:06 ` Fu, Siyuan
2019-01-29 13:12 ` Tomas Pilar (tpilar)
2019-01-29 13:42 ` Laszlo Ersek
2019-01-29 13:52 ` Tomas Pilar (tpilar)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B1FF2E9001CE9041BD10B825821D5BC58B6DF0DF@SHSMSX103.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox