|
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.
Michael
[Prev in Thread] | Current Thread | [Next in Thread] |