[net-next,08/11] net:fec: change FEC alignment to 64 bytes for ARM platform

From: Fugang Duan <B38611@freescale.com>

Since enet-avb has 64 bytes alignment limitation for rx DMA transfer.
The previous enet IP for ARM platform has 16 bytes alignment for tx
DMA transfer. 64 is the an integral number of 16, so change alignment
to 64 bytes for all ARM platform, which don't impact the performance
of previous platform.

Signed-off-by: Fugang Duan <B38611@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

From: Frank Li
> From: Fugang Duan <B38611@freescale.com>
> 
> Since enet-avb has 64 bytes alignment limitation for rx DMA transfer.
> The previous enet IP for ARM platform has 16 bytes alignment for tx
> DMA transfer.

Do you mean rx or tx here? or both??

And can we beat up the hardware designers to stop these restrictions
on rx (in particular) ethernet buffer alignments?
A device isn't suitable for ethernet unless is can write the destination
mac address to a 4n+2 boundary.

	David

> 64 is the an integral number of 16, so change alignment
> to 64 bytes for all ARM platform, which don't impact the performance
> of previous platform.
> 
> Signed-off-by: Fugang Duan <B38611@freescale.com>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
> ---
>  drivers/net/ethernet/freescale/fec_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index a232245..b388e29f 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -65,7 +65,7 @@
>  static void set_multicast_list(struct net_device *ndev);
> 
>  #if defined(CONFIG_ARM)
> -#define FEC_ALIGNMENT	0xf
> +#define FEC_ALIGNMENT	0x3f
>  #else
>  #define FEC_ALIGNMENT	0x3
>  #endif
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: David Laight <David.Laight@ACULAB.COM> Sent: Thursday, September 04, 2014 4:51 PM
>To: Li Frank-B20596; Duan Fugang-B38611; davem@davemloft.net;
>netdev@vger.kernel.org; lznuaa@gmail.com
>Cc: shawn.guo@linaro.org; linux-arm-kernel@lists.infradead.org;
>devicetree@vger.kernel.org; Duan Fugang-B38611
>Subject: RE: [Patch net-next 08/11] net:fec: change FEC alignment to 64
>bytes for ARM platform
>
>From: Frank Li
>> From: Fugang Duan <B38611@freescale.com>
>>
>> Since enet-avb has 64 bytes alignment limitation for rx DMA transfer.
>> The previous enet IP for ARM platform has 16 bytes alignment for tx
>> DMA transfer.
>
>Do you mean rx or tx here? or both??
>
>And can we beat up the hardware designers to stop these restrictions on rx
>(in particular) ethernet buffer alignments?
>A device isn't suitable for ethernet unless is can write the destination
>mac address to a 4n+2 boundary.
>
>	David
>
Hi, David,

For previous enet IP there has 16 bytes data buffer alignment limitation for tx & rx DMA transfer.
For imx6sx enet-avb IP, there has 64 bytes data buffer alignment limitation for rx DMA transfer, byte alignment for tx data
Buffer for DMA transfer.

I think rx data buffer alignment limitation don't introduce performance drop, is not complex for sw implemention. Anyway,
We can request IC designer to remove the limitation for future chips.

Thanks,
Andy

>> 64 is the an integral number of 16, so change alignment to 64 bytes
>> for all ARM platform, which don't impact the performance of previous
>> platform.
>>
>> Signed-off-by: Fugang Duan <B38611@freescale.com>
>> Signed-off-by: Frank Li <Frank.Li@freescale.com>
>> ---
>>  drivers/net/ethernet/freescale/fec_main.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c
>> b/drivers/net/ethernet/freescale/fec_main.c
>> index a232245..b388e29f 100644
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -65,7 +65,7 @@
>>  static void set_multicast_list(struct net_device *ndev);
>>
>>  #if defined(CONFIG_ARM)
>> -#define FEC_ALIGNMENT	0xf
>> +#define FEC_ALIGNMENT	0x3f
>>  #else
>>  #define FEC_ALIGNMENT	0x3
>>  #endif
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org More majordomo info
>> at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: fugang.duan@freescale.com
> >From: Frank Li
> >> From: Fugang Duan <B38611@freescale.com>
> >>
> >> Since enet-avb has 64 bytes alignment limitation for rx DMA transfer.
> >> The previous enet IP for ARM platform has 16 bytes alignment for tx
> >> DMA transfer.
> >
> >Do you mean rx or tx here? or both??
> >
> >And can we beat up the hardware designers to stop these restrictions on rx
> >(in particular) ethernet buffer alignments?
> >A device isn't suitable for ethernet unless is can write the destination
> >mac address to a 4n+2 boundary.
> >
> >	David
> >
> Hi, David,
> 
> For previous enet IP there has 16 bytes data buffer alignment limitation for tx & rx DMA transfer.
> For imx6sx enet-avb IP, there has 64 bytes data buffer alignment limitation for rx DMA transfer, byte
> alignment for tx data
> Buffer for DMA transfer.
> 
> I think rx data buffer alignment limitation don't introduce performance drop, is not complex for sw
> implemention. Anyway,
> We can request IC designer to remove the limitation for future chips.

The 'problem' is that you need the IP header to be 32bit aligned.
If the dma buffer has to be aligned then the code either has to do an expensive
misaligned copy of the entire frame (at some point the entire frame is almost
certainly all copied into an aligned buffer), or take the hit of misaligned
memory accesses (which might have to be emulated with byte transfers).

The rx buffer can be aligned provided the hardware skips (or writes junk to)
the first two bytes.

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Sep 4, 2014 at 4:18 AM, David Laight <David.Laight@aculab.com> wrote:
> From: fugang.duan@freescale.com
>> >From: Frank Li
>> >> From: Fugang Duan <B38611@freescale.com>
>> >>
>> >> Since enet-avb has 64 bytes alignment limitation for rx DMA transfer.
>> >> The previous enet IP for ARM platform has 16 bytes alignment for tx
>> >> DMA transfer.
>> >
>> >Do you mean rx or tx here? or both??
>> >
>> >And can we beat up the hardware designers to stop these restrictions on rx
>> >(in particular) ethernet buffer alignments?
>> >A device isn't suitable for ethernet unless is can write the destination
>> >mac address to a 4n+2 boundary.
>> >
>> >     David
>> >
>> Hi, David,
>>
>> For previous enet IP there has 16 bytes data buffer alignment limitation for tx & rx DMA transfer.
>> For imx6sx enet-avb IP, there has 64 bytes data buffer alignment limitation for rx DMA transfer, byte
>> alignment for tx data
>> Buffer for DMA transfer.
>>
>> I think rx data buffer alignment limitation don't introduce performance drop, is not complex for sw
>> implemention. Anyway,
>> We can request IC designer to remove the limitation for future chips.
>
> The 'problem' is that you need the IP header to be 32bit aligned.
> If the dma buffer has to be aligned then the code either has to do an expensive
> misaligned copy of the entire frame (at some point the entire frame is almost
> certainly all copied into an aligned buffer), or take the hit of misaligned
> memory accesses (which might have to be emulated with byte transfers).
>
> The rx buffer can be aligned provided the hardware skips (or writes junk to)
> the first two bytes.

ENET IP have feature to add additional 2 byte when save data to memory.

RX FIFO Shift-16
When this field is set, the actual frame data starts at bit 16 of the
first word read from the RX FIFO aligning
the Ethernet payload on a 32-bit boundary.
NOTE: This function only affects the FIFO storage and has no influence
on the statistics, which use the
actual length of the frame received.
0 Disabled.
1 Instructs the MAC to write two additional bytes in front of each
frame received into the RX FIFO.

i.MX6SX,
          Remove TX alignment requirement.
          But RX and DMA BD address is 64byte aligment.


best regards
Frank Li



>
>         David
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html