David S. Miller wrote:
From: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Mon, 06 Jun 2005 21:53:32 -0700
I noticed that the tg3 driver copies packets less than a certain
threshold to a new buffer, but e1000 always passes the big buffer up
the stack. Could this be having an impact?
I bet it does, this makes ACK processing a lot more expensive.
Why would ACK processing care about the size of the buffer containing the ACK
is so much cheaper to just recycle the big buffer back to the chip
if you copy to a small buffer, and it warms up the caches for the
packet headers as a side effect as well.
I would think that the cache business would be a wash either way. With 64 byte
cache lines (128 in some cases) just accessing the link-level header has brought
the IP header into the cache, and probably the TCP header as well.
Isn't the decision point between the sum of allocating a small buffer and doing
the copy, versus allocating a new large buffer and (re)mapping it for DMA? I
guess that would come down to copy versus mapping overhead.
Actually, it has a _HUGE_ _HUGE_ impact. If you pass the big buffer
up, the receiving socket gets charged for the size of the huge buffer,
not for just the size of the packet contained within. This makes
sockets get overcharged for data reception, and it can cause all kinds
of performance problems.
Then copy when the socket is about to fill with overhead bytes?
I highly recommend that this gets fixed.
What is the cut-off point for the copy?