Re: limited network bandwidth with 3.2.x kernels

[Ben Hutchings <bhutchings@solarflare.com>]

On Thu, 2012-02-16 at 16:09 +0100, Eric Dumazet wrote:
> Le jeudi 16 février 2012 à 13:51 +0000, Ben Hutchings a écrit :
> 
> > I'm aware of this problem and I believe it exists with most
> > implementations of LRO.
> > 
> > The out-of-tree version of the sfc driver has its own soft-LRO
> > implementation (SSR) which does some limited connection tracking to
> > detect slow start and disable aggregation temporarily.  I've been
> > meaning to look into enhancing GRO to match SSR, but haven't got round
> > to it yet.
> 
> 
> Not sure why we cant change tcp_grow_window() to take into account
> number of segments in skb ?

Maybe it's as simple as that.  I don't pretend to understand the details
of TCP flow control.

I checked with David Riddoch who originally implemented SSR.  His
concern was that each aggregated packet received results in at most one
ACK and some senders then won't grow their congestion window as fast as
they would if we were ACKing each wire-level packet (or every 2
packets).  But since current Linux *as a sender* counts the ACKed bytes
and not the packets, I don't think it's relevant to this particular
problem.

Ben.

> It currently increments rcv_ssthresh by a fixed amount (2 * advmss)
> 
>         if (tcp_win_from_space(skb->truesize) <= skb->len)
>                 incr = 2 * tp->advmss;
>         else
>                 incr = __tcp_grow_window(sk, skb);
>         if (incr) {
>                 tp->rcv_ssthresh = min(tp->rcv_ssthresh + incr,
>                                        tp->window_clamp);
>                 inet_csk(sk)->icsk_ack.quick |= 1;
>                 }
> 
> 
> 

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.