Re: Network Stack Budgeting

["Tomas Pilar (tpilar)" <tpilar@solarflare.com>]

> This reeks. :)
>
> It looks like some driver in the platform sets up a protocol notify
> callback for SNP, with gBS->CreateEvent() +
> gBS->RegisterProtocolNotify(). Your driver's DriverBindingStart()
> function is called normally from BDS, via ConnectController(). In
> DriverBindingStart(), you install an SNP instance, which signals the
> event (makes it pending / queues the notification function for it). Once
> you drop the TPL again, the notification function is called, on the
> stack of gBS->RestoreTPL().
>
> The event's notification funciton probably uses the "Registration"
> feature of gBS->RegisterProtocolNotify(), together with
> gBS->LocateProtocol(), to process only those SNP instances that it
> hasn't seen yet. In other words, it catches exactly the SNP instance
> that your driver just produced, and then it calls the Start() member of it.

This was my assumption a well. I did not consider that another third party driver could be the cause of this.
> I've now run
>
>   git grep -A10 -B10 -w gEfiSimpleNetworkProtocolGuid
>
> on edk2, and then searched the output for "RegisterProtocolNotify".
> There were no hits. So, I don't think anything in edk2 behaves like
> described above (thankfully!).
That's good to know, I was going to have a browse through the edk2 network stack but this is reassuring.
>
> You mentioned seeing this on "DELL 13G platforms". I suggest opening a
> support case with Dell.
The problem is much more widespread than that. This log is from a HP gen 10 server. I am pretty sure the DELL 14G also has the same behaviour. That's what originally led me to think it might be in upstream.

Cheers,
Tom