From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C40BD21A07A92 for ; Wed, 23 Jan 2019 08:08:46 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1188F58E4B; Wed, 23 Jan 2019 16:08:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-117.rdu2.redhat.com [10.10.120.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id 52E22601A4; Wed, 23 Jan 2019 16:08:45 +0000 (UTC) To: "Tomas Pilar (tpilar)" References: <6029fb15-3820-0f05-f02a-577e99592bbc@solarflare.com> Cc: "edk2-devel@lists.01.org" From: Laszlo Ersek Message-ID: <32137552-e2b0-4392-17c7-dedaa1f05244@redhat.com> Date: Wed, 23 Jan 2019 17:08:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6029fb15-3820-0f05-f02a-577e99592bbc@solarflare.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 23 Jan 2019 16:08:46 +0000 (UTC) Subject: Re: Network Stack Budgeting X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 16:08:47 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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