|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|
|References:||<20030613.154634.74748085.davem@xxxxxxxxxx> <OF0078342A.E131D4B1-ON85256D44.0051F7C0@xxxxxxxxxxx> <1055521263.3531.2055.camel@nighthawk> <20030613223841.GB32097@krispykreme> <20030613.154634.74748085.davem@xxxxxxxxxx>|
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>|
|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), Anton Blanchard|
|Next by Thread:||Re: e1000 performance hack for ppc64 (Power4), David S. Miller|
|Indexes:||[Date] [Thread] [Top] [All Lists]|