All of lore.kernel.org
 help / color / mirror / Atom feed
From: hayeswang <hayeswang@realtek.com>
To: 'Francois Romieu' <romieu@fr.zoreil.com>,
	'David Miller' <davem@davemloft.net>
Cc: <eric.dumazet@gmail.com>, <netdev@vger.kernel.org>
Subject: RE: [RFC] r8169 : why SG / TX checksum are default disabled
Date: Fri, 20 Jul 2012 10:11:17 +0800	[thread overview]
Message-ID: <3D5EE67D3FC948CAB5D11ABBBFD60A6F@realtek.com.tw> (raw)
In-Reply-To: <20120718201201.GC14149@electric-eye.fr.zoreil.com>

 Francois Romieu [mailto:romieu@fr.zoreil.com] 
[...]
> 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 ?

According to the response from our hw engineer, it still has the problem even
though you pad the packet to 60 bytes with zeroes. I would still test this patch
to verify it.

>  static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
> @@ -5797,7 +5804,8 @@ static netdev_tx_t 
> rtl8169_start_xmit(struct sk_buff *skb,
>  	opts[1] = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
>  	opts[0] = DescOwn;
>  
> -	rtl8169_tso_csum(tp, skb, opts);
> +	if (!rtl8169_tso_csum(tp, skb, opts))
> +		goto err_update_stats;
>  

I think you should check the length of opts1 of the descriptor, too. Besides,
how about the length of dma_map_xxx? Should it use the original length or the
modified length?

>  	frags = rtl8169_xmit_frags(tp, skb, opts);
>  	if (frags < 0)
> @@ -5853,6 +5861,7 @@ err_dma_1:
>  	rtl8169_unmap_tx_skb(d, tp->tx_skb + entry, txd);
>  err_dma_0:
>  	dev_kfree_skb(skb);
> +err_update_stats:
>  	dev->stats.tx_dropped++;
>  	return NETDEV_TX_OK;
>  
 
Best Regards,
Hayes

  parent reply	other threads:[~2012-07-20  2:11 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
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 [this message]
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=3D5EE67D3FC948CAB5D11ABBBFD60A6F@realtek.com.tw \
    --to=hayeswang@realtek.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.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.