Re: limited network bandwidth with 3.2.x kernels

Neal Cardwell
2012-02-23T18:39:02Z

On Wed, Feb 22, 2012 at 2:36 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> This skb->truesize/skb->len affair is suspect if you ask me.
>
> We increase rcv_ssthresh if we receive a 'good skb', but we have no
> guarantee of future skbs.
>
> When we are close to the converged value, we might spend some time in
> tcp_grow_window() and decide not to increase rcv_sshthresh
>
> IMHO a better way would be to look at integration values
> (sk->sk_rmem_alloc) to not increase rcv_sshthresh if socket receive
> queue is full of 'bad skbs'

I agree that using a single skb->truesize/skb->len sample is
unfortunate, and it would be nice to have a larger sample size.

Looking at sk->sk_rmem_alloc would be an improvement, though I'm
guessing that often this will still be a small sample of just a couple
of packets, for the case of well-behaved apps that mostly keep up with
reading everything that arrives in their read buffer.

If we wanted a larger sample of truesize/len ratios, perhaps we'd want
some sort of exponentially weighted moving average of skb->truesize
and skb->len, or the ratio of the two. That could give us a larger
sample even for well-behaved apps that keep their read queues short.
But that is starting to seem like it's perhaps overkill.

> Note that with your patch and 'good skb', rcv_ssthresh increases slower
> than before (MSS increases instead of 2*MSS)

Good point. How about:

u32 incr = max(skb->len, 2U * tp->advmss);

Or do you think we'd want:

u32 incr = 2U * max(skb->len, tp->advmss);

neal