Re: Network Stack Budgeting

[Laszlo Ersek <lersek@redhat.com>]

Hi,

On 01/23/19 11:55, Tomas Pilar (tpilar) wrote:
> Hi,
> 
> Recently I have done some performance improvements to my network
> driver. I am however finding that on some platforms, it's becoming
> impossible to boot if the network cable has a lot of traffic on it
> that is not filtered by the NIC itself (broadcast, multicast or
> directed unicast). It would seem the platform hangs in the DXE phase
> trying to process (drop) all the packets and not progressing through
> the boot order.
> 
> I am wondering if anyone has seen similar behaviour. Does the network
> stack have any budgeting?
> 
> Ideally this would be fixed by the network stack not calling
> Snp.Start() until in the BDS phase but it seems most platforms just
> call Snp.Start() immediately following the driver probe.

this is a platform BDS issue, on those platforms where you see the
symptom.

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.

It is convenient for a platform BDS implementation to just connect all
drivers to all devices, regardless of what devices are actually going to
be booted. Unfortunately, as the number of devices grows (or the traffic
grows, as you say), the boot performance worsens.

In OVMF and ArmVirtQemu, we saw pretty dramatic gains when we switched
from the simple+convenient approach to a bit smarter/selective approach.
And once we had fixed all the regressions too :) , it was a net win.

(Regressions because, once you switch the policy from "blanket connect"
to "specific connect", it is easy to forget about devices that are not
really "boot" devices, but you still might want to connect them in every
case. Consider a USB keyboard, or a hardware entropy device, for
example. After the switch, you have to connect those individually.)

Thanks,
Laszlo