| To: | Rick Jones <rick.jones2@xxxxxx> |
|---|---|
| Subject: | Re: e1000 (?) jumbo frames performance issue |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Thu, 5 May 2005 15:17:20 -0700 |
| Cc: | netdev@xxxxxxxxxxx, m.iatrou@xxxxxxxxxxx |
| In-reply-to: | <427A9623.5060402@xxxxxx> |
| References: | <200505051928.32496.m.iatrou@xxxxxxxxxxx> <427A7F5B.8050704@xxxxxx> <20050505143318.004566a9.davem@xxxxxxxxxxxxx> <427A9623.5060402@xxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Thu, 05 May 2005 14:54:43 -0700 Rick Jones <rick.jones2@xxxxxx> wrote: > assuming of course that the intent of the algorithm was to try to get the > average header/header+data ratio to something > around 0.9 (although IIRC, none of a 537 byte send would be delayed by Nagle > since it was the size of the user's send being >= the MSS, so make that ~0.45 > ?) It tries to hold smaller packets back in hopes to get some more sendmsg() calls which will bunch up some more data before all outstanding data is ACK'd. It's meant for terminal protocols and other chatty sequences. It was not designed with 16K MSS frame sizes in mind. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: netfilter6: ICMPv6 type 143 doesn't match, David Stevens |
|---|---|
| Next by Date: | Re: resend patch: xfrm policybyid, David S. Miller |
| Previous by Thread: | Re: e1000 (?) jumbo frames performance issue, Rick Jones |
| Next by Thread: | Re: e1000 (?) jumbo frames performance issue, Michael Iatrou |
| Indexes: | [Date] [Thread] [Top] [All Lists] |