e1000 driver and samba
Subsystems (2)
Quoted 3 lines
If you look for it on the Realtek cards, there had been sporadic Nissues up to late 2005. The solution posted universally was 'change card'.
Yes, that *was* the common recommendation. But recently I narrowed down the realtek performance problem most commonly seen with samba (but also applicable to other TCP applications), and I also narrowed down the fix as well.
The current fix involves re-kicking the TX queue after it becomes stuck. Apparently it becomes stuck due to a contention problem between the driver and controller. I suspect the root problem is the driver isn't properly locking the TX queue. It might be worth checking if the queue locking problem exists in other net drivers as well.
Quoted 9 lines · Bruce Cole
Yes, that *was* the common recommendation. But recently I narrowed down the realtek performance problem most commonly seen with samba (but also applicable to other TCP applications), and I also narrowed down the fix as well.
The current fix involves re-kicking the TX queue after it becomes stuck. Apparently it becomes stuck due to a contention problem between the driver and controller. I suspect the root problem is the driver isn't properly locking the TX queue. It might be worth checking if the queue locking problem exists in other net drivers as well.
Aha. This doesn't seem to be in mr. Romieu's patch above: should it go in on top of that?
I ask because with the forementioned patch the newer integrated NICs seem to be recognised correctly and preliminary testing shows no disconnect issues, but performance is nothing to write home about (one of these days I'll get into a rant about samba speed vs. ftp speed, but this is not the time nor place).
Quoted 4 lines
Reference:
http://www.spinics.net/lists/netdev/msg40384.htmlBruce Cole
LF
Quoted 3 lines · L F
Aha. This doesn't seem to be in mr. Romieu's patch above: should it go in on top of that?
His newer
0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch does the same thing as the older quoted version, and is also included in the roll-up patch he pointed you to.
I agree re. performance, and don't want to clutter the thread
realtek issues. I just wanted to clarify this particular
realtek-samba issue in case it's relevant. For a long time folks
suspected similar culprits (bad cable, half duplex, etc.) when
it was the driver. Perhaps you should try doing a ping flood between server&client during your test. That healed the problem by keeping the queue busy in the realtek case.
Bruce Cole <[email protected]> :
Quoted 5 lines
Quoted 3 lines
If you look for it on the Realtek cards, there had been sporadic Nissues up to late 2005. The solution posted universally was 'change card'.
Yes, that *was* the common recommendation.
There was no such thing as a universal solution to sporadic issues.
[...]
Quoted 2 lines
I suspect the root problem is the driver isn't properly locking the TX queue.
Can you be more specific ?
Signature · 1 line
Ueimor
Quoted 11 lines · Francois Romieu
Bruce Cole <[email protected]> :
Quoted 6 lines
Quoted 4 lines
If you look for it on the Realtek cards, there had been sporadic Nissues up to late 2005. The solution posted universally was 'change card'.
Yes, that *was* the common recommendation.
There was no such thing as a universal solution to sporadic issues.
I made no such claim. I do claim the realtek samba et all issues are not sporadic however. In fact the common problem is readily reproducible as has been shown.
Quoted 8 lines
[...]
Quoted 3 lines
I suspect the root problem is the driver isn't properly locking the TX queue.
Can you be more specific ?
Yes per the reference I gave:
http://www.spinics.net/lists/netdev/msg40384.html
"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."
I could probably help fix the underlying problem but I didn't receive any response to my post quoted above.
Bruce Cole <[email protected]> :
Quoted 1 line
Francois Romieu wrote:
[...]
Quoted 4 lines
Quoted 2 lines
Can you be more specific ?
Yes per the reference I gave:
http://www.spinics.net/lists/netdev/msg40384.html
[...]
Ok, I wondered if you had found something between the start_xmit and the Tx completion code.
[...]
Quoted 2 lines
I could probably help fix the underlying problem but I didn't receive any response to my post quoted above.
I have submitted the smallest workaround to Jeff. It is not necessarily the best wrt performance but this part is not trivial to arbitrate.
Signature · 1 line
Ueimor