[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dacd415c06bc854136ba93ef258e92292b782037.camel@redhat.com>
Date: Mon, 15 Nov 2021 22:40:40 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Soheil Hassas Yeganeh <soheil@...gle.com>,
Eric Dumazet <eric.dumazet@...il.com>
Cc: "David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
netdev <netdev@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>,
Neal Cardwell <ncardwell@...gle.com>,
Arjun Roy <arjunroy@...gle.com>
Subject: Re: [PATCH net-next 00/20] tcp: optimizations for linux-5.17
Hello,
On Mon, 2021-11-15 at 15:37 -0500, Soheil Hassas Yeganeh wrote:
> On Mon, Nov 15, 2021 at 2:02 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
> >
> > From: Eric Dumazet <edumazet@...gle.com>
> >
> > Mostly small improvements in this series.
> >
> > The notable change is in "defer skb freeing after
> > socket lock is released" in recvmsg() (and RX zerocopy)
> >
> > The idea is to try to let skb freeing to BH handler,
> > whenever possible, or at least perform the freeing
> > outside of the socket lock section, for much improved
> > performance. This idea can probably be extended
> > to other protocols.
> >
> > Tests on a 100Gbit NIC
> > Max throughput for one TCP_STREAM flow, over 10 runs.
> >
> > MTU : 1500 (1428 bytes of TCP payload per MSS)
> > Before: 55 Gbit
> > After: 66 Gbit
> >
> > MTU : 4096+ (4096 bytes of TCP payload, plus TCP/IPv6 headers)
> > Before: 82 Gbit
> > After: 95 Gbit
>
> Acked-by: Soheil Hassas Yeganeh <soheil@...gle.com>
>
> Wow, this is really impressive. I reviewed all the patches and I can't
> point out any issues other than the typo that Arjun has pointed out.
> Thank you Eric!
Possibly there has been some issues with the ML while processing these
patches?!? only an handful of them reached patchwork (and my mailbox :)
(/me was just curious about the code ;)
Cheers,
Paolo
Powered by blists - more mailing lists