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 7B49A211BB8CD for ; Tue, 29 Jan 2019 05:42:06 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CA3AB86677; Tue, 29 Jan 2019 13:42:05 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-45.rdu2.redhat.com [10.10.121.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83D9219487; Tue, 29 Jan 2019 13:42:02 +0000 (UTC) To: "Tomas Pilar (tpilar)" , "Fu, Siyuan" , "Wu, Jiaxin" , "edk2-devel@lists.01.org" Cc: "Ye, Ting" References: <6029fb15-3820-0f05-f02a-577e99592bbc@solarflare.com> <32137552-e2b0-4392-17c7-dedaa1f05244@redhat.com> <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> <67f8fb4a-5e1b-8bbc-90d4-670ff7e3bfe8@redhat.com> <5185c0b2-031f-ec50-b273-2665d83ef38a@solarflare.com> <923ebd9f-ef26-c96d-37cc-5cc76f88fea1@solarflare.com> <770c5b55-32b1-c2f3-f3de-b25de5f2b37d@solarflare.com> <841c4437-ad73-64d5-0eb8-cfc0220cc55d@solarflare.com> <895558F6EA4E3B41AC93A00D163B727416ECCDAA@SHSMSX107.ccr.corp.intel.com> <642a0352-e098-dc90-c9aa-89443a7dde04@solarflare.com> <8ef796a4-c3f1-d97a-03c8-add7ff6430b6@solarflare.com> <197303c9-8af5-6092-afe1-404cf86dd800@solarflare.com> From: Laszlo Ersek Message-ID: <24080ea2-e564-69dd-73dd-ecbb5435f653@redhat.com> Date: Tue, 29 Jan 2019 14:42:01 +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: <197303c9-8af5-6092-afe1-404cf86dd800@solarflare.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 29 Jan 2019 13:42:05 +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: Tue, 29 Jan 2019 13:42:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 01/29/19 11:54, Tomas Pilar (tpilar) wrote: >> Why TFTP client just pull one packet per second? I think it’s not >> correct and it could use the poll() function to accelerate the >> receive. Why you trying to solve a TFTP layer problem in SNP layer? >> It breaks the design principle of network layer model. > Yes, I appreciate the principle. However, in practice we don't get to > sell adapters that do not PXE boot and it's pointless to argue with > customers that they have a rubbish TFTP client implementation. So we > put in workarounds into the driver. Actually, I think this is the core principle behind the UEFI forum, and the UEFI spec. You shouldn't have to implement bug compat hacks. The era when an add-on card would work on some platform's BIOS but not on another's should be left behind. You have a spec to point at, and the platform in question was likely certified against that spec in some form (possibly self-certified). Sp I think it would be reasonable to contact the platform vendor, and to direct your own customers to that ticket too. If you have a representative on the USWG, it might make sense to raise the issue there as well, especially if the issue is wide-spread and affects multiple platform vendors. The UEFI spec targets practical, common use cases, and this looks like one. (When a RH customer or partner reports e.g. a RHEL kernel issue to us, and we determine it is a problem in the firmware, we absolutely talk to the platform vendor, and sometimes to standards bodies too. We also advise customers on the applications that they run on RHEL, if they ask and/or care to listen. Plus, some high-profile applications and RHEL are explicitly certified against each other.) ... I don't mean to intrude of course; I'm sorry if I came through like that. Thanks Laszlo