| To: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: bad TSO performance in 2.6.9-rc2-BK |
| From: | Nivedita Singhvi <niv@xxxxxxxxxx> |
| Date: | Wed, 29 Sep 2004 14:16:55 -0700 |
| Cc: | John Heffner <jheffner@xxxxxxx>, ak@xxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20040929140016.7ffa4e8b.davem@xxxxxxxxxxxxx> |
| References: | <20040928223344.GC2975@xxxxxxxxxxxxx> <Pine.NEB.4.33.0409282323220.27103-100000@xxxxxxxxxxxxxx> <20040929140016.7ffa4e8b.davem@xxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 |
David S. Miller wrote: > I think you hit the jackpot John... or at least you're on the right trail. It seems I'll have to do some send buffer liberation when we partially ACK TSO frames. Since that isn't happening currently, this window advancing test never passes until the full TSO frame is freed up at the sender side. Patch coming... That was my point to Herbert, Dave - that we can't rely on Nagle - either we're triggering too early and not utilizing TSO MTU or we're triggering too late (waiting for the full TSO frame) depending on whether we use standard or TSO mss.. We need some heuristic to do partial sends under TSO. Is that what you are addressing? thanks, Nivedita |
| Previous by Date: | Re: Please route new work through -mm tree?, Gerrit Huizenga |
|---|---|
| Next by Date: | Re: bad TSO performance in 2.6.9-rc2-BK, David S. Miller |
| Previous by Thread: | Re: bad TSO performance in 2.6.9-rc2-BK, David S. Miller |
| Next by Thread: | Re: bad TSO performance in 2.6.9-rc2-BK, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |