Re: r8169: slow samba performance

[Bruce Cole <bacole@gmail.com>]

Francois Romieu wrote:
> Does "acceptable" mean that there is a noticeable difference when compared
> to the patch based on a busy-waiting loop ?
>
>   
>> Would you like me to *just* try patches 1 & 2, to help narrow down anything?
>>     
>
> I expect patch #2 alone to be enough to enhance the performance. If it gets
> proven, the patch would be a good candidate for a quick merge upstream.
>
>   
Patch #0002 looks functionally equivalent to the patch I already pointed 
folks
to and which I showed as being sufficient to address the TX queue problem.
The fix has also already been confirmed by shane, that fix being:

diff -c r/r8169.c r3/r8169-out.c
*** r/r8169.c   2007-08-18 11:54:58.000000000 -0700
--- r3/r8169-out.c      2007-09-04 14:23:49.000000000 -0700
***************
*** 2646,2651 ****
--- 2646,2655 ----
                if (netif_queue_stopped(dev) &&
                    (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
                        netif_wake_queue(dev);
+               } else if (dirty_tx != tp->cur_tx) {
+                       netif_tx_lock(dev);
+                       RTL_W8(TxPoll, NPQ);
+                       netif_tx_unlock(dev);
                }
        }
  }


In any case, I've tried your latest version of the patch,
0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch, and it alone
works as well.


I'm not sure why you describe this as being an "8168 hack", given that the
problem has been seen with the 8111b chip (I have an 8111b chip on my 
gigabyte
motherboard).


Now since this change heals the TX queue stall, it would seem that the real
underlying problem involves a race condition with enqueueing to the TX queue
while the controller is processing the queue.  The ultimate fix for that 
I bet
is either to address locking at TX enqueue time, or there is a 
controller bug.
Any clarification from realtek on the necessary processing for the NPQ 
bit, or
a known controller problem?
 
PS: I've also received private email that this problem pertains to video
streaming (to a Kiss DVD player) not just samba or X11 traffic.  Basically
most all high-level TCP based protocols are affected it seems.  This serious
performance problem should be considered to impact a lot more than just 
samba
users.