All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: edumazet@google.com, netdev@vger.kernel.org,
	ncardwell@google.com, ycheng@google.com, soheil@google.com,
	oleksandr@natalenko.name, eric.dumazet@gmail.com,
	linux-sctp@vger.kernel.org
Subject: Re: [PATCH net-next 0/6] tcp: remove non GSO code
Date: Wed, 28 Feb 2018 20:10:18 +0000	[thread overview]
Message-ID: <20180228201018.GA3887@localhost.localdomain> (raw)
In-Reply-To: <20180221.143748.516809068075257257.davem@davemloft.net>

On Wed, Feb 21, 2018 at 02:37:48PM -0500, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Mon, 19 Feb 2018 11:56:46 -0800
> 
> > Switching TCP to GSO mode, relying on core networking layers
> > to perform eventual adaptation for dumb devices was overdue.
> > 
> > 1) Most TCP developments are done with TSO in mind.
> > 2) Less high-resolution timers needs to be armed for TCP-pacing
> > 3) GSO can benefit of xmit_more hint
> > 4) Receiver GRO is more effective (as if TSO was used for real on sender)
> >    -> less ACK packets and overhead.
> > 5) Write queues have less overhead (one skb holds about 64KB of payload)
> > 6) SACK coalescing just works. (no payload in skb->head)
> > 7) rtx rb-tree contains less packets, SACK is cheaper.
> > 8) Removal of legacy code. Less maintenance hassles.
> > 
> > Note that I have left the sendpage/zerocopy paths, but they probably can
> > benefit from the same strategy.
> > 
> > Thanks to Oleksandr Natalenko for reporting a performance issue for BBR/fq_codel,
> > which was the main reason I worked on this patch series.
> 
> Series applied, thanks Eric.
> 
> SCTP might want to do something similar, and if so we can get rid
> of sk_can_gso() too.

Cc'ing linux-sctp and adding to the ToDo here, although it may be too
soon for SCTP. GSO support was added just a few months ago and
considering that it is not that much widely used as TCP, I fear we may
have some issues that didn't show up yet.

  Marcelo

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: edumazet@google.com, netdev@vger.kernel.org,
	ncardwell@google.com, ycheng@google.com, soheil@google.com,
	oleksandr@natalenko.name, eric.dumazet@gmail.com,
	linux-sctp@vger.kernel.org
Subject: Re: [PATCH net-next 0/6] tcp: remove non GSO code
Date: Wed, 28 Feb 2018 17:10:18 -0300	[thread overview]
Message-ID: <20180228201018.GA3887@localhost.localdomain> (raw)
In-Reply-To: <20180221.143748.516809068075257257.davem@davemloft.net>

On Wed, Feb 21, 2018 at 02:37:48PM -0500, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Mon, 19 Feb 2018 11:56:46 -0800
> 
> > Switching TCP to GSO mode, relying on core networking layers
> > to perform eventual adaptation for dumb devices was overdue.
> > 
> > 1) Most TCP developments are done with TSO in mind.
> > 2) Less high-resolution timers needs to be armed for TCP-pacing
> > 3) GSO can benefit of xmit_more hint
> > 4) Receiver GRO is more effective (as if TSO was used for real on sender)
> >    -> less ACK packets and overhead.
> > 5) Write queues have less overhead (one skb holds about 64KB of payload)
> > 6) SACK coalescing just works. (no payload in skb->head)
> > 7) rtx rb-tree contains less packets, SACK is cheaper.
> > 8) Removal of legacy code. Less maintenance hassles.
> > 
> > Note that I have left the sendpage/zerocopy paths, but they probably can
> > benefit from the same strategy.
> > 
> > Thanks to Oleksandr Natalenko for reporting a performance issue for BBR/fq_codel,
> > which was the main reason I worked on this patch series.
> 
> Series applied, thanks Eric.
> 
> SCTP might want to do something similar, and if so we can get rid
> of sk_can_gso() too.

Cc'ing linux-sctp and adding to the ToDo here, although it may be too
soon for SCTP. GSO support was added just a few months ago and
considering that it is not that much widely used as TCP, I fear we may
have some issues that didn't show up yet.

  Marcelo

  reply	other threads:[~2018-02-28 20:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-19 19:56 [PATCH net-next 0/6] tcp: remove non GSO code Eric Dumazet
2018-02-19 19:56 ` [PATCH net-next 1/6] tcp: switch to GSO being always on Eric Dumazet
2018-02-20  1:22   ` kbuild test robot
2018-02-19 19:56 ` [PATCH net-next 2/6] tcp: remove sk_can_gso() use Eric Dumazet
2018-02-19 19:56 ` [PATCH net-next 3/6] tcp: remove sk_check_csum_caps() Eric Dumazet
2018-02-19 19:56 ` [PATCH net-next 4/6] tcp: tcp_sendmsg() only deals with CHECKSUM_PARTIAL Eric Dumazet
2018-02-19 19:56 ` [PATCH net-next 5/6] tcp: remove dead code from tcp_set_skb_tso_segs() Eric Dumazet
2018-02-19 19:56 ` [PATCH net-next 6/6] tcp: remove dead code after CHECKSUM_PARTIAL adoption Eric Dumazet
2018-02-20  1:45 ` [PATCH net-next 0/6] tcp: remove non GSO code Soheil Hassas Yeganeh
2018-02-20  9:32 ` Oleksandr Natalenko
2018-02-20 15:39   ` Eric Dumazet
2018-02-20 18:57     ` Eric Dumazet
2018-02-20 19:35       ` Oleksandr Natalenko
2018-02-20 19:39         ` Eric Dumazet
2018-02-20 19:51           ` Oleksandr Natalenko
2018-02-20 19:56             ` Eric Dumazet
2018-02-20 20:06               ` Oleksandr Natalenko
2018-02-20 20:09               ` Eric Dumazet
2018-02-20 20:45                 ` Oleksandr Natalenko
2018-02-20 23:21                   ` Eric Dumazet
2018-02-21  6:14                     ` Oleksandr Natalenko
2018-02-21 14:43                     ` [PATCH net] tcp_bbr: better deal with suboptimal GSO Eric Dumazet
2018-02-21 15:01                       ` Paolo Abeni
2018-02-21 15:09                         ` Eric Dumazet
2018-02-21 15:55                           ` Paolo Abeni
2018-02-21 15:14                       ` Neal Cardwell
2018-02-21 15:18                         ` Soheil Hassas Yeganeh
2018-02-22 19:16                       ` David Miller
2018-02-21 19:37 ` [PATCH net-next 0/6] tcp: remove non GSO code David Miller
2018-02-28 20:10   ` Marcelo Ricardo Leitner [this message]
2018-02-28 20:10     ` 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=20180228201018.GA3887@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-sctp@vger.kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=oleksandr@natalenko.name \
    --cc=soheil@google.com \
    --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.