From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZmrTQ-0000sG-F1 for mharc-grub-devel@gnu.org; Thu, 15 Oct 2015 18:58:12 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmrTC-0000qK-4E for grub-devel@gnu.org; Thu, 15 Oct 2015 18:57:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmrT8-00005r-Sb for grub-devel@gnu.org; Thu, 15 Oct 2015 18:57:58 -0400 Received: from duck.fensystems.co.uk ([2001:ba8:0:1d4::6950:5845]:47357) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmrT8-00005i-Lg for grub-devel@gnu.org; Thu, 15 Oct 2015 18:57:54 -0400 Received: from [10.0.0.133] (cpc3-cmbg15-2-0-cust24.5-4.cable.virginm.net [86.9.148.25]) by duck.fensystems.co.uk (Postfix) with ESMTPSA id D8E3E10208; Thu, 15 Oct 2015 23:57:52 +0100 (BST) Message-ID: <56202F70.3060000@ipxe.org> Date: Thu, 15 Oct 2015 23:57:52 +0100 From: Michael Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andrew Fish , Laszlo Ersek Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling References: <20151001.182655.371384337.d.hatayama@jp.fujitsu.com> <560D1E07.3090902@redhat.com> <20151013214919.GA6140@router-fw-old.local.net-space.pl> <561D83E9.6050703@redhat.com> <20151014110847.GQ6226@olila.local.net-space.pl> <1BAD7DA9-D60E-4743-9143-3327989DF6B6@oracle.com> <561FED1C.7050801@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:ba8:0:1d4::6950:5845 Cc: The development of GNU GRUB , "Ye, Ting" , edk2-devel-01 , "arvidjaar@gmail.com" , "glin@suse.com" , Seth Goldberg , Mark Salter X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 22:57:59 -0000 On 15/10/15 23:33, Andrew Fish wrote: > The EFI Driver Model, lets you connect and disconnect, drivers as neede= d. The EFI networking stack supports the EFI Manged Network Protocol to h= elp manage the network stack configuration. This is what was intended for= normal operation. > > I=E2=80=99m just guessing but the iPXE developers have to deal with mul= tiple environments (Legacy BIOS, EFI, =E2=80=A6) and probably picked a pa= th that allowed all these =E2=80=9Cworlds=E2=80=9D 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 networ= king stack (iPXE) trying to make it as common as possible in all its vari= ous 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,=20 by using as few of the firmware-provided facilities as possible. If we=20 have a native iPXE driver for the NIC hardware then we will explicitly=20 rip out any attached MNP, SNP and NII drivers, plug ourselves in (via=20 the UEFI driver model) as the driver for the underlying PCI device, and=20 control the hardware directly. If we don't have a native driver (e.g.=20 in snponly.efi) then we'll fall back to ripping out just MNP and SNP and=20 taking exclusive ownership of the NII device. 2. We actually care about performance. A "good" MNP-attached driver=20 might be able to achieve 10Mbps on a 1000Mbps NIC. We expect to achieve=20 the full 1000Mbps in iPXE. However, the fact that iPXE takes exclusive ownership of the underlying=20 device should not matter, because we always expose a new device handle=20 onto which we install SNP, NII, PxeBc, LoadFile, etc. Whatever we load=20 will be given this new handle as the DeviceHandle. Michael