From: Hannes Reinecke <hare@suse.de>
To: Xin Long <lucien.xin@gmail.com>,
network dev <netdev@vger.kernel.org>,
quic@lists.linux.dev
Cc: 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 08:43:58 +0200 [thread overview]
Message-ID: <c64e0dde-ce6a-4528-ad11-bfe3a90c2623@suse.de> (raw)
In-Reply-To: <cover.1758234904.git.lucien.xin@gmail.com>
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
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.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2025-09-19 6:44 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 ` Hannes Reinecke [this message]
2025-09-19 14:41 ` [PATCH net-next v3 00/15] net: introduce QUIC infrastructure and core subcomponents Xin Long
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=c64e0dde-ce6a-4528-ad11-bfe3a90c2623@suse.de \
--to=hare@suse.de \
--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=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=lucien.xin@gmail.com \
--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