From: Xin Long <lucien.xin@gmail.com>
To: Hannes Reinecke <hare@suse.de>
Cc: network dev <netdev@vger.kernel.org>,
quic@lists.linux.dev, davem@davemloft.net, kuba@kernel.org,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Stefan Metzmacher <metze@samba.org>,
Moritz Buhl <mbuhl@openbsd.org>,
Tyler Fanelli <tfanelli@redhat.com>,
Pengtao He <hepengtao@xiaomi.com>,
linux-cifs@vger.kernel.org, Steve French <smfrench@gmail.com>,
Namjae Jeon <linkinjeon@kernel.org>,
Paulo Alcantara <pc@manguebit.com>, Tom Talpey <tom@talpey.com>,
kernel-tls-handshake@lists.linux.dev,
Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>,
Benjamin Coddington <bcodding@redhat.com>,
Steve Dickson <steved@redhat.com>,
Alexander Aring <aahringo@redhat.com>,
David Howells <dhowells@redhat.com>,
Matthieu Baerts <matttbe@kernel.org>,
John Ericson <mail@johnericson.me>,
Cong Wang <xiyou.wangcong@gmail.com>,
"D . Wythe" <alibuda@linux.alibaba.com>,
Jason Baron <jbaron@akamai.com>,
illiliti <illiliti@protonmail.com>,
Sabrina Dubroca <sd@queasysnail.net>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Daniel Stenberg <daniel@haxx.se>,
Andy Gospodarek <andrew.gospodarek@broadcom.com>
Subject: Re: [PATCH net-next v3 00/15] net: introduce QUIC infrastructure and core subcomponents
Date: Fri, 19 Sep 2025 10:41:58 -0400 [thread overview]
Message-ID: <CADvbK_d1fuyoG_F8jXNSyuicFqDxmbwSp06mkE1GvgTFkYRm5A@mail.gmail.com> (raw)
In-Reply-To: <c64e0dde-ce6a-4528-ad11-bfe3a90c2623@suse.de>
On Fri, Sep 19, 2025 at 2:44 AM Hannes Reinecke <hare@suse.de> wrote:
>
> On 9/19/25 00:34, Xin Long wrote:
> > Introduction
> > ============
> >
> > The QUIC protocol, defined in RFC 9000, is a secure, multiplexed transport
> > built on top of UDP. It enables low-latency connection establishment,
> > stream-based communication with flow control, and supports connection
> > migration across network paths, while ensuring confidentiality, integrity,
> > and availability.
> >
> [ .. ]>
> > - Performance Testing
> >
> > Performance was benchmarked using iperf [8] over a 100G NIC with
> > using various MTUs and packet sizes:
> >
> > - QUIC vs. kTLS:
> >
> > UNIT size:1024 size:4096 size:16384 size:65536
> > Gbits/sec QUIC | kTLS QUIC | kTLS QUIC | kTLS QUIC | kTLS
> > ────────────────────────────────────────────────────────────────────
> > mtu:1500 2.27 | 3.26 3.02 | 6.97 3.36 | 9.74 3.48 | 10.8
> > ────────────────────────────────────────────────────────────────────
> > mtu:9000 3.66 | 3.72 5.87 | 8.92 7.03 | 11.2 8.04 | 11.4
> >
> > - QUIC(disable_1rtt_encryption) vs. TCP:
> >
> > UNIT size:1024 size:4096 size:16384 size:65536
> > Gbits/sec QUIC | TCP QUIC | TCP QUIC | TCP QUIC | TCP
> > ────────────────────────────────────────────────────────────────────
> > mtu:1500 3.09 | 4.59 4.46 | 14.2 5.07 | 21.3 5.18 | 23.9
> > ────────────────────────────────────────────────────────────────────
> > mtu:9000 4.60 | 4.65 8.41 | 14.0 11.3 | 28.9 13.5 | 39.2
> >
> >
> I have been following the QUIC implementation progress for quite some
> while, and always found the performance impact rather frustrating.
> At the onset it looks as if you would suffer heavily from the additional
> complexity the QUIC protocol imposes up you.
> But that would make the use of QUIC rather pointless for most use-cases.
> So one wonders if this is not rather a problem of an unsuitable test
For fast networks, like the ones I used in my iperf tests, it’s expected
that QUIC does not outperform TCP+TLS at the time, The main reason is that
TCP has decades of kernel-level optimizations, including features like
GSO/GRO and even hardware offload support, which I don't think QUIC can
catch up due to its complexity.
That said, QUIC shows advantages in other scenarios web browsing or
similar workloads. QUIC can outperform TCP+TLS because of:
- Faster connection setup: QUIC combines the transport and TLS handshakes,
avoiding the extra round trips of TCP’s three-way handshake plus TLS
negotiation.
- No head-of-line blocking across streams: QUIC multiplexes multiple
streams over a single connection, so a single lost packet doesn’t stall
unrelated streams, unlike TCP.
> case. From my understanding QUIC is geared up for handling a
> multi-stream connection workload, so one should use an adequate test to
> simulate a multi-stream connection. Did you use the '-P' option for
> iperf when running the tests?
>
> And it might also be an idea to add QUIC support to iperf itself,
> especially transforming the '-P' option onto QUIC streams looks
> promising.
>
Yes, we could add QUIC to iperf, but then testing would need to include
packet loss and ensure the CPU isn’t the bottleneck, which moves away
from a fast-network environment.
Thanks Hannes for your comment. I’d be glad to hear any further ideas on
QUIC performance testing. So far, I haven’t seen a common method or tool
adopted for it from the community.
prev parent reply other threads:[~2025-09-19 14:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 22:34 [PATCH net-next v3 00/15] net: introduce QUIC infrastructure and core subcomponents Xin Long
2025-09-18 22:34 ` [PATCH net-next v3 01/15] net: define IPPROTO_QUIC and SOL_QUIC constants Xin Long
2025-09-18 22:34 ` [PATCH net-next v3 02/15] net: build socket infrastructure for QUIC protocol Xin Long
2025-09-23 11:07 ` Paolo Abeni
2025-09-23 15:47 ` Xin Long
2025-09-25 15:53 ` Paolo Abeni
2025-09-18 22:34 ` [PATCH net-next v3 03/15] quic: provide common utilities and data structures Xin Long
2025-09-23 9:06 ` Simon Horman
2025-09-23 15:49 ` Xin Long
2025-09-23 11:21 ` Paolo Abeni
2025-09-23 16:06 ` Xin Long
2025-09-25 15:50 ` Paolo Abeni
2025-09-18 22:34 ` [PATCH net-next v3 04/15] quic: provide family ops for address and protocol Xin Long
2025-09-23 11:30 ` Paolo Abeni
2025-09-23 16:15 ` Xin Long
2025-09-18 22:34 ` [PATCH net-next v3 05/15] quic: provide quic.h header files for kernel and userspace Xin Long
2025-09-18 22:34 ` [PATCH net-next v3 06/15] quic: add stream management Xin Long
2025-09-23 9:09 ` Simon Horman
2025-09-23 17:30 ` Xin Long
2025-09-23 13:39 ` Paolo Abeni
2025-09-23 17:57 ` Xin Long
2025-09-25 16:03 ` Paolo Abeni
2025-09-18 22:34 ` [PATCH net-next v3 07/15] quic: add connection id management Xin Long
2025-09-18 22:34 ` [PATCH net-next v3 08/15] quic: add path management Xin Long
2025-09-18 22:34 ` [PATCH net-next v3 09/15] quic: add congestion control Xin Long
2025-09-23 13:55 ` Paolo Abeni
2025-09-23 19:37 ` Xin Long
2025-09-18 22:34 ` [PATCH net-next v3 10/15] quic: add packet number space Xin Long
2025-09-18 22:35 ` [PATCH net-next v3 11/15] quic: add crypto key derivation and installation Xin Long
2025-09-18 22:35 ` [PATCH net-next v3 12/15] quic: add crypto packet encryption and decryption Xin Long
2025-09-18 22:35 ` [PATCH net-next v3 13/15] quic: add timer management Xin Long
2025-09-18 22:35 ` [PATCH net-next v3 14/15] quic: add frame encoder and decoder base Xin Long
2025-09-18 22:35 ` [PATCH net-next v3 15/15] quic: add packet builder and parser base Xin Long
2025-09-19 6:43 ` [PATCH net-next v3 00/15] net: introduce QUIC infrastructure and core subcomponents Hannes Reinecke
2025-09-19 14:41 ` Xin Long [this message]
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=CADvbK_d1fuyoG_F8jXNSyuicFqDxmbwSp06mkE1GvgTFkYRm5A@mail.gmail.com \
--to=lucien.xin@gmail.com \
--cc=aahringo@redhat.com \
--cc=alibuda@linux.alibaba.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=bcodding@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=daniel@haxx.se \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=hare@suse.de \
--cc=hepengtao@xiaomi.com \
--cc=horms@kernel.org \
--cc=illiliti@protonmail.com \
--cc=jbaron@akamai.com \
--cc=jlayton@kernel.org \
--cc=kernel-tls-handshake@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=mail@johnericson.me \
--cc=marcelo.leitner@gmail.com \
--cc=matttbe@kernel.org \
--cc=mbuhl@openbsd.org \
--cc=metze@samba.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pc@manguebit.com \
--cc=quic@lists.linux.dev \
--cc=sd@queasysnail.net \
--cc=smfrench@gmail.com \
--cc=steved@redhat.com \
--cc=tfanelli@redhat.com \
--cc=tom@talpey.com \
--cc=xiyou.wangcong@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox