Re: [PATCH] pch_gbe: Fix the issue that the receiving data is not normal.

From: David Miller <davem@davemloft.net>
Date: Tue, 08 Feb 2011 16:35:22 -0800 (PST)

quoted

Hi Devid

I resubmit this patch modified.
Please check them.

Your memcpy+memcpy sequences are equivalent to memmove(), please
use that instead.

I use memmove().

I have to say this function is insanely complicated.  There seems
to be 16 different ways RX packets are processed.  I can't believe
that is needs to be like this.

If processing is arranged, There are 4 different ways RX packets are 
processed.

[Case1]
"rx_csum is enable " and
 "NET_IP_ALIGN == 0"

 DMA buffer is used as SKB as it is.

[Case2]
"rx_csum is enable " and
 "NET_IP_ALIGN != 0"

 Because alignment differs, the new_skb is newly allocated, and data is 
copied to new_skb.

[Case3]
"rx_csum is disable " and
 "length < copybreak" or "NET_IP_ALIGN != PCH_GBE_DMA_PADDING"

 Because alignment differs, the new_skb is newly allocated, and data is 
copied to new_skb.
 Padding data is deleted at the time of a copy.

[Case4]
"rx_csum is disable " and
 "length >= copybreak" and "NET_IP_ALIGN == PCH_GBE_DMA_PADDING"

 Padding data is deleted by moving header data.

I rewrite without using skb_copy_flag and skb_padding simply.

Best regards
Toshiharu Okada(OKI semiconductor)