From: "Tomas Pilar (tpilar)" <tpilar@solarflare.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: Network Stack Budgeting
Date: Wed, 23 Jan 2019 16:27:03 +0000 [thread overview]
Message-ID: <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> (raw)
In-Reply-To: <32137552-e2b0-4392-17c7-dedaa1f05244@redhat.com>
> The set of devices connected during BDS is platform policy. It is not
> the "network stack" that calls Snp.Start(), but the platform BDS code
> that calls gBS->ConnectController() on the device, possibly without a
> good reason (e.g. without the device being present in a UEFI boot
> option). The network stack only "reacts" to that connection request.
Indeed, but even if a SNP handle is present as a boot option in a boot manager, surely the Snp.Start() should be deferred until the user actually chooses to boot from that handle.
A workaround that we have in the legacy implementation doesn't start the underlying hardware datapath until the platform tries to send the first packet (since PXE boot is always initiated by the client) but that is a horrible hack that should not be necessary. The distinction between Snp.Initialize() and Snp.Start() is there exactly for that reason, no?
In other words, ConnectController() should not immediately result in Snp.Start() being called.
Cheers,
Tom
next prev parent reply other threads:[~2019-01-23 16:27 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) [this message]
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
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=09017041-d418-1186-9942-dfa70d82c4d6@solarflare.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