| To: | "David S. Miller" <davem@xxxxxxxxxx> |
|---|---|
| Subject: | Re: e1000 performance hack for ppc64 (Power4) |
| From: | Lincoln Dale <ltd@xxxxxxxxx> |
| Date: | Sat, 14 Jun 2003 15:52:35 +1000 |
| Cc: | anton@xxxxxxxxx, haveblue@xxxxxxxxxx, hdierks@xxxxxxxxxx, scott.feldman@xxxxxxxxx, dwg@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, milliner@xxxxxxxxxx, ricardoz@xxxxxxxxxx, twichell@xxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20030613.224122.104034261.davem@xxxxxxxxxx> |
| References: | <5.1.0.14.2.20030614114755.036abbb0@xxxxxxxxxxxxxxxxxxxxx> <20030613.154634.74748085.davem@xxxxxxxxxx> <20030613231836.GD32097@krispykreme> <5.1.0.14.2.20030614114755.036abbb0@xxxxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
At 10:41 PM 13/06/2003 -0700, David S. Miller wrote: From: Lincoln Dale <ltd@xxxxxxxxx> Date: Sat, 14 Jun 2003 11:52:53 +1000 unless i misunderstand the problem, you can certainly pad the TCP options with NOPs ... You may not mangle packet if it is not your's alone. And every TCP packet is shared with TCP retransmit queue and therefore would need to be copied before being mangled. ok, so lets take this a step further.can we have the TCP retransmit side take a performance hit if it needs to realign buffers? once again, for a "high performance app" requiring gigabit-type speeds, its probably fair to say that this is mostly in the realm of applications on a LAN rather than across a WAN or internet. on a switched LAN, i'd expect TCP retransmissions to be far fewer ... cheers, lincoln. |
| Previous by Date: | Re: e1000 performance hack for ppc64 (Power4), David S. Miller |
|---|---|
| Next by Date: | Re: e1000 performance hack for ppc64 (Power4), David S. Miller |
| Previous by Thread: | Re: e1000 performance hack for ppc64 (Power4), David S. Miller |
| Next by Thread: | Re: e1000 performance hack for ppc64 (Power4), David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |