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

[Toshiharu Okada]

From: David Miller <davem@xxxxxxxxxxxxx>
Date: Tue, 08 Feb 2011 16:35:22 -0800 (PST)
>> 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) 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/