Subject: Re: GRO aggregation

From: Marcelo Ricardo Leitner <[email-masked]>
Date: Tue, 11 Sep 2012 15:48:13 -0300

On 09/11/2012 03:41 PM, Shlomo Pongratz wrote:
> From: Marcelo Ricardo Leitner [[email-masked]]
> Sent: Tuesday, September 11, 2012 9:20 PM
> To: Shlomo Pongratz
> Cc: [email-masked]
> Subject: Re: GRO aggregation
>
> On 09/11/2012 10:45 AM, Shlomo Pongartz wrote:
>> Hi,
>>
>> I’m checking GRO aggregation with kernel 3.6.0-rc1+ using Intel ixgbe
>> driver.
>> The mtu is 1500 and GRO is on and so are SG and RX checksum.
>> I ran iperf with default setting and monitor the receiver with tcpdump.
>> The tcpdump shows that the maximal aggregation is 32120 which is 21 * 1500.
>> In the transmitter side tcpdump shows that TSO works better (~64K).
>> I did a capture without GRO enabled to see if there was a difference
>> between any flag
>> of any two consecutive packets that forced flushing but didn't find
>> anything.
>> Is the GRO aggregation can be tuned.
>
> Hi Shlomo,
>
> Have you tried tuning coalescing parameters?
>
> Marcelo
>
>
> Hi Marcelo
>
> I didn't play with interrupts coalescing.
> Do you suggest to increase the value?

Actually it was an idea from top of my mind, I don't know how it applies 
to ixgbe, sorry. But making the NIC hold the packets a bit more should 
make it send larger ones to kernel. Trade-off between latency/throughput.

I was thinking about ethtool -c options, like rx-usecs*

Marcelo