All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: eric.dumazet@gmail.com
Cc: netdev@vger.kernel.org, ncardwell@google.com, ycheng@google.com
Subject: Re: [PATCH net-next] tcp: add tcp_add_backlog()
Date: Mon, 29 Aug 2016 00:20:42 -0400 (EDT)	[thread overview]
Message-ID: <20160829.002042.876057972687474994.davem@davemloft.net> (raw)
In-Reply-To: <1472308674.14381.226.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 27 Aug 2016 07:37:54 -0700

> From: Eric Dumazet <edumazet@google.com>
> 
> When TCP operates in lossy environments (between 1 and 10 % packet
> losses), many SACK blocks can be exchanged, and I noticed we could
> drop them on busy senders, if these SACK blocks have to be queued
> into the socket backlog.
> 
> While the main cause is the poor performance of RACK/SACK processing,
> we can try to avoid these drops of valuable information that can lead to
> spurious timeouts and retransmits.
> 
> Cause of the drops is the skb->truesize overestimation caused by :
> 
> - drivers allocating ~2048 (or more) bytes as a fragment to hold an
>   Ethernet frame.
> 
> - various pskb_may_pull() calls bringing the headers into skb->head
>   might have pulled all the frame content, but skb->truesize could
>   not be lowered, as the stack has no idea of each fragment truesize.
> 
> The backlog drops are also more visible on bidirectional flows, since
> their sk_rmem_alloc can be quite big.
> 
> Let's add some room for the backlog, as only the socket owner
> can selectively take action to lower memory needs, like collapsing
> receive queues or partial ofo pruning.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Really nice change, thanks Eric.

  parent reply	other threads:[~2016-08-29  4:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-27 14:37 [PATCH net-next] tcp: add tcp_add_backlog() Eric Dumazet
2016-08-27 16:13 ` Yuchung Cheng
2016-08-27 16:25   ` Eric Dumazet
2016-08-29 16:53     ` Yuchung Cheng
2016-08-27 18:24 ` Neal Cardwell
2016-08-29  4:20 ` David Miller [this message]
2016-08-29 18:51 ` Marcelo Ricardo Leitner
2016-08-29 19:22   ` Eric Dumazet
2016-08-29 19:33     ` Marcelo Ricardo Leitner
2016-09-22 22:34 ` Marcelo Ricardo Leitner
2016-09-22 23:21   ` Eric Dumazet
2016-09-23 12:45     ` Marcelo Ricardo Leitner
2016-09-23 13:42       ` Eric Dumazet
2016-09-23 14:09         ` Marcelo Ricardo Leitner
2016-09-23 14:36           ` Eric Dumazet
2016-09-23 14:43             ` David Laight
2016-09-23 15:12             ` Marcelo Ricardo Leitner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160829.002042.876057972687474994.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=ycheng@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.