| To: | herbert@xxxxxxxxxxxxxxxxxxx |
|---|---|
| Subject: | Re: issue with new TCP TSO stuff |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Thu, 12 May 2005 15:52:30 -0700 (PDT) |
| Cc: | netdev@xxxxxxxxxxx |
| In-reply-to: | <20050512221046.GA22136@gondor.apana.org.au> |
| References: | <20050512.131349.32715242.davem@davemloft.net> <20050512214744.GA21958@gondor.apana.org.au> <20050512221046.GA22136@gondor.apana.org.au> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Subject: Re: issue with new TCP TSO stuff Date: Fri, 13 May 2005 08:10:46 +1000 > Nevermind, you're comparing to the existing TSO implementation. > So how big exactly is the slowdown? The "scp largefile dest:" test case went down from 4.6MB/sec to 4.3MB/sec when I enable TSO on the tg3 device with the new TSO code. So that drop is relative to non-TSO. That's how I knew there was some trouble. TSO should definitely not have more overhead that non-TSO. For a clean transfer bulk transfer which is not application limited like scp is, we get full line rate. But that doesn't show how expensive TSO is, since the link is the bottleneck not the cpu. > This just occured to me, what about NETIF_F_SKBLIST? Sounds ok. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | ipw2100: intrusive cleanups, working this time ;-), Pavel Machek |
|---|---|
| Next by Date: | Re: issue with new TCP TSO stuff, Herbert Xu |
| Previous by Thread: | Re: issue with new TCP TSO stuff, Herbert Xu |
| Next by Thread: | Re: issue with new TCP TSO stuff, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |