From: Jason Wang <jasowang@redhat.com>
To: virtio-comment@lists.linux.dev, mst@redhat.com
Cc: lulu@redhat.com, nguyenlienviet@google.com,
Jason Wang <jasowang@redhat.com>
Subject: [PATCH] virtio-net: introduce TSO limit feature
Date: Tue, 14 Oct 2025 12:22:43 +0800 [thread overview]
Message-ID: <20251014042243.22087-1-jasowang@redhat.com> (raw)
This patch introduces TSO limit feature which allows the device to
advertise:
- Maximum TCP length of a TSO packet or inner TSO packet when UDP
tunnel is support
- Maximum number of segment that can be produced by the device after
segmentation of TSO or inner TSO packet of a UDP tunnel
This is a must to implement TCP jumbogram, as networking stack needs
to know the limitation of the device in order to produce TSO packet as
large as possible.
And it would also help for the case where host has a different TSO
limitation than the assumption (for example, Linux assumes 64K to be
the maximum number of segs and payload length).
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
device-types/net/description.tex | 46 ++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 415c7fd..e56df75 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -146,6 +146,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
when VIRTIO_NET_F_IPSEC is negotiated. When a device offers IPsec feature, it SHOULD
also offer the VIRTIO_NET_F_OUT_NET_HEADER feature.
+\item[VIRTIO_NET_F_HOST_TSO_LIMIT(71)] Device limits the maximum TCP
+ length and the number of segments when performing TCP segmentation.
+
\end{description}
\subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements}
@@ -184,6 +187,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
\item[VIRTIO_NET_F_VQ_NOTF_COAL] Requires VIRTIO_NET_F_CTRL_VQ.
\item[VIRTIO_NET_F_HASH_TUNNEL] Requires VIRTIO_NET_F_CTRL_VQ along with VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT.
\item[VIRTIO_NET_F_RSS_CONTEXT] Requires VIRTIO_NET_F_CTRL_VQ and VIRTIO_NET_F_RSS.
+\item[VIRTIO_NET_F_HOST_TSO_LIMIT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6
\end{description}
\begin{note}
@@ -220,6 +224,8 @@ \subsection{Device configuration layout}\label{sec:Device Types / Network Device
le16 rss_max_indirection_table_length;
le32 supported_hash_types;
le32 supported_tunnel_types;
+ le32 tso_max_size;
+ le32 tso_max_segs;
};
\end{lstlisting}
@@ -276,6 +282,19 @@ \subsection{Device configuration layout}\label{sec:Device Types / Network Device
Encapsulation types are defined in \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}.
+The following field, \field{tso_max_size} only exists if
+VIRTIO_NET_F_HOST_TSO_LIMIT is set.
+It specifies the maximum TCP length of a TSO packet that the
+device can process. When VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO is set,
+it specifies the maximum inner TCP length of a UDP tunnel TSO packet
+that the device can process.
+
+The following field, \field{tso_max_segs} only exists if
+VIRTIO_NET_F_HOST_TSO_LIMIT is set.
+It specifies the maximum number of segments that can be produced by
+the device after performing segmentation on TSO packet or a UDP tunnel
+TSO packet (when VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO is set).
+
\devicenormative{\subsubsection}{Device configuration layout}{Device Types / Network Device / Device configuration layout}
The device MUST set \field{max_virtqueue_pairs} to between 1 and 0x8000 inclusive,
@@ -326,6 +345,17 @@ \subsection{Device configuration layout}\label{sec:Device Types / Network Device
The device SHOULD NOT offer VIRTIO_NET_F_CTRL_RX_EXTRA if it
does not offer VIRTIO_NET_F_CTRL_VQ.
+If VIRTIO_NET_F_HOST_TSO_LIMIT and VIRTIO_NET_F_MTU have been
+negotiated, the device SHOULD set \field{tso_max_size} so that a TCP
+segment that fully utilizes the configured MTU can be processed by TSO
+(e.g., for IPv4 without options: at least \field{mtu} - 20; for IPv6
+without extension headers: at least \field{mtu} - 40). This
+recommendation does not account for IPv4 options or IPv6 extension
+headers, which reduce the effective segment size.
+
+If VIRTIO_NET_F_HOST_TSO_LIMIT has been negotiated, the device MUST
+set \field{tso_max_segs} to at least 64.
+
\drivernormative{\subsubsection}{Device configuration layout}{Device Types / Network Device / Device configuration layout}
The driver MUST NOT write to any of the device configuration fields.
@@ -379,6 +409,22 @@ \subsubsection{Legacy Interface: Device configuration layout}\label{sec:Device T
which provided a way for drivers to update the MAC without
negotiating VIRTIO_NET_F_CTRL_MAC_ADDR.
+If the driver negotiates VIRTIO_NET_F_HOST_TSO_LIMIT, it MUST NOT
+transmit TSO packets with TCP length exceeding \field{tso_max_size}.
+
+If the driver negotiates both VIRTIO_NET_F_HOST_TSO_LIMIT and
+VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO, it MUST NOT transmit UDP tunnel TSO
+packets with inner TCP length exceeding \field{tso_max_size}.
+
+If the driver negotiates VIRTIO_NET_F_HOST_TSO_LIMIT, it MUST NOT
+transmit TSO packets with \field{gso_size} that would cause the device
+to generate more than \field{tso_max_segs} segments.
+
+If the driver negotiates both VIRTIO_NET_F_HOST_TSO_LIMIT and
+VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO, it MUST NOT transmit UDP tunnel TSO
+packets with \field{gso_size} that would cause the device to generate
+more than \field{tso_max_segs} segments.
+
\subsection{Device Initialization}\label{sec:Device Types / Network Device / Device Initialization}
A driver would perform a typical initialization routine like so:
--
2.42.0
next reply other threads:[~2025-10-14 4:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 4:22 Jason Wang [this message]
2025-10-14 8:59 ` [PATCH] virtio-net: introduce TSO limit feature Michael S. Tsirkin
2025-10-15 4:29 ` Jason Wang
2025-10-15 7:01 ` Michael S. Tsirkin
2025-10-16 5:46 ` Jason Wang
2025-10-16 6:17 ` Michael S. Tsirkin
2025-10-16 6:19 ` Michael S. Tsirkin
2025-10-16 6:22 ` Jason Wang
2025-10-16 10:16 ` Michael S. Tsirkin
2025-10-15 7:27 ` Michael S. Tsirkin
2025-10-16 5:57 ` Jason Wang
2025-10-16 6:17 ` Michael S. Tsirkin
2025-10-16 6:31 ` Jason Wang
2025-10-16 10:02 ` Michael S. Tsirkin
2025-10-20 6:25 ` Jason Wang
2025-10-20 8:19 ` Michael S. Tsirkin
2025-10-21 3:01 ` Jason Wang
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=20251014042243.22087-1-jasowang@redhat.com \
--to=jasowang@redhat.com \
--cc=lulu@redhat.com \
--cc=mst@redhat.com \
--cc=nguyenlienviet@google.com \
--cc=virtio-comment@lists.linux.dev \
/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