public inbox for virtio-comment@lists.linux.dev
 help / color / mirror / Atom feed
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


             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