netdev - Re: limited network bandwidth with 3.2.x kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Feb 2012 13:39:00 -0500
From:	Neal Cardwell <ncardwell@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: limited network bandwidth with 3.2.x kernels

On Wed, Feb 22, 2012 at 2:36 AM, Eric Dumazet <eric.dumazet@...il.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html