Re: Network Stack Budgeting

[Laszlo Ersek <lersek@redhat.com>]

On 01/23/19 17:27, Tomas Pilar (tpilar) wrote:
>
>> 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.

Yes, I agree. As far as I remember, UefiBootManagerLib is compatible
with that idea (it makes sure the device path is connected before the
boot is attempted). So again, the deferral you suggest applies to
platform BDS.

> 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?

That's a good question; if someone finds the answer, please let me too
know! :)

> In other words, ConnectController() should not immediately result in
> Snp.Start() being called.

Hmm, now that you put it like this, it's hard for me to comment on this
specific statement. I'm unsure if the higher level network drivers can
do their jobs (i.e. just bind the device) without calling Snp.Start(). I
haven't implemented anything higher level than SNP; I'm not sure about
MNP etc. internals. I do admit your original point makes a lot more
sense to me now.

Can you capture a call stack when Snp.Start() is invoked for the very
first time (which, IIUC, is a call that should not happen, in your
opinion)?

Thanks
Laszlo