mbox series

[net-next,0/3] tcp: decouple TLP timer from RTO timer

Message ID 20191022231051.30770-1-xiyou.wangcong@gmail.com
Headers show
Series tcp: decouple TLP timer from RTO timer | expand

Message

Cong Wang Oct. 22, 2019, 11:10 p.m. UTC
This patchset contains 3 patches: patch 1 is a cleanup,
patch 2 is a small change preparing for patch 3, patch 3 is the
one does the actual change. Please find details in each of them.

---
Cong Wang (3):
  tcp: get rid of ICSK_TIME_EARLY_RETRANS
  tcp: make tcp_send_loss_probe() boolean
  tcp: decouple TLP timer from RTO timer

 include/net/inet_connection_sock.h | 13 +++++----
 include/net/tcp.h                  |  3 ++-
 net/dccp/timer.c                   |  2 +-
 net/ipv4/inet_connection_sock.c    |  5 +++-
 net/ipv4/inet_diag.c               |  8 ++++--
 net/ipv4/tcp_input.c               |  8 ++++--
 net/ipv4/tcp_ipv4.c                |  6 +++--
 net/ipv4/tcp_output.c              |  8 ++++--
 net/ipv4/tcp_timer.c               | 43 +++++++++++++++++++++++++++---
 net/ipv6/tcp_ipv6.c                |  6 +++--
 10 files changed, 80 insertions(+), 22 deletions(-)

Comments

David Miller Oct. 28, 2019, 6:29 p.m. UTC | #1
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 22 Oct 2019 16:10:48 -0700

> This patchset contains 3 patches: patch 1 is a cleanup,
> patch 2 is a small change preparing for patch 3, patch 3 is the
> one does the actual change. Please find details in each of them.

Eric, have you had a chance to test this on a system with
suitable CPU arity?
Eric Dumazet Oct. 28, 2019, 6:34 p.m. UTC | #2
On Mon, Oct 28, 2019 at 11:29 AM David Miller <davem@davemloft.net> wrote:
>
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Tue, 22 Oct 2019 16:10:48 -0700
>
> > This patchset contains 3 patches: patch 1 is a cleanup,
> > patch 2 is a small change preparing for patch 3, patch 3 is the
> > one does the actual change. Please find details in each of them.
>
> Eric, have you had a chance to test this on a system with
> suitable CPU arity?

Yes, and I confirm I could not repro the issues at all.

I got a 100Gbit NIC, trying to increase the pressure a bit, and
driving this NIC at line rate was only using 2% of my 96 cpus host,
no spinlock contention of any sort.

Thanks.
Cong Wang Oct. 28, 2019, 8:13 p.m. UTC | #3
On Mon, Oct 28, 2019 at 11:34 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Mon, Oct 28, 2019 at 11:29 AM David Miller <davem@davemloft.net> wrote:
> >
> > From: Cong Wang <xiyou.wangcong@gmail.com>
> > Date: Tue, 22 Oct 2019 16:10:48 -0700
> >
> > > This patchset contains 3 patches: patch 1 is a cleanup,
> > > patch 2 is a small change preparing for patch 3, patch 3 is the
> > > one does the actual change. Please find details in each of them.
> >
> > Eric, have you had a chance to test this on a system with
> > suitable CPU arity?
>
> Yes, and I confirm I could not repro the issues at all.
>
> I got a 100Gbit NIC, trying to increase the pressure a bit, and
> driving this NIC at line rate was only using 2% of my 96 cpus host,
> no spinlock contention of any sort.

Please let me know if there is anything else I can provide to help
you to make the decision.

All I can say so far is this only happens on our hosts with 128
AMD CPU's. I don't see anything here related to AMD, so I think
only the number of CPU's (vs. number of TX queues?) matters.

Thanks.
Eric Dumazet Oct. 28, 2019, 8:31 p.m. UTC | #4
On Mon, Oct 28, 2019 at 1:13 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Mon, Oct 28, 2019 at 11:34 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Mon, Oct 28, 2019 at 11:29 AM David Miller <davem@davemloft.net> wrote:
> > >
> > > From: Cong Wang <xiyou.wangcong@gmail.com>
> > > Date: Tue, 22 Oct 2019 16:10:48 -0700
> > >
> > > > This patchset contains 3 patches: patch 1 is a cleanup,
> > > > patch 2 is a small change preparing for patch 3, patch 3 is the
> > > > one does the actual change. Please find details in each of them.
> > >
> > > Eric, have you had a chance to test this on a system with
> > > suitable CPU arity?
> >
> > Yes, and I confirm I could not repro the issues at all.
> >
> > I got a 100Gbit NIC, trying to increase the pressure a bit, and
> > driving this NIC at line rate was only using 2% of my 96 cpus host,
> > no spinlock contention of any sort.
>
> Please let me know if there is anything else I can provide to help
> you to make the decision.
>
> All I can say so far is this only happens on our hosts with 128
> AMD CPU's. I don't see anything here related to AMD, so I think
> only the number of CPU's (vs. number of TX queues?) matters.
>

I also have AMD hosts with 256 cpus, I can try them later (not today,
I am too busy)

But I feel you are trying to work around a more fundamental issue if
this problem only shows up on AMD hosts.
Cong Wang Oct. 29, 2019, 12:49 a.m. UTC | #5
On Mon, Oct 28, 2019 at 1:31 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Mon, Oct 28, 2019 at 1:13 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >
> > On Mon, Oct 28, 2019 at 11:34 AM Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > On Mon, Oct 28, 2019 at 11:29 AM David Miller <davem@davemloft.net> wrote:
> > > >
> > > > From: Cong Wang <xiyou.wangcong@gmail.com>
> > > > Date: Tue, 22 Oct 2019 16:10:48 -0700
> > > >
> > > > > This patchset contains 3 patches: patch 1 is a cleanup,
> > > > > patch 2 is a small change preparing for patch 3, patch 3 is the
> > > > > one does the actual change. Please find details in each of them.
> > > >
> > > > Eric, have you had a chance to test this on a system with
> > > > suitable CPU arity?
> > >
> > > Yes, and I confirm I could not repro the issues at all.
> > >
> > > I got a 100Gbit NIC, trying to increase the pressure a bit, and
> > > driving this NIC at line rate was only using 2% of my 96 cpus host,
> > > no spinlock contention of any sort.
> >
> > Please let me know if there is anything else I can provide to help
> > you to make the decision.
> >
> > All I can say so far is this only happens on our hosts with 128
> > AMD CPU's. I don't see anything here related to AMD, so I think
> > only the number of CPU's (vs. number of TX queues?) matters.
> >
>
> I also have AMD hosts with 256 cpus, I can try them later (not today,
> I am too busy)
>
> But I feel you are trying to work around a more fundamental issue if
> this problem only shows up on AMD hosts.

I wish I have Intel hosts with the same number of CPU's, but I don't,
all Intel ones have less, probably 80 at max. This is why I think it
is related to the number of CPU's.

Also, IOMMU is turned off explicitly, I don't see anything else could
be AMD specific along the TCP path.

Thanks.
David Miller Oct. 30, 2019, 9:56 p.m. UTC | #6
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 22 Oct 2019 16:10:48 -0700

> This patchset contains 3 patches: patch 1 is a cleanup,
> patch 2 is a small change preparing for patch 3, patch 3 is the
> one does the actual change. Please find details in each of them.

I'm marking this deferred until someone can drill down why this is
only seen in such a specific configuration, and not to ANY EXTENT
whatsoever with just a slightly lower number of CPUs on other
machines.

It's really hard to justify this set of changes without a full
understanding and detailed analysis.

Thanks.