Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*bad\s+TSO\s+performance\s+in\s+2\.6\.9\-rc2\-BK\s*$/: 194 ]

Total 194 documents matching your query.

141. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Tue, 28 Sep 2004 01:51:17 +0200
~66MB/s Yes, a buffalo gigabit switch. I'm running the test from a e1000 through the switch to a tg3 (tg3 with an older kernel). I also tested it now from a tg3 machine to the other tg3 machine. That
/archives/netdev/2004-09/msg02708.html (11,495 bytes)

142. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 27 Sep 2004 17:13:56 -0700
Bright minds think alike. :-) We have to keep all the other packet counts in sync as well. Andi, others, forget my previous hack patch to tcp_clean_rtx_queue() and give this more complete patch a try
/archives/netdev/2004-09/msg02709.html (17,595 bytes)

143. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 27 Sep 2004 17:15:20 -0700
Yes, the e1000 does TSO expansion much faster than the MIPS cpus on the tg3. I believe the e1000 implementation is in the ASIC instead of being implemented with a firmware runing on a general purpose
/archives/netdev/2004-09/msg02710.html (11,152 bytes)

144. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 10:34:12 +1000
Yes this looks very good. Just a few minor things below. In future we should probably record the MSS in the scb just in case it changes. tso_factor > 1 Is this a clever trick that I don't understand?
/archives/netdev/2004-09/msg02711.html (13,145 bytes)

145. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 27 Sep 2004 21:59:01 -0700
It's got a nasty bug though, I'm not updating TCP_SKB_CB(skb)->seq so retransmits have corrupted sequence numbers, doh! And hey if I update that then I do not need this tso_offset thingy. Fixed in my
/archives/netdev/2004-09/msg02723.html (23,055 bytes)

146. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 15:15:39 +1000
Nice work. Please make that > so that I can sleep at night :) The argument to __tcp_trim_head should be Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxx
/archives/netdev/2004-09/msg02724.html (11,941 bytes)

147. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 27 Sep 2004 22:58:19 -0700
Good catch, fixed as follows: Noted by Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c -- a/net
/archives/netdev/2004-09/msg02728.html (12,443 bytes)

148. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Mon, 27 Sep 2004 23:45:44 -0700
It's got a nasty bug though, I'm not updating TCP_SKB_CB(skb)->seq so retransmits have corrupted sequence numbers, doh! And hey if I update that then I do not need this tso_offset thingy. Hmm, I got
/archives/netdev/2004-09/msg02731.html (11,430 bytes)

149. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Tue, 28 Sep 2004 00:20:50 -0700
Bright minds think alike. :-) We have to keep all the other packet counts in sync as well. Andi, others, forget my previous hack patch to tcp_clean_rtx_queue() and give this more complete patch a tr
/archives/netdev/2004-09/msg02732.html (10,786 bytes)

150. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Tue, 28 Sep 2004 00:23:38 -0700
I think I know what may be going on here. Let's say that we even get the congestion window openned up so that we can build 64K TSO frames, that's around 43 or 44 1500 mtu frames. That means as the w
/archives/netdev/2004-09/msg02733.html (11,460 bytes)

151. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 18:23:23 +1000
Currently we're relying on Nagle to do that. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ P
/archives/netdev/2004-09/msg02735.html (9,664 bytes)

152. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: John Heffner <jheffner@xxxxxxx>
Date: Tue, 28 Sep 2004 08:53:03 -0400 (EDT)
I was referring to a problem I saw that had really terrible performance (around 1 Mbit). It would send out one virtual segment, and all but the last of its real segments would be acked. The receiver
/archives/netdev/2004-09/msg02747.html (10,222 bytes)

153. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 13:38:30 -0700
None. I am working on a local network through a gigabit switch. I will work on making sure cases involving loss work correctly, via the netem module, before I submit these fixes upstream to Linus. Li
/archives/netdev/2004-09/msg02765.html (10,978 bytes)

154. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 14:10:02 -0700
Ok, here are 2 patches incorporating all of the things we discussed in this area: 1) Uninline tcp_current_mss(), fix tcp_sync_mss() return value to match tcp_current_mss()'s 2) Fix the do_large calcu
/archives/netdev/2004-09/msg02767.html (12,600 bytes)

155. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Tue, 28 Sep 2004 23:34:15 +0200
I admit I lost track of all your patches now - can you give me a big diff against the latest BK so that I can check that the problem is gone for me too? Thanks, -Andi
/archives/netdev/2004-09/msg02770.html (11,205 bytes)

156. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 14:53:45 -0700
Here are all of the pending TCP bug fixes, attached in order. I'll be pushing these to Linus some time today. Attachment: diff1 Description: Binary data Attachment: diff2 Description: Binary data Att
/archives/netdev/2004-09/msg02773.html (13,012 bytes)

157. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Wed, 29 Sep 2004 00:33:44 +0200
I'm afraid I must report it's still not completely solved for me yet. 10s netperf with TSO on with your patches gives now ~10MB/s less than with TSO off (57 vs 67). It's better than before, but not r
/archives/netdev/2004-09/msg02774.html (12,381 bytes)

158. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 15:57:06 -0700
Your system is SMP and packet reordering is occuring? If so, you can lock the interrupts of the card to a specific cpu to see if that makes the problem go away. Another possibility is tcpdump droppin
/archives/netdev/2004-09/msg02775.html (12,423 bytes)

159. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Wed, 29 Sep 2004 01:27:57 +0200
The sender is SMP, but the receiver is UP. I tcpdumped at the receiver. Possible, unfortunately there are no counters for this (anyone on netdev motivated to add them to each packet drop in PF_PACKET
/archives/netdev/2004-09/msg02780.html (13,154 bytes)

160. Re: bad TSO performance in 2.6.9-rc2-BK (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 28 Sep 2004 16:35:09 -0700
You might be missing the topmost part of the backtrace which is probably in tcp_clean_rtx_queue() or even more likely tcp_tso_acked() where there are several assertions present. I guess your compiler
/archives/netdev/2004-09/msg02781.html (12,684 bytes)


This search system is powered by Namazu