Re: GRO aggregation

On 9/12/2012 7:52 PM, Rick Jones wrote:

On 09/12/2012 09:34 AM, Shlomo Pongartz wrote:

quoted

On 9/12/2012 7:23 PM, Rick Jones wrote:

quoted

On 09/12/2012 07:41 AM, Shlomo Pongartz wrote:

quoted

Hi Eric

The TSO is just a mean to create a burst of frames on the wire so the
NAPI will be able to pool as much as possible.

Is it?  If I recall correctly, TSO was in place well before all
drivers were using NAPI.  And NAPI was being proposed independent of
TSO. TSO is there to save CPU cycles on the transmit side. "On the
wire" what it sends is to be identical to what a host with greater CPU
performance could accomplish.

rick jones

Hi Rick.

What I say is that I use TSO on the machine that transmits so I'll have
a burst of frames on the wire for the NAPI on the receiver machine.

Also, NAPI was in place before GRO.  IIRC, the napi code was simply a 
convenient/correct/natural place to have the GRO functionality.

rick jones

Hi Rick

The thing is that napi_complete calls napi_gro_flush so this pose a 
limit on the aggregation.
However when I count the number of packets received until this routine 
is been called, I get a number,
which is bigger then what I see with tcpdump, and this number is less 
than what is expected if the limit is 64K.
So I what to know what can I do in order to improve things, e.g. 
allocate the skb differently.

Shlomo