From: David Miller <davem@davemloft.net>
To: romieu@fr.zoreil.com
Cc: hayeswang@realtek.com, eric.dumazet@gmail.com, netdev@vger.kernel.org
Subject: Re: [RFC] r8169 : why SG / TX checksum are default disabled
Date: Wed, 18 Jul 2012 13:28:40 -0700 (PDT) [thread overview]
Message-ID: <20120718.132840.1571938255177607234.davem@davemloft.net> (raw)
In-Reply-To: <20120718201201.GC14149@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 18 Jul 2012 22:12:01 +0200
> David Miller <davem@davemloft.net> :
>> From: hayeswang <hayeswang@realtek.com>
>> > Francois Romieu [mailto:romieu@fr.zoreil.com]
>> > [...]
>> >
>> >> Hayes, should we not add into the kernel driver something similar to
>> >> the rtl8168_start_xmit::skb_checksum_help stuff in Realtek's
>> >> 8168 driver ?
>> >> There seems to be a bug for (skb->len < 60 && RTL_GIGA_MAC_VER_34.
>> >
>> > For RTL8168E-VL (RTL_GIGA_MAC_VER_34), the hardware wouldn't send the packet
>> > with the length less than 60 bytes. The hardware should pad this kind of packet
>> > to 60 bytes, but it wouldn't. Therefore, the software has to pad the packet to
>> > 60 bytes. However, the hw checksum would be incorrect for the modified packet,
>> > so the software checksum is necessary.
>>
>> I wonder how the hardware checksum can be incorrectly calculated if the padding
>> is done with zeros?
>
> A part of the apparent problem may stem from the fact that Realtek's 8168
> driver claims a modified length but it does not really skb_padto...
>
> Hayes, would the patch below fix the original problem ?
A NETDEV_TX_OK return means we accepted the SKB, it doesn't look like
that's what you are doing in the skb_padto() failure path.
next prev parent reply other threads:[~2012-07-18 20:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-17 22:39 [RFC] r8169 : why SG / TX checksum are default disabled Eric Dumazet
2012-07-17 23:40 ` Francois Romieu
2012-07-18 6:45 ` hayeswang
2012-07-18 16:23 ` David Miller
2012-07-18 20:12 ` Francois Romieu
2012-07-18 20:28 ` David Miller [this message]
2012-07-18 21:44 ` Francois Romieu
2012-07-18 22:05 ` Eric Dumazet
2012-07-18 22:24 ` David Miller
2012-07-20 7:14 ` hayeswang
2012-07-20 10:08 ` Francois Romieu
2012-07-20 16:01 ` hayeswang
2012-07-20 16:28 ` David Miller
2012-07-20 21:01 ` Francois Romieu
2012-07-24 6:34 ` hayeswang
2012-07-24 6:59 ` David Miller
2012-07-25 2:10 ` hayeswang
2012-07-20 16:17 ` David Miller
2012-07-20 2:11 ` hayeswang
2012-07-18 8:55 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120718.132840.1571938255177607234.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hayeswang@realtek.com \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.