netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gundersen <gundy@iinet.net.au>
To: netdev@vger.kernel.org
Subject: Realtek r8168 slow outbound transfer -  potential fix/workaround
Date: Thu, 14 Jun 2007 00:46:04 +1000	[thread overview]
Message-ID: <4670032C.7010803@iinet.net.au> (raw)


Hi all,

I've been doing a bit of investigation work into a problem that I've 
been experiencing with the latest available r8168 driver from realtek 
('r8168-8.001.00') & linux kernel 2.6.21.1.

I have been experiencing wierd problems with slow outbound traffic that 
seem to go away if there's traffic coming into the device.  Googling 
seen reports of this in a number of places on the web so I get the 
feeling I'm not alone.

I decided to spend a few hours looking into this and as best I could 
tell it's because back-to-back outbound packets result in the 2nd packet 
being mysteriously dropped.

What I found was that line 2505:

  RTL_W8(TxPoll, NPQ);

in the rtl8168_start_xmit() handler is the part that's telling the NIC 
to kick off the next transfer.

I'm guessing that the signal must be edge triggered because after a few 
checks I noticed that during times of heavy transmission, it was 
possible for the card to still have this bit set from the previous 
packet's transmission request, with the result being that the command to 
kick off the next packets' transmission would be lost. The net effect of 
this was that timeouts & retransmits were occurring further up the 
protocol stack, and I believe that was what was responsible for the 
terrible performance.

Now, on to my workaround. Putting a spin style wait like the following 
in front of the line above seemed to solve the problem for me:


if (RTL_R8(TxPoll) & NPQ) {
     for (i = 20; i > 0; i--) {
      if (!(RTL_R8(TxPoll) & NPQ))
       break;
      udelay(25);
    }
}

...

RTL_W8(TxPoll, NPQ);

This waits for the card to signal that it's dealt with the previous 
packet before telling it to process the next. YMMV.

It would be interesting to hear if other people have similar success 
with the above workaround.  Also, I'm not convinced that having a spin 
style wait is the best solution here - if anybody else is able to offer 
a better solution it'd be great to hear it.


Kind Regards,

Dave.

             reply	other threads:[~2007-06-13 14:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-13 14:46 David Gundersen [this message]
2007-06-13 23:11 ` Realtek r8168 slow outbound transfer - potential fix/workaround Francois Romieu
2007-06-14 14:57   ` David Gundersen
  -- strict thread matches above, loose matches on Subject: below --
2007-08-13 18:53 Bruce Cole
2007-08-14 21:19 ` Francois Romieu
2007-08-15  7:17   ` Bruce Cole
     [not found] <25536.1187071305@iinet.net.au>
2007-08-15  5:46 ` Bruce Cole

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=4670032C.7010803@iinet.net.au \
    --to=gundy@iinet.net.au \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).