From: Paolo Abeni <pabeni@redhat.com>
To: lucien.xin@gmail.com
Cc: hepengtao@xiaomi.com, kuba@kernel.org, jlayton@kernel.org,
metze@samba.org, davem@davemloft.net,
kernel-tls-handshake@lists.linux.dev, horms@kernel.org,
hare@suse.de, aahringo@redhat.com, tfanelli@redhat.com,
mail@johnericson.me, andrew.gospodarek@broadcom.com,
linkinjeon@kernel.org, dhowells@redhat.com, matttbe@kernel.org,
xiyou.wangcong@gmail.com, dreibh@simula.no, jbaron@akamai.com,
quic@lists.linux.dev, pc@manguebit.com, marc@fiuczynski.com,
edumazet@google.com, pabeni@redhat.com,
alibuda@linux.alibaba.com, steved@redhat.com,
illiliti@protonmail.com, tom@talpey.com,
marcelo.leitner@gmail.com, sd@queasysnail.net,
linux-cifs@vger.kernel.org, netdev@vger.kernel.org,
mbuhl@openbsd.org, smfrench@gmail.com, chuck.lever@oracle.com,
daniel@haxx.se
Subject: Re: [net-next,v10,14/15] quic: add packet builder base
Date: Tue, 3 Mar 2026 09:33:38 +0100 [thread overview]
Message-ID: <20260303083338.35544-1-pabeni@redhat.com> (raw)
In-Reply-To: <e49a24b97a25a9c25bd33411b8212978dd566bd3.1771986861.git.lucien.xin@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
quic: add packet builder base
This patch introduces 'quic_packet' to handle packing of QUIC packets on
the transmit path, including frame packing, packet construction,
encryption, bundling, and transmission logic.
> diff --git a/net/quic/Makefile b/net/quic/Makefile
> index 2ccf01ad9e22..0f903f4a7ff1 100644
> --- a/net/quic/Makefile
> +++ b/net/quic/Makefile
> @@ -6,4 +6,4 @@
> obj-$(CONFIG_IP_QUIC) += quic.o
>
> quic-y := common.o family.o protocol.o socket.o stream.o connid.o path.o \
> - cong.o pnspace.o crypto.o timer.o
> + cong.o pnspace.o crypto.o timer.o packet.o
> diff --git a/net/quic/packet.c b/net/quic/packet.c
> new file mode 100644
> index 000000000000..a56edc745bb1
> --- /dev/null
> +++ b/net/quic/packet.c
[ ... ]
> +/* Perform routing for the QUIC packet on the specified path, update header length and MSS
> + * accordingly, reset path and start PMTU timer.
> + */
> +int quic_packet_route(struct sock *sk)
> +{
> + struct quic_path_group *paths = quic_paths(sk);
> + struct quic_packet *packet = quic_packet(sk);
> + union quic_addr *sa, *da;
> + u32 pmtu;
> + int err;
> +
> + da = quic_path_daddr(paths, packet->path);
> + sa = quic_path_saddr(paths, packet->path);
> + err = quic_flow_route(sk, da, sa, &paths->fl);
> + if (err)
> + return err;
> +
> + packet->hlen = quic_encap_len(da);
> + pmtu = min_t(u32, dst_mtu(__sk_dst_get(sk)), QUIC_PATH_MAX_PMTU);
> + quic_packet_mss_update(sk, pmtu - packet->hlen);
> +
> + quic_path_pl_reset(paths);
> + quic_timer_reset(sk, QUIC_TIMER_PMTU, paths->plpmtud_interval);
> + return 0;
> +}
> +
> +/* Configure the QUIC packet header and routing based on encryption level and path. */
> +int quic_packet_config(struct sock *sk, u8 level, u8 path)
> +{
[ ... ]
> +
> + /* Perform routing and MSS update for the configured packet. */
> + if (quic_packet_route(sk) < 0)
> + return -1;
> + return 0;
> +}
Should quic_packet_config() propagate the error code from
quic_packet_route() instead of returning -1?
The function quic_packet_route() returns proper negative errno values
(via quic_flow_route()), but quic_packet_config() replaces any error
with -1 (which is -EPERM). This could be misleading when diagnosing
routing failures.
> diff --git a/net/quic/packet.h b/net/quic/packet.h
> new file mode 100644
> index 000000000000..8c23be386207
> --- /dev/null
> +++ b/net/quic/packet.h
[ ... ]
> +static inline u8 quic_packet_taglen(struct quic_packet *packet)
> +{
> + return packet->taglen[!!packet->level];
> +}
> +
> +static inline void quic_packet_set_taglen(struct quic_packet *packet, u8 taglen)
> +{
> + packet->taglen[0] = taglen;
> +}
> +
> +static inline u32 quic_packet_mss(struct quic_packet *packet)
> +{
> + return packet->mss[0] - packet->taglen[!!packet->level];
> +}
> +
> +static inline u32 quic_packet_max_payload(struct quic_packet *packet)
> +{
> + return packet->mss[0] - packet->overhead - packet->taglen[!!packet->level];
> +}
> +
> +static inline u32 quic_packet_max_payload_dgram(struct quic_packet *packet)
> +{
> + return packet->mss[1] - packet->overhead - packet->taglen[!!packet->level];
> +}
This isn't a bug, but quic_packet_mss(), quic_packet_max_payload(),
and quic_packet_max_payload_dgram() all repeat the expression
'packet->taglen[!!packet->level]'.
Could these use quic_packet_taglen(packet) instead for consistency?
[ ... ]
next prev parent reply other threads:[~2026-03-03 8:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 2:34 [PATCH net-next v10 00/15] net: introduce QUIC infrastructure and core subcomponents Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 01/15] net: define IPPROTO_QUIC and SOL_QUIC constants Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 02/15] net: build socket infrastructure for QUIC protocol Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 03/15] quic: provide common utilities and data structures Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 04/15] quic: provide family ops for address and protocol Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 05/15] quic: provide quic.h header files for kernel and userspace Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 06/15] quic: add stream management Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 07/15] quic: add connection id management Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 08/15] quic: add path management Xin Long
2026-03-03 8:22 ` Paolo Abeni
2026-03-04 21:25 ` Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 09/15] quic: add congestion control Xin Long
2026-03-03 8:32 ` [net-next,v10,09/15] " Paolo Abeni
2026-03-04 21:41 ` Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 10/15] quic: add packet number space Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 11/15] quic: add crypto key derivation and installation Xin Long
2026-03-03 8:32 ` [net-next,v10,11/15] " Paolo Abeni
2026-03-04 21:58 ` Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 12/15] quic: add crypto packet encryption and decryption Xin Long
2026-03-03 8:32 ` [net-next,v10,12/15] " Paolo Abeni
2026-03-04 22:31 ` Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 13/15] quic: add timer management Xin Long
2026-03-03 8:33 ` [net-next,v10,13/15] " Paolo Abeni
2026-03-04 23:03 ` Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 14/15] quic: add packet builder base Xin Long
2026-03-03 8:33 ` Paolo Abeni [this message]
2026-03-04 23:13 ` [net-next,v10,14/15] " Xin Long
2026-03-03 9:18 ` [PATCH net-next v10 14/15] " Paolo Abeni
2026-03-04 23:26 ` Xin Long
2026-02-25 2:34 ` [PATCH net-next v10 15/15] quic: add packet parser base Xin Long
2026-03-03 8:33 ` [net-next,v10,15/15] " Paolo Abeni
2026-03-04 23:37 ` Xin Long
2026-03-03 9:16 ` [PATCH net-next v10 15/15] " Paolo Abeni
2026-03-05 0:14 ` 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=20260303083338.35544-1-pabeni@redhat.com \
--to=pabeni@redhat.com \
--cc=aahringo@redhat.com \
--cc=alibuda@linux.alibaba.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=chuck.lever@oracle.com \
--cc=daniel@haxx.se \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dreibh@simula.no \
--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=lucien.xin@gmail.com \
--cc=mail@johnericson.me \
--cc=marc@fiuczynski.com \
--cc=marcelo.leitner@gmail.com \
--cc=matttbe@kernel.org \
--cc=mbuhl@openbsd.org \
--cc=metze@samba.org \
--cc=netdev@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.