Message-ID: <c64e0dde-ce6a-4528-ad11-bfe3a90c2623@suse.de>
Date: Fri, 19 Sep 2025 08:43:58 +0200
From: Hannes Reinecke <hare@...e.de>
To: Xin Long <lucien.xin@...il.com>, network dev <netdev@...r.kernel.org>,
 quic@...ts.linux.dev
Cc: davem@...emloft.net, kuba@...nel.org, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 Stefan Metzmacher <metze@...ba.org>, Moritz Buhl <mbuhl@...nbsd.org>,
 Tyler Fanelli <tfanelli@...hat.com>, Pengtao He <hepengtao@...omi.com>,
 linux-cifs@...r.kernel.org, Steve French <smfrench@...il.com>,
 Namjae Jeon <linkinjeon@...nel.org>, Paulo Alcantara <pc@...guebit.com>,
 Tom Talpey <tom@...pey.com>, kernel-tls-handshake@...ts.linux.dev,
 Chuck Lever <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>,
 Benjamin Coddington <bcodding@...hat.com>, Steve Dickson
 <steved@...hat.com>, Alexander Aring <aahringo@...hat.com>,
 David Howells <dhowells@...hat.com>, Matthieu Baerts <matttbe@...nel.org>,
 John Ericson <mail@...nericson.me>, Cong Wang <xiyou.wangcong@...il.com>,
 "D . Wythe" <alibuda@...ux.alibaba.com>, Jason Baron <jbaron@...mai.com>,
 illiliti <illiliti@...tonmail.com>, Sabrina Dubroca <sd@...asysnail.net>,
 Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
 Daniel Stenberg <daniel@...x.se>,
 Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v3 00/15] net: introduce QUIC infrastructure and
 core subcomponents

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@...e.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

Powered by blists - more mailing lists