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 3F52B211C8332 for ; Mon, 4 Feb 2019 08:54:23 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CD785AFC3F; Mon, 4 Feb 2019 16:54:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-118-250.phx2.redhat.com [10.3.118.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id C49715BBD2; Mon, 4 Feb 2019 16:54:21 +0000 (UTC) To: Sajeesh Kk Cc: Rafael Machado , edk2-devel@lists.01.org References: <18b7cdf5-8569-ab69-fc19-21da7ce2b1ea@redhat.com> From: Laszlo Ersek Message-ID: Date: Mon, 4 Feb 2019 17:54:20 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 04 Feb 2019 16:54:22 +0000 (UTC) Subject: Re: BlockIo2 Protocol test tool 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: Mon, 04 Feb 2019 16:54:24 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/02/19 08:05, Sajeesh Kk wrote: > Hello Laszlo, > > Thanks for the quick response. I have some doubts regarding > "TransactionStatus" that should be signaled by the driver when an IO > operation is completed. If my understanding is not correct please educate. > > 1. As per UEFI spec, the error codes EFI_DEVICE_ERROR, EFI_NO_MEDIA, > EFI_MEDIA_CHANGED or EFI_WRITE_PROTECTED should not be signaled when non > Blocking IO is being used. so if an IO fails, the driver should not signal > the event as per the spec. if this is the case, > the event should be signaled only when IO is completed successfully ? My understanding is that there are three cases: (1) The IO completes successfully. In this case, the completion notification is asynchronous (i.e., the event is signaled) (2) The IO fails, and the BlockIo2 driver determines the failure asynchronously. In this case, the original call returns EFI_SUCCESS, and the error notification occurs again via signaling the event. (3) The IO fails, but the failure is determined immediately (synchronously), as part of the original call. In this case, no background operation is queued (so there is nothing to signal an event for later), and the error is returned immediately. IMO, the spec requires the driver to check for the EFI_NO_MEDIA and the EFI_MEDIA_CHANGED conditions *at least* synchronously, that is, to return them (if they occur) *at least* as case (3). Regarding EFI_DEVICE_ERROR, I think the driver is free to check for that only asynchronously, when the actual attempt is being made, in the background, to work with the device. Therefore, EFI_DEVICE_ERROR may be reported both as case (2) and as case (3). What's important is that, *if* the driver reports EFI_DEVICE_ERROR synchronously (3), then the signaling (case (2)) should not occur -- as it would be redundant. In summary: - we have three cases about status reporting, - some error codes *must* be checked-for synchronously (at least), - some other error codes may be identified both synchronously and asynchronously; in either case, they should be reported accordingly. > 2. If the driver does not have enough resources to complete an IO request, > the driver should signal the event with same status (EFI_OUT_OF_RESOURCES) > so that caller will retry the IO ? In such cases, what should be the status > of ReadEx/WriteEx callbacks itself that should returned to the caller ? IMO, the same logic applies to EFI_OUT_OF_RESOURCES as to EFI_DEVICE_ERROR. If the driver sees immediately that it has lacking resources, it should return EFI_OUT_OF_RESOURCES immediately. (For example, if it lacks resources for even *queueing* the request, this would be the right thing to do.) If the driver realizes only during background processing that it has run out of resources, then EFI_OUT_OF_RESOURCES should be returned through the token, asynchronously. Note that EFI_OUT_OF_RESOURCES is documented as "The request could not be *completed* due to a lack of resources". This includes both cases above. (I.e., couldn't be queued, or could be queued, but not completed.) Therefore both cases (2) and (3) apply, dependent on what happens. Now, whether a BlockIo2 driver tries to allocate all *possibly* necessary resources in advance, when queueing a request, is a Quality-of-Implementation question, IMO. I think it's not required by the spec, but it could benefits user experience, and debugging too. Synchronous error reports save higher level drivers the burden of async context restoration and recovery --> fewer bugs hit by the user. Also, it helps with debugging: the developer will get a usable call stack when the issue hits. OTOH, if a driver tries too hard to synchronously allocate all possibly necessary resources for a request, even if there's a good chance that part of those resources will never be used, then it's a waste. It could cause other drivers to run out of resources, or it could fail some requests that would otherwise complete fine in practice. So it's up to your device & driver whether you should report EFI_OUT_OF_RESOURCES *only* synchronously. I think it's valid to report it asynchronously too. > In short, i am bit confused what should be the "Transaction Status" that > should be signaled by the driver. Please comment. Hopefully the above helps. Thanks, Laszlo > On Mon, Jan 28, 2019 at 2:17 PM Laszlo Ersek wrote: > >> Hi, >> >> On 01/26/19 17:57, Sajeesh Kk wrote: >>> Hello Rafeal, >>> >>> I believe The UEFI Sct test suite cannot be used for performance testing. >>> Are there any tools which can be used from UEFI shell to measure disk IO >>> perfomance using BlockIO2 Protocol ? >>> Please let me know. >> >> from a cursory look, FatPkg/EnhancedFatDxe appears to implement the the >> ReadEx/WriteEx methods of EFI_FILE_PROTOCOL >> (EFI_FILE_PROTOCOL_REVISION2). I think the implementation uses the >> DiskIo2 protocol. >> >> And "MdeModulePkg/Universal/Disk/DiskIoDxe" should automatically install >> DiskIo2 on top of your BlockIo2. >> >> So, if you can write a simple UEFI application that uses the *Ex() >> methods of EFI_FILE_PROTOCOL, that could be a start. (Nothing in edk2 >> seems to use ReadEx / WriteEx currently.) >> >> Thanks, >> Laszlo >> >