[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [edk2] [grub PATCH] efinet: disable MNP background polling

From: Michael Brown
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling
Date: Thu, 15 Oct 2015 23:57:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 15/10/15 23:33, Andrew Fish wrote:
The EFI Driver Model, lets you connect and disconnect, drivers as needed. The 
EFI networking stack supports the EFI Manged Network Protocol to help manage 
the network stack configuration. This is what was intended for normal operation.

I’m just guessing but the iPXE developers have to deal with multiple 
environments (Legacy BIOS, EFI, …) and probably picked a path that allowed all 
these “worlds” to have a similar code flow. So the EFI OpenProtocol  EXCLUSIVE 
probably mapped into the other flows where iPXE just takes over. If you are 
maintaining a complex networking stack (iPXE) trying to make it as common as 
possible in all its various ports does not seem like an unreasonable goal, but 
you might not end up with the ideal implementation for each environment.

That's part of it.  Other important reasons are:

1. We want to minimise our exposure to buggy firmware implementations, by using as few of the firmware-provided facilities as possible. If we have a native iPXE driver for the NIC hardware then we will explicitly rip out any attached MNP, SNP and NII drivers, plug ourselves in (via the UEFI driver model) as the driver for the underlying PCI device, and control the hardware directly. If we don't have a native driver (e.g. in snponly.efi) then we'll fall back to ripping out just MNP and SNP and taking exclusive ownership of the NII device.

2. We actually care about performance. A "good" MNP-attached driver might be able to achieve 10Mbps on a 1000Mbps NIC. We expect to achieve the full 1000Mbps in iPXE.

However, the fact that iPXE takes exclusive ownership of the underlying device should not matter, because we always expose a new device handle onto which we install SNP, NII, PxeBc, LoadFile, etc. Whatever we load will be given this new handle as the DeviceHandle.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]