In a CloseEvent, an UnregisterProtocolNotify is done unconditionally.
There is a penalty associated with searching the protocol database on
every CloseEvent and impacts performance, especially during Network
IO. Unregister needs to be done only if the Event is for a
RegisterProtocolNotify.
So
Take the range in the resource descriptor HOB for the memory region described
by the PHIT as higher priority if it is big enough. It can make the memory bin
allocated to be at the same memory region with PHIT that has more better
compatibility
to avoid memory fragmentation for some code practices
Hi, Samer
Should below if condition
+ if (!(EFI_ERROR (Status) || Smbios30Table == NULL)) {
to be
if (!(EFI_ERROR (Status) && Smbios30Table != NULL))
Siyuan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Samer
El-Haj-Mahmoud
Hi, Sriram
Do you have any performance data about this change for Network IO case?
Thanks
Feng
-Original Message-
From: Subramanian, Sriram (System FW, HP Servers) [mailto:srira...@hpe.com]
Sent: Thursday, September 17, 2015 14:07
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer;
On 16 September 2015 at 07:51, Qiu Shumin wrote:
> When execute a command with tailing blank spaces in ShellProtocol.Execute()
> Shell will fail. This patch move the TrimSpaces operation into
> ParseCommandLineToArgs function to fix the problem.
>
> Cc: Ruiyu Ni
Hi Feng,
It was a while since we tested (the data is from June). With this change alone,
we saw about 35% improvement in network download performance when HTTP/FTP like
application running over TcpDxe and downloading files > 200MB in size.
Also, in addition to the numbers, we didn't see a
Update some smbios string and macro name for MinnowBoard Turbot board.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tim He >
Best Regards,
Tim
___
edk2-devel mailing list
Thanks for your comments I'll update the patch.
-Shumin
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
Biesheuvel
Sent: Thursday, September 17, 2015 4:56 PM
To: Qiu, Shumin
Cc: Carsey, Jaben; Ni, Ruiyu; edk2-devel@lists.01.org; Yang, Jadis
On 17 September 2015 at 05:04, Qiu Shumin wrote:
> Cc: Jaben Carsey
> Cc: Ruiyu Ni
> Cc: Yang Jadis
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin
Adding patch file, which is to update some Smbios string and macro name for
MinnowBoard Turbot board.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tim He >
Best Regards,
Tim
From: He, Tim
Sent: Thursday, September 17, 2015
Difference with previous version:
It's not correct to casts away constness to allow TrimSpaces() to modify
'commandline'.
This version make a copy of 'commandLine' and work with that in the remainder
of the function.
Cc: Jaben Carsey
Cc: Ruiyu Ni
On 17 September 2015 at 17:07, Laszlo Ersek wrote:
> According to the UEFI spec, EFI_EVENT_GROUP_READY_TO_BOOT "is notified by
> the system when the Boot Manager is about to load and execute a boot
> option". ArmVirtPkg doesn't do this currently when launching a kernel from
>
On 17 September 2015 at 16:57, Qiu Shumin wrote:
> Difference with the 1st version:
> It's not correct to casts away constness to allow TrimSpaces() to modify
> 'commandline'.
> This version make a copy of 'commandLine' and work with that in the remainder
> of the
Hi all,
I have some question about the mtftp4 protocol.
When i use the "EFI_MTFTP4_PROTOCOL.GetInfo()" function to get the file
size of server's file.
And server will send a OACK packet to client for file info.
And client should use "EFI_MTFTP4_PROTOCOL.ParseOptions()" to parsing the
OACK
On 17 September 2015 at 14:27, Qiu Shumin wrote:
> Difference with previous version:
> It's not correct to casts away constness to allow TrimSpaces() to modify
> 'commandline'.
> This version make a copy of 'commandLine' and work with that in the remainder
> of the
Difference with the 1st version:
It's not correct to casts away constness to allow TrimSpaces() to modify
'commandline'.
This version make a copy of 'commandLine' and work with that in the remainder
of the function.
Difference with the 2nd version
Remove the redundant code.
Cc: Jaben Carsey
According to the UEFI spec, EFI_EVENT_GROUP_READY_TO_BOOT "is notified by
the system when the Boot Manager is about to load and execute a boot
option". ArmVirtPkg doesn't do this currently when launching a kernel from
the QEMU command line. OvmfPkg does (see git commit 28a34033ee).
At least two
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tim He
---
Vlv2TbltDevicePkg/Include/Guid/PlatformInfo.h| 4 ++--
.../Library/MultiPlatformLib/BoardClkGens/BoardClkGens.c | 2 +-
.../Library/MultiPlatformLib/BoardGpios/BoardGpios.c | 6
Dear MdeModulePkg maintainers,
Please see attached patch. I follow the suggestions from previous email thread
and update the patch.
MdeModulePkg : Add a new DxeServicesLib GetFileDevicePathFromAnyFv () function
Contributed-under: TianoCore Contribution Agreement 1.0
From: Shia Cinnamon
Hi,
For GetInfo(), the MTFTP4 server provides a callback function named
"Mtftp4GetInfoCheckPacket" for CheckPacket(). Even though the UEFI spec does
not define the GetInfo() should use EFI_MTFTP4_TOKEN, the MTFTP4 driver
implements GetInfo() based on Readfile() thus it need supply callback
Correct a typo below. MTFTP4 server -> MTFTP4 driver.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting
Sent: Friday, September 18, 2015 11:13 AM
To: Mang Chia Ho; edk2-devel@lists.01.org
Subject: Re: [edk2] Some question for MTFTP4
21 matches
Mail list logo