netdev
[Top] [All Lists]

Re: e1000 performance hack for ppc64 (Power4)

To: Anton Blanchard <anton@xxxxxxxxx>
Subject: Re: e1000 performance hack for ppc64 (Power4)
From: Lincoln Dale <ltd@xxxxxxxxx>
Date: Sat, 14 Jun 2003 11:52:53 +1000
Cc: "David S. Miller" <davem@xxxxxxxxxx>, haveblue@xxxxxxxxxx, hdierks@xxxxxxxxxx, scott.feldman@xxxxxxxxx, dwg@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, milliner@xxxxxxxxxx, ricardoz@xxxxxxxxxx, twichell@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20030613231836.GD32097@krispykreme>
References: <20030613.154634.74748085.davem@redhat.com> <OF0078342A.E131D4B1-ON85256D44.0051F7C0@pok.ibm.com> <1055521263.3531.2055.camel@nighthawk> <20030613223841.GB32097@krispykreme> <20030613.154634.74748085.davem@redhat.com>
Sender: netdev-bounce@xxxxxxxxxxx
At 09:18 AM 14/06/2003 +1000, Anton Blanchard wrote:

> Not really... one retransmit and the TCP header size grows
> due to the SACK options.

OK scratch that idea.

why not have a performance option that is a tradeoff between optimum payload size versus efficiency.


unless i misunderstand the problem, you can certainly pad the TCP options with NOPs ...

> I find it truly bletcherous what you're trying to do here.

I think so too, but its hard to ignore ~100Mbit/sec in performance.

another option is for the write() path is for instantant-send TCP sockets to delay the copy_from_user() until the IP+TCP header size is known.
i wouldn't expect the net folks to like that, however ..



cheers,

lincoln.


<Prev in Thread] Current Thread [Next in Thread>