Hi, Eugene
The PaddingSize is in order to make the packet data (exclude the media header)
4-byte aligned when we tries to receive a packet.
When MNP driver calls the Snp.Receive() interface, both the media header and
the data will be placed to the *Buffer*. Use IP packet over Ethernet for
example, the media header is 14 bytes length (2 * 6 bytes MAC address + 2 bytes
protocol type), then the IP4 header which immediately following the media
header. The EFI network stack is designed to make the minimum times memory
copy, so most of the upper layer drivers will operate on this buffer directly.
Thus we have 2 choices,
(1) If *Buffer* passed to Snp.Receive() is 4-byte aligned, the packet data
will start at a non-dword aligned address. Since most network protocols are
designed with alignment consideration, the upper layer protocols, like IP, UDP,
TCP data items, will also start at a non-dword aligned address. I think parse
these data on unaligned address will also have performance issue.
(2) If we make the packet data aligned, the *Buffer* is unaligned, it will
bring performance issue as your said. Fortunately this unaligned memory copy
only happen once on each packet (only in SNP or UNDI driver).
I think that's why MNP driver tries to align a later part of Ethernet packet.
And I have tested the PXE boot and TCP download on my side and do not see clear
differences between them (maybe it's because my UNDI driver do not use DMA?).
Hope my explanation is helpful.
Fu, Siyuan
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Thursday, August 22, 2013 11:46 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] MNP PaddingSize Question
Ruth,
The performance impact is related to unaligned copies to uncached buffers. So
I suppose any machine that must make use of uncached buffers for DMA coherency
would have the same slowdown, although I have not had a reason to measure this
on other platforms.
The code seems strange since for a normal driver (UNDI, SNP) the receive buffer
address passed down is no longer 4-byte aligned. Apparently this code is
trying to align a later part of the ethernet packet (the payload, not the
header) but I can't think of a reason for this.
Eugene
From: Li, Ruth [mailto:ruth...@intel.com]
Sent: Wednesday, August 21, 2013 7:55 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] MNP PaddingSize Question
Hi Eugene,
Below pieces of code has been there for long time. We need some time to
evaluate it and see possible impact.
BTW, can I know whether you see the performance impact only over your machine?
Or generally all machine?
Thanks,
Ruth
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, August 20, 2013 3:56 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] MNP PaddingSize Question
I've been tracking down a performance issue and have isolated it to this piece
of MNP initialization code:
//
// Make sure the protocol headers immediately following the media header
// 4-byte aligned, and also preserve additional space for VLAN tag
//
MnpDeviceData->PaddingSize = ((4 - SnpMode->MediaHeaderSize) & 0x3) +
NET_VLAN_TAG_LEN;
On my system this is coming up with '6' (MediaHeaderSize = 0xE) which is
causing performance issues since some of the memory copies to the resulting
non-dword aligned addresses are slower. As an experiment I tried bumping this
number to '8' and things worked well.
This value is used later when NET_BUFs are being allocated:
if (MnpDeviceData->PaddingSize > 0) {
//
// Pad padding bytes before the media header
//
NetbufAllocSpace (Nbuf, MnpDeviceData->PaddingSize, NET_BUF_TAIL);
NetbufTrim (Nbuf, MnpDeviceData->PaddingSize, NET_BUF_HEAD);
}
Can someone explain the purpose of PaddingSize and how that affects the later
processing of packets? Is this number a minimum value and is ok to be larger?
Thanks,
Eugene
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
