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 44E39211B698D for ; Fri, 11 Jan 2019 02:24:35 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 94B23CCB88; Fri, 11 Jan 2019 10:24:34 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-3.rdu2.redhat.com [10.10.120.3]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA9B760C7F; Fri, 11 Jan 2019 10:24:32 +0000 (UTC) To: Songpeng Li , edk2-devel@lists.01.org Cc: Jaben Carsey , Ruiyu Ni , Wu Jiaxin References: <20190110025415.41056-1-songpeng.li@intel.com> From: Laszlo Ersek Message-ID: <168d2e88-e1e4-730d-ac39-474670c10bc6@redhat.com> Date: Fri, 11 Jan 2019 11:24:31 +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: <20190110025415.41056-1-songpeng.li@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 11 Jan 2019 10:24:34 +0000 (UTC) Subject: Re: [PATCH v2] ShellPkg/TftpDynamicCommand: Change file writing method in tftp 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: Fri, 11 Jan 2019 10:24:35 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/10/19 03:54, Songpeng Li wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1433 > > v2: Remove an unused variable. > > Current logic of shell tftp download was writing file after tftp > download finished, when the file is large, it looks like the shell > tftp command hanged after download was finished. To improve > end-user experience, the solution is using split file writing > instead. > > This patch update the code to open and close file inside > DownloadFile(), and save each packet to file within callback > function CheckPacket(). I have some questions, just out of curiosity: > > Since AllocatePage() is no-longer needed, This patch can also > remove the memory limitation. The download file can be larger > than system free memory now. > > Cc: Jaben Carsey > Cc: Ruiyu Ni > Cc: Wu Jiaxin > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Songpeng Li > --- > ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 154 ++++++++------------ > 1 file changed, 64 insertions(+), 90 deletions(-) > > diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c > index ed081b5bad7c..ba753a279b00 100644 > --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c > +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c > @@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[ > // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b' > STATIC CONST CHAR16 mTftpProgressDelete[] = L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"; > > +// Local File Handle > +SHELL_FILE_HANDLE mFileHandle; > + > +// Path of the local file, Unicode encoded > +CONST CHAR16 *mLocalFilePath; > + > /** > Check and convert the UINT16 option values of the 'tftp' command > > @@ -166,9 +172,6 @@ GetFileSize ( > @param[in] FileSize Size of the file in number of bytes > @param[in] BlockSize Value of the TFTP blksize option > @param[in] WindowSize Value of the TFTP window size option > - @param[out] Data Address where to store the address of the buffer > - where the data of the file were downloaded in > - case of success. > > @retval EFI_SUCCESS The file was downloaded. > @retval EFI_OUT_OF_RESOURCES A memory allocation failed. > @@ -184,8 +187,7 @@ DownloadFile ( > IN CONST CHAR8 *AsciiFilePath, > IN UINTN FileSize, > IN UINT16 BlockSize, > - IN UINT16 WindowSize, > - OUT VOID **Data > + IN UINT16 WindowSize > ); > > /** > @@ -287,7 +289,6 @@ RunTftp ( > CHAR8 *AsciiRemoteFilePath; > UINTN FilePathSize; > CONST CHAR16 *Walker; > - CONST CHAR16 *LocalFilePath; > EFI_MTFTP4_CONFIG_DATA Mtftp4ConfigData; > EFI_HANDLE *Handles; > UINTN HandleCount; > @@ -297,9 +298,6 @@ RunTftp ( > EFI_HANDLE Mtftp4ChildHandle; > EFI_MTFTP4_PROTOCOL *Mtftp4; > UINTN FileSize; > - UINTN DataSize; > - VOID *Data; > - SHELL_FILE_HANDLE FileHandle; > UINT16 BlockSize; > UINT16 WindowSize; > > @@ -309,7 +307,6 @@ RunTftp ( > AsciiRemoteFilePath = NULL; > Handles = NULL; > FileSize = 0; > - DataSize = 0; > BlockSize = MTFTP_DEFAULT_BLKSIZE; > WindowSize = MTFTP_DEFAULT_WINDOWSIZE; > > @@ -385,7 +382,7 @@ RunTftp ( > UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize); > > if (ParamCount == 4) { > - LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3); > + mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3); > } else { > Walker = RemoteFilePath + StrLen (RemoteFilePath); > while ((--Walker) >= RemoteFilePath) { > @@ -394,7 +391,7 @@ RunTftp ( > break; > } > } > - LocalFilePath = Walker + 1; > + mLocalFilePath = Walker + 1; > } > > // > @@ -492,7 +489,6 @@ RunTftp ( > (NicNumber < HandleCount) && (ShellStatus != SHELL_SUCCESS); > NicNumber++) { > ControllerHandle = Handles[NicNumber]; > - Data = NULL; > > Status = GetNicName (ControllerHandle, NicNumber, NicName); > if (EFI_ERROR (Status)) { > @@ -543,7 +539,7 @@ RunTftp ( > goto NextHandle; > } > > - Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, FileSize, BlockSize, WindowSize, &Data); > + Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath, FileSize, BlockSize, WindowSize); > if (EFI_ERROR (Status)) { > ShellPrintHiiEx ( > -1, -1, NULL, STRING_TOKEN (STR_TFTP_ERR_DOWNLOAD), > @@ -552,45 +548,8 @@ RunTftp ( > goto NextHandle; > } > > - DataSize = FileSize; > - > - if (!EFI_ERROR (ShellFileExists (LocalFilePath))) { > - ShellDeleteFileByName (LocalFilePath); > - } > - > - Status = ShellOpenFileByName ( > - LocalFilePath, > - &FileHandle, > - EFI_FILE_MODE_CREATE | > - EFI_FILE_MODE_WRITE | > - EFI_FILE_MODE_READ, > - 0 > - ); > - if (EFI_ERROR (Status)) { > - ShellPrintHiiEx ( > - -1, -1, NULL, STRING_TOKEN (STR_GEN_FILE_OPEN_FAIL), > - mTftpHiiHandle, L"tftp", LocalFilePath > - ); > - goto NextHandle; > - } > - > - Status = ShellWriteFile (FileHandle, &FileSize, Data); Before the patch, the shell would write the entire file in "one go". In this particular case, I'm not interested in the memory allocation size, but the transfer block size that the shell would ultimately use with EFI_FILE_WRITE. I find it interesting because some lower-level storage drivers may have limitations themselves (for example, a single SCSI transfer might not be larger than 1GB). What layer would handle (split) a downloaded file larger than that into smaller chunks? Maybe the FS (FAT) driver? > - if (!EFI_ERROR (Status)) { > - ShellStatus = SHELL_SUCCESS; > - } else { > - ShellPrintHiiEx ( > - -1, -1, NULL, STRING_TOKEN (STR_TFTP_ERR_WRITE), > - mTftpHiiHandle, LocalFilePath, Status > - ); > - } > - ShellCloseFile (&FileHandle); > - > NextHandle: > > - if (Data != NULL) { > - gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)Data, EFI_SIZE_TO_PAGES (DataSize)); > - } > - > CloseProtocolAndDestroyServiceChild ( > ControllerHandle, > &gEfiMtftp4ServiceBindingProtocolGuid, > @@ -912,9 +871,6 @@ Error : > @param[in] FileSize Size of the file in number of bytes > @param[in] BlockSize Value of the TFTP blksize option > @param[in] WindowSize Value of the TFTP window size option > - @param[out] Data Address where to store the address of the buffer > - where the data of the file were downloaded in > - case of success. > > @retval EFI_SUCCESS The file was downloaded. > @retval EFI_OUT_OF_RESOURCES A memory allocation failed. > @@ -930,13 +886,10 @@ DownloadFile ( > IN CONST CHAR8 *AsciiFilePath, > IN UINTN FileSize, > IN UINT16 BlockSize, > - IN UINT16 WindowSize, > - OUT VOID **Data > + IN UINT16 WindowSize > ) > { > EFI_STATUS Status; > - EFI_PHYSICAL_ADDRESS PagesAddress; > - VOID *Buffer; > DOWNLOAD_CONTEXT *TftpContext; > EFI_MTFTP4_TOKEN Mtftp4Token; > UINT8 BlksizeBuf[10]; > @@ -944,22 +897,6 @@ DownloadFile ( > > ZeroMem (&Mtftp4Token, sizeof (EFI_MTFTP4_TOKEN)); > > - // Downloaded file can be large. BS.AllocatePages() is more faster > - // than AllocatePool() and avoid fragmentation. > - // The downloaded file could be an EFI application. Marking the > - // allocated page as EfiBootServicesCode would allow to execute a > - // potential downloaded EFI application. > - Status = gBS->AllocatePages ( > - AllocateAnyPages, > - EfiBootServicesCode, > - EFI_SIZE_TO_PAGES (FileSize), > - &PagesAddress > - ); > - if (EFI_ERROR (Status)) { > - return Status; > - } > - > - Buffer = (VOID*)(UINTN)PagesAddress; > TftpContext = AllocatePool (sizeof (DOWNLOAD_CONTEXT)); > if (TftpContext == NULL) { > Status = EFI_OUT_OF_RESOURCES; > @@ -970,8 +907,6 @@ DownloadFile ( > TftpContext->LastReportedNbOfBytes = 0; > > Mtftp4Token.Filename = (UINT8*)AsciiFilePath; > - Mtftp4Token.BufferSize = FileSize; > - Mtftp4Token.Buffer = Buffer; > Mtftp4Token.CheckPacket = CheckPacket; > Mtftp4Token.Context = (VOID*)TftpContext; > Mtftp4Token.OptionCount = 0; > @@ -1000,14 +935,41 @@ DownloadFile ( > mTftpHiiHandle, FilePath > ); > > + // > + // OPEN FILE > + // > + if (!EFI_ERROR (ShellFileExists (mLocalFilePath))) { > + ShellDeleteFileByName (mLocalFilePath); > + } > + > + Status = ShellOpenFileByName ( > + mLocalFilePath, > + &mFileHandle, > + EFI_FILE_MODE_CREATE | > + EFI_FILE_MODE_WRITE | > + EFI_FILE_MODE_READ, > + 0 > + ); > + if (EFI_ERROR (Status)) { > + ShellPrintHiiEx ( > + -1, -1, NULL, STRING_TOKEN (STR_GEN_FILE_OPEN_FAIL), > + mTftpHiiHandle, L"tftp", mLocalFilePath > + ); > + goto Error; > + } > + > Status = Mtftp4->ReadFile (Mtftp4, &Mtftp4Token); > ShellPrintHiiEx ( > -1, -1, NULL, STRING_TOKEN (STR_GEN_CRLF), > mTftpHiiHandle > ); > > -Error : > + // > + // CLOSE FILE > + // > + ShellCloseFile (&mFileHandle); > > +Error : > if (TftpContext != NULL) { > FreePool (TftpContext); > } > @@ -1016,14 +978,7 @@ Error : > FreePool (Mtftp4Token.OptionList); > } > > - if (EFI_ERROR (Status)) { > - gBS->FreePages (PagesAddress, EFI_SIZE_TO_PAGES (FileSize)); > - return Status; > - } > - > - *Data = Buffer; > - > - return EFI_SUCCESS; > + return Status; > } > > /** > @@ -1054,6 +1009,7 @@ CheckPacket ( > UINTN Index; > UINTN LastStep; > UINTN Step; > + UINTN DownloadLen; > EFI_STATUS Status; > > if ((NTOHS (Packet->OpCode)) != EFI_MTFTP4_OPCODE_DATA) { > @@ -1061,17 +1017,35 @@ CheckPacket ( > } > > Context = (DOWNLOAD_CONTEXT*)Token->Context; > - if (Context->DownloadedNbOfBytes == 0) { > - ShellPrintEx (-1, -1, L"%s 0 Kb", mTftpProgressFrame); > - } > > // > // The data in the packet are prepended with two UINT16 : > // . OpCode = EFI_MTFTP4_OPCODE_DATA > // . Block = the number of this block of data > // > - Context->DownloadedNbOfBytes += PacketLen - sizeof (Packet->OpCode) > - - sizeof (Packet->Data.Block); > + DownloadLen = (UINTN)PacketLen - sizeof (Packet->OpCode) - sizeof (Packet->Data.Block); > + > + ShellSetFilePosition(mFileHandle, Context->DownloadedNbOfBytes); > + Status = ShellWriteFile (mFileHandle, &DownloadLen, Packet->Data.Data); And, after the patch, we're now writing TFTP packet-sized chunks to the file. Is this not a performance problem for traditional spindle disks ("spinning rust")? If neither the rest of the driver stack, nor the disk controller itself, support some form of write caching, then writing out every TFTP packet in isolation (especially for a multi-GB file) could be detrimental to performance (and maybe to the health of the spindle disk). Currently I'm not affected by this use case either way, so feel free to ignore, but it might make sense to implement some larger chunking here, like 64KB or 128KB -- later, as a separate Feature BZ. Thanks, Laszlo > + if (EFI_ERROR (Status)) { > + if (Context->DownloadedNbOfBytes > 0) { > + ShellPrintHiiEx ( > + -1, -1, NULL, STRING_TOKEN (STR_GEN_CRLF), > + mTftpHiiHandle > + ); > + } > + ShellPrintHiiEx ( > + -1, -1, NULL, STRING_TOKEN (STR_TFTP_ERR_WRITE), > + mTftpHiiHandle, mLocalFilePath, Status > + ); > + return Status; > + } > + > + if (Context->DownloadedNbOfBytes == 0) { > + ShellPrintEx (-1, -1, L"%s 0 Kb", mTftpProgressFrame); > + } > + > + Context->DownloadedNbOfBytes += DownloadLen; > NbOfKb = Context->DownloadedNbOfBytes / 1024; > > Progress[0] = L'\0'; >