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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
