* [virtio-dev] [PATCH v12] virtio-net: support device stats
@ 2022-03-15 3:24 Xuan Zhuo
2022-03-22 7:57 ` [virtio-dev] " Jason Wang
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Xuan Zhuo @ 2022-03-15 3:24 UTC (permalink / raw)
To: virtio-dev; +Cc: jasowang, Michael S. Tsirkin
This patch allows the driver to obtain some statistics from the device.
In the back-end implementation, we can count a lot of such information,
which can be used for debugging and judging the running status of the
back-end. We hope to directly display it to the user through ethtool.
To get stats atomically, try to get stats for all queue pairs in one
command.
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
---
conformance.tex | 2 +
content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 405 insertions(+), 3 deletions(-)
diff --git a/conformance.tex b/conformance.tex
index 42f8537..c67f877 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State}
\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
+\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
\end{itemize}
\conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance}
@@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
+\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
\end{itemize}
\conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance}
diff --git a/content.tex b/content.tex
index c6f116c..81f325d 100644
--- a/content.tex
+++ b/content.tex
@@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
\item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
channel.
+\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level statistics
+ to the driver through the control channel.
+
\item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO
(fragmenting the packet) the USO splits large UDP packet
to several segments when each of these smaller packets has UDP header.
@@ -3137,6 +3140,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
\item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
\item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
\item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
+\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
\item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6.
\item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
\end{description}
@@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
u8 command;
u8 command-specific-data[];
u8 ack;
+ u8 command-specific-data-reply[];
};
/* ack values */
@@ -4023,9 +4028,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
\end{lstlisting}
The \field{class}, \field{command} and command-specific-data are set by the
-driver, and the device sets the \field{ack} byte. There is little it can
-do except issue a diagnostic if \field{ack} is not
-VIRTIO_NET_OK.
+driver, and the device sets the \field{ack} byte and optionally
+\field{command-specific-data-reply}. There is little the driver can
+do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
+
+The command VIRTIO_NET_CTRL_STATS_GET contains \field{command-specific-data-reply}.
\paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
@@ -4471,6 +4478,399 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
according to the native endian of the guest rather than
(necessarily when not using the legacy interface) little-endian.
+\paragraph{Device Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
+
+If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
+get the device stats from the device in \field{command-specific-data-reply}.
+
+To get the stats, the following definitions are used:
+\begin{lstlisting}
+#define VIRTIO_NET_CTRL_STATS 6
+#define VIRTIO_NET_CTRL_STATS_GET 0
+
+#define VIRTIO_NET_STATS_TYPE_CVQ 0
+#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
+#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
+#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
+#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
+#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
+#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
+#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
+#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
+
+\end{lstlisting}
+
+Use the command VIRTIO_NET_CTRL_STATS_GET and \field{command-specific-data}
+containing struct virtio_net_ctrl_queue_stats to get the device stats.
+The result is returned by \field{command-specific-data-reply}.
+The stats ware returned in the order of the type specified in the
+\field{virtio_net_ctrl_queue_stats}.
+
+The following layout structures are used:
+
+\field{command-specific-data}
+\begin{lstlisting}
+struct virtio_net_ctrl_queue_stats {
+ u16 nstats;
+ struct {
+ u16 queue_num;
+ u16 type;
+ } stats[];
+};
+\end{lstlisting}
+
+\field{command-specific-data-reply}
+\begin{lstlisting}
+struct virtio_net_stats_cvq {
+ le64 command_num;
+ le64 ok_num;
+};
+
+struct virtio_net_stats_rx_basic {
+ le64 rx_packets;
+ le64 rx_bytes;
+
+ le64 rx_notification;
+ le64 rx_interrupt;
+
+ le64 rx_drop;
+ le64 rx_drop_overruns;
+};
+
+struct virtio_net_stats_rx_csum {
+ le64 rx_csum_valid;
+ le64 rx_needs_csum;
+ le64 rx_csum_bad;
+ le64 rx_csum_none;
+};
+
+struct virtio_net_stats_rx_gso {
+ le64 rx_gso_packets;
+ le64 rx_gso_bytes;
+ le64 rx_gso_packets_coalesced;
+ le64 rx_gso_bytes_coalesced;
+ le64 rx_gso_segments;
+ le64 rx_gso_segments_bytes;
+};
+
+struct virtio_net_stats_rx_reset {
+ le64 rx_reset;
+};
+
+struct virtio_net_stats_tx_basic {
+ le64 tx_packets;
+ le64 tx_bytes;
+
+ le64 tx_notification;
+ le64 tx_interrupt;
+
+ le64 tx_drop;
+ le64 tx_drop_malformed;
+};
+
+struct virtio_net_stats_tx_csum {
+ le64 tx_csum_none;
+ le64 tx_needs_csum;
+};
+
+struct virtio_net_stats_tx_gso {
+ le64 tx_gso_packets;
+ le64 tx_gso_bytes;
+ le64 tx_gso_packets_split;
+ le64 tx_gso_bytes_split;
+ le64 tx_gso_segments;
+ le64 tx_gso_segments_bytes;
+};
+
+struct virtio_net_stats_tx_reset {
+ le64 tx_reset;
+};
+
+\end{lstlisting}
+
+\begin{description}
+ \item [nstats]
+ The number of \field{stats}.
+
+ \item [queue_num]
+ The number of the virtqueue to obtain the statistics.
+
+ \item [type]
+ The type of the stats to be obtained.
+
+\end{description}
+
+Correspondence between the vq type, the stats type, the stats structure and the
+required features.
+\begin{tabular}{ |l|l|l|l| }
+ \hline
+ VQ Type & Stats Type & Stats Structure & Features \\ \hline
+
+ controlq & VIRTIO_NET_STATS_TYPE_CVQ & virtio_net_stats_cvq & \\ \hline
+
+ \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC & virtio_net_stats_rx_basic & \\ \cline{2-4}
+ & VIRTIO_NET_STATS_TYPE_RX_CSUM & virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
+ & VIRTIO_NET_STATS_TYPE_RX_GSO & virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
+ VIRTIO_NET_F_GUEST_TSO6 or\newline
+ VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
+ & VIRTIO_NET_STATS_TYPE_RX_RESET & virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
+
+ \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC & virtio_net_stats_tx_basic & \\ \cline{2-4}
+ & VIRTIO_NET_STATS_TYPE_TX_CSUM & virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
+ & VIRTIO_NET_STATS_TYPE_TX_GSO & virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
+ VIRTIO_NET_F_HOST_TSO6 or\newline
+ VIRTIO_NET_F_HOST_USO or\newline
+ VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
+ & VIRTIO_NET_STATS_TYPE_TX_RESET & virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
+ \hline
+\end{tabular}
+
+
+\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
+
+The structure corresponding to the controlq stats is virtio_net_stats_cvq.
+
+\begin{description}
+ \item [command_num]
+ The number of commands, including the current command.
+
+ \item [ok_num]
+ The number of commands (including the current command) where the ack was VIRTIO_NET_OK.
+\end{description}
+
+
+\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Basic Stats}
+
+The structure corresponding to the receiveq basic stats is virtio_net_stats_rx_basic.
+
+Receiveq basic stats doesn't need any features, as long as the device supports
+VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
+
+\begin{description}
+ \item [rx_packets]
+ The number of packets received by device (not the packets passed to the
+ guest), including the dropped packets by device.
+
+ \item [rx_bytes]
+ The number of bytes received by device (not the packets passed to the
+ guest), including the dropped packets by device.
+
+ \item [rx_notification]
+ The number of driver notifications.
+
+ \item [rx_interrupt]
+ The number of device interrupts.
+
+ \item [rx_drop]
+ The number of packets dropped by the receiveq. Contains all kinds of
+ packet drop.
+
+ \item [rx_drop_overruns]
+ The number of packets dropped by the receiveq when no more descriptors
+ were available.
+
+\end{description}
+
+\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Basic Stats}
+
+The structure corresponding to the transmitq basic stats is virtio_net_stats_tx_basic.
+
+Transmitq basic stats doesn't need any features, as long as the device supports
+VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
+
+\begin{description}
+ \item [tx_packets]
+ The number of packets sent by device (not the packets got from the
+ guest), excluding the dropped packets by device.
+
+ \item [tx_bytes]
+ The number of bytes sent by device (not the packets got from the
+ guest), excluding the dropped packets by device.
+
+ \item [tx_notification]
+ The number of driver notifications.
+
+ \item [tx_interrupt]
+ The number of device interrupts.
+
+ \item [tx_drop]
+ The number of packets dropped by the transmitq. Contains all kinds of
+ packet drop.
+
+ \item [tx_drop_malformed]
+ The number of packets dropped when the descriptor is in an error state.
+ For example, the buffer is too short.
+
+\end{description}
+
+\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq CSUM Stats}
+
+The structure corresponding to the receiveq csum stats is virtio_net_stats_rx_csum.
+
+Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the receiveq
+csum stats can be obtained.
+
+The following are the receiveq csum stats:
+
+\begin{description}
+ \item [rx_csum_valid]
+ The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
+
+ \item [rx_needs_csum]
+ The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
+
+ \item [rx_csum_bad]
+ The number of packets with abnormal csum.
+
+ \item [rx_csum_none]
+ The number of packets without hardware csum. The packet here refers to
+ the non-TCP/UDP packet that the backend cannot recognize.
+
+\end{description}
+
+\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq CSUM Stats}
+
+The structure corresponding to the transmitq csum stats is virtio_net_stats_tx_csum.
+
+Only after the VIRTIO_NET_F_CSUM negotiation is successful, the transmitq csum
+stats can be obtained.
+
+The following are the transmitq csum stats:
+
+\begin{description}
+ \item [tx_csum_none]
+ The number of packets that didn't require hardware csum.
+
+ \item [tx_needs_csum]
+ The number of packets that required hardware csum.
+
+\end{description}
+
+\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO Stats}
+
+The structure corresponding to the receiveq gso stats is virtio_net_stats_rx_gso.
+
+If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
+been negotiated, the receiveq gso stats can be obtained.
+
+Rx gso packets refer to packets passed by the device to the driver where
+\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
+
+\begin{description}
+ \item [rx_gso_packets]
+ The number of the rx gso packets.
+
+ \item [rx_gso_bytes]
+ The number of bytes(excluding the virtio net header) of the rx gso packets.
+
+ \item [rx_gso_packets_coalesced]
+ The number of the rx gso packages generated by coalescing.
+
+ \item [rx_gso_bytes_coalesced]
+ The number of bytes(excluding the virtio net header) of the rx gso packets generated by coalescing.
+
+ \item [rx_gso_segments]
+ The number of coalesced segments.
+
+ \item [rx_gso_segments_bytes]
+ The number of bytes of coalesced segments.
+
+\end{description}
+
+\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq GSO Stats}
+
+The structure corresponding to the transmitq gso stats is virtio_net_stats_tx_gso.
+
+If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
+been negotiated, the transmitq gso stats can be obtained.
+
+Tx gso packets refer to packets passed by the driver to the device where
+\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
+
+\begin{description}
+ \item [tx_gso_packets]
+ The number of the tx gso packets.
+
+ \item [tx_gso_bytes]
+ The number of bytes(excluding the virtio net header) of the tx gso packets.
+
+ \item [tx_gso_packets_split]
+ The number of the tx gso packets that been split.
+
+ \item [tx_gso_bytes_split]
+ The number of bytes(excluding the virtio net header) of the tx gso packets that been split.
+
+ \item [tx_gso_segments]
+ The number of segments split from the gso package.
+
+ \item [tx_gso_segments_bytes]
+ The number of bytes(excluding the virtio net header) of segments split from the gso package.
+\end{description}
+
+\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Reset Stats}
+
+The structure corresponding to the receiveq reset stats is virtio_net_stats_rx_reset.
+
+Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq reset stats
+can be obtained.
+
+See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
+for more about \field{rx_reset}.
+
+\begin{description}
+ \item [rx_reset]
+ The number of receiveq resets.
+\end{description}
+
+\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Reset Stats}
+
+The structure corresponding to the transmitq reset stats is virtio_net_stats_tx_reset.
+
+Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq reset stats
+can be obtained.
+
+See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
+for more about \field{tx_reset}.
+
+\begin{description}
+ \item [tx_reset]
+ The number of transmitq resets.
+\end{description}
+
+\devicenormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
+
+If virtio_net_ctrl_queue_stats is incorrect (such as the following), the device
+MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
+the device MUST abort the entire command.
+\begin{itemize}
+ \item \field{queue_num} exceeds the queue range.
+ \item \field{type} is not a known value.
+ \item The type of vq does not match \field{type}. E.g. the driver tries to query
+ RX stats through a TX index.
+ \item The feature corresponding to the specified \field{type} was not successfully
+ negotiated.
+ \item The size of the buffer allocated by the driver for \field{command-specific-data-reply}
+ is less than the total size of the stats specialed by
+ \field{virtio_net_ctrl_queue_stats}.
+\end{itemize}
+
+The device MUST write the requested stats structures in
+\field{command-specific-data-reply} in the order specified by the structure
+virtio_net_ctrl_queue_stats.
+
+\drivernormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
+
+When a driver tries to obtain a certain stats, it MUST confirm that the relevant
+feature negotiation is successful.
+
+\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to the vq
+specified by \field{queue_num}.
+
+The \field{command-specific-data-reply} buffer allocated by the driver MUST be
+able to hold all the stats specified by virtio_net_ctrl_queue_stats.
+
+When the driver reads the response, it MUST read
+\field{command-specific-data-reply} one by one based on the \field{type}.
\subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
Types / Network Device / Legacy Interface: Framing Requirements}
--
2.31.0
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
2022-03-15 3:24 [virtio-dev] [PATCH v12] virtio-net: support device stats Xuan Zhuo
@ 2022-03-22 7:57 ` Jason Wang
2023-07-10 7:28 ` [virtio-comment] " Xuan Zhuo
2023-07-12 11:34 ` [virtio-dev] " Michael S. Tsirkin
2 siblings, 0 replies; 21+ messages in thread
From: Jason Wang @ 2022-03-22 7:57 UTC (permalink / raw)
To: Xuan Zhuo, virtio-dev; +Cc: Michael S. Tsirkin
在 2022/3/15 上午11:24, Xuan Zhuo 写道:
> This patch allows the driver to obtain some statistics from the device.
>
> In the back-end implementation, we can count a lot of such information,
> which can be used for debugging and judging the running status of the
> back-end. We hope to directly display it to the user through ethtool.
>
> To get stats atomically, try to get stats for all queue pairs in one
> command.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> conformance.tex | 2 +
> content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 405 insertions(+), 3 deletions(-)
>
> diff --git a/conformance.tex b/conformance.tex
> index 42f8537..c67f877 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
> +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance}
> @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance}
> diff --git a/content.tex b/content.tex
> index c6f116c..81f325d 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> channel.
>
> +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level statistics
> + to the driver through the control channel.
> +
> \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO
> (fragmenting the packet) the USO splits large UDP packet
> to several segments when each of these smaller packets has UDP header.
> @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
> \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6.
> \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> \end{description}
> @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> u8 command;
> u8 command-specific-data[];
> u8 ack;
> + u8 command-specific-data-reply[];
> };
>
> /* ack values */
> @@ -4023,9 +4028,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \end{lstlisting}
>
> The \field{class}, \field{command} and command-specific-data are set by the
> -driver, and the device sets the \field{ack} byte. There is little it can
> -do except issue a diagnostic if \field{ack} is not
> -VIRTIO_NET_OK.
> +driver, and the device sets the \field{ack} byte and optionally
> +\field{command-specific-data-reply}. There is little the driver can
> +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> +
> +The command VIRTIO_NET_CTRL_STATS_GET contains \field{command-specific-data-reply}.
>
> \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> \label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> @@ -4471,6 +4478,399 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> according to the native endian of the guest rather than
> (necessarily when not using the legacy interface) little-endian.
>
> +\paragraph{Device Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> +get the device stats from the device in \field{command-specific-data-reply}.
> +
> +To get the stats, the following definitions are used:
> +\begin{lstlisting}
> +#define VIRTIO_NET_CTRL_STATS 6
> +#define VIRTIO_NET_CTRL_STATS_GET 0
> +
> +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> +
> +\end{lstlisting}
> +
> +Use the command VIRTIO_NET_CTRL_STATS_GET and \field{command-specific-data}
> +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> +The result is returned by \field{command-specific-data-reply}.
> +The stats ware returned in the order of the type specified in the
s/ware/were/ and s/type/types/ ?
> +\field{virtio_net_ctrl_queue_stats}.
> +
> +The following layout structures are used:
> +
> +\field{command-specific-data}
> +\begin{lstlisting}
> +struct virtio_net_ctrl_queue_stats {
> + u16 nstats;
> + struct {
> + u16 queue_num;
> + u16 type;
> + } stats[];
> +};
> +\end{lstlisting}
> +
> +\field{command-specific-data-reply}
> +\begin{lstlisting}
> +struct virtio_net_stats_cvq {
> + le64 command_num;
> + le64 ok_num;
> +};
> +
> +struct virtio_net_stats_rx_basic {
> + le64 rx_packets;
> + le64 rx_bytes;
> +
> + le64 rx_notification;
> + le64 rx_interrupt;
> +
> + le64 rx_drop;
> + le64 rx_drop_overruns;
> +};
> +
> +struct virtio_net_stats_rx_csum {
> + le64 rx_csum_valid;
> + le64 rx_needs_csum;
> + le64 rx_csum_bad;
> + le64 rx_csum_none;
> +};
> +
> +struct virtio_net_stats_rx_gso {
> + le64 rx_gso_packets;
> + le64 rx_gso_bytes;
> + le64 rx_gso_packets_coalesced;
> + le64 rx_gso_bytes_coalesced;
> + le64 rx_gso_segments;
> + le64 rx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_rx_reset {
> + le64 rx_reset;
> +};
> +
> +struct virtio_net_stats_tx_basic {
> + le64 tx_packets;
> + le64 tx_bytes;
> +
> + le64 tx_notification;
> + le64 tx_interrupt;
> +
> + le64 tx_drop;
> + le64 tx_drop_malformed;
> +};
> +
> +struct virtio_net_stats_tx_csum {
> + le64 tx_csum_none;
> + le64 tx_needs_csum;
> +};
> +
> +struct virtio_net_stats_tx_gso {
> + le64 tx_gso_packets;
> + le64 tx_gso_bytes;
> + le64 tx_gso_packets_split;
> + le64 tx_gso_bytes_split;
> + le64 tx_gso_segments;
> + le64 tx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_tx_reset {
> + le64 tx_reset;
> +};
> +
> +\end{lstlisting}
> +
> +\begin{description}
> + \item [nstats]
> + The number of \field{stats}.
This looks not necessary since it can be deduced from the buffer length.
> +
> + \item [queue_num]
> + The number of the virtqueue to obtain the statistics.
> +
> + \item [type]
> + The type of the stats to be obtained.
> +
> +\end{description}
> +
> +Correspondence between the vq type, the stats type, the stats structure and the
> +required features.
> +\begin{tabular}{ |l|l|l|l| }
> + \hline
> + VQ Type & Stats Type & Stats Structure & Features \\ \hline
> +
> + controlq & VIRTIO_NET_STATS_TYPE_CVQ & virtio_net_stats_cvq & \\ \hline
> +
> + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC & virtio_net_stats_rx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_CSUM & virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_GSO & virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> + VIRTIO_NET_F_GUEST_TSO6 or\newline
> + VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_RESET & virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> +
> + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC & virtio_net_stats_tx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_CSUM & virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_GSO & virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> + VIRTIO_NET_F_HOST_TSO6 or\newline
> + VIRTIO_NET_F_HOST_USO or\newline
> + VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_RESET & virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> + \hline
> +\end{tabular}
> +
> +
> +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> +
> +The structure corresponding to the controlq stats is virtio_net_stats_cvq.
> +
> +\begin{description}
> + \item [command_num]
> + The number of commands, including the current command.
> +
> + \item [ok_num]
> + The number of commands (including the current command) where the ack was VIRTIO_NET_OK.
> +\end{description}
> +
> +
> +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Basic Stats}
> +
> +The structure corresponding to the receiveq basic stats is virtio_net_stats_rx_basic.
> +
> +Receiveq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> +
> +\begin{description}
> + \item [rx_packets]
> + The number of packets received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_bytes]
> + The number of bytes received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_notification]
> + The number of driver notifications.
> +
> + \item [rx_interrupt]
> + The number of device interrupts.
> +
> + \item [rx_drop]
> + The number of packets dropped by the receiveq. Contains all kinds of
> + packet drop.
> +
> + \item [rx_drop_overruns]
> + The number of packets dropped by the receiveq when no more descriptors
> + were available.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Basic Stats}
> +
> +The structure corresponding to the transmitq basic stats is virtio_net_stats_tx_basic.
> +
> +Transmitq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> +
> +\begin{description}
> + \item [tx_packets]
> + The number of packets sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
"packets dropped by device"?
> +
> + \item [tx_bytes]
> + The number of bytes sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
> +
> + \item [tx_notification]
> + The number of driver notifications.
> +
> + \item [tx_interrupt]
> + The number of device interrupts.
> +
> + \item [tx_drop]
> + The number of packets dropped by the transmitq. Contains all kinds of
> + packet drop.
> +
> + \item [tx_drop_malformed]
> + The number of packets dropped when the descriptor is in an error state.
> + For example, the buffer is too short.
I wonder if "tx_erros" is better (this is what I see from at least two
other NIC vendors).
> +
> +\end{description}
> +
> +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq CSUM Stats}
> +
> +The structure corresponding to the receiveq csum stats is virtio_net_stats_rx_csum.
> +
> +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the receiveq
> +csum stats can be obtained.
> +
> +The following are the receiveq csum stats:
> +
> +\begin{description}
> + \item [rx_csum_valid]
> + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
A question, it looks to me the stats refer to the phy -> device counters
not the device -> driver counter (which could be count by the driver).
If this is true, technically, device can't receive a packet with
VIRTIO_NET_HDR_F_DATA_VALID.
FYI, e1000e had:
ethtool -S enp0s31f6 | grep csum
rx_csum_offload_good: 601959
rx_csum_offload_errors: 0
> +
> + \item [rx_needs_csum]
> + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> +
> + \item [rx_csum_bad]
> + The number of packets with abnormal csum.
> +
> + \item [rx_csum_none]
> + The number of packets without hardware csum. The packet here refers to
> + the non-TCP/UDP packet that the backend cannot recognize.
This is probably not correct. We may have a guest without
VIRTIO_NET_F_GUEST_CSUM support.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq CSUM Stats}
> +
> +The structure corresponding to the transmitq csum stats is virtio_net_stats_tx_csum.
> +
> +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the transmitq csum
> +stats can be obtained.
> +
> +The following are the transmitq csum stats:
> +
> +\begin{description}
> + \item [tx_csum_none]
> + The number of packets that didn't require hardware csum.
> +
> + \item [tx_needs_csum]
> + The number of packets that required hardware csum.
> +
> +\end{description}
> +
> +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO Stats}
> +
> +The structure corresponding to the receiveq gso stats is virtio_net_stats_rx_gso.
> +
> +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> +been negotiated, the receiveq gso stats can be obtained.
We probably need to use "GSO" instead of "gso" for the whole patch.
> +
> +Rx gso packets refer to packets passed by the device to the driver where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [rx_gso_packets]
> + The number of the rx gso packets.
> +
> + \item [rx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the rx gso packets.
> +
> + \item [rx_gso_packets_coalesced]
> + The number of the rx gso packages generated by coalescing.
For "packages", did you mean "packets" actually? Does it work only if
RSC is negotiated?
> +
> + \item [rx_gso_bytes_coalesced]
> + The number of bytes(excluding the virtio net header) of the rx gso packets generated by coalescing.
> +
> + \item [rx_gso_segments]
> + The number of coalesced segments.
If we do VM2VM traffic, we can receive GSO packets directly without
coalescing. Do we count this packet here?
> +
> + \item [rx_gso_segments_bytes]
> + The number of bytes of coalesced segments.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq GSO Stats}
> +
> +The structure corresponding to the transmitq gso stats is virtio_net_stats_tx_gso.
> +
> +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> +been negotiated, the transmitq gso stats can be obtained.
> +
> +Tx gso packets refer to packets passed by the driver to the device where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [tx_gso_packets]
> + The number of the tx gso packets.
> +
> + \item [tx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the tx gso packets.
> +
> + \item [tx_gso_packets_split]
> + The number of the tx gso packets that been split.
> +
> + \item [tx_gso_bytes_split]
> + The number of bytes(excluding the virtio net header) of the tx gso packets that been split.
S/packet/bytes/? And does it include the L2/L3/L4 headers of the
segmented packets?
> +
> + \item [tx_gso_segments]
> + The number of segments split from the gso package.
For package, I think you meant packet actually.
> +
> + \item [tx_gso_segments_bytes]
> + The number of bytes(excluding the virtio net header) of segments split from the gso package.
> +\end{description}
> +
> +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Reset Stats}
> +
> +The structure corresponding to the receiveq reset stats is virtio_net_stats_rx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq reset stats
> +can be obtained.
Not a native speaker, but I think we can remove "successfully" here.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{rx_reset}.
> +
> +\begin{description}
> + \item [rx_reset]
> + The number of receiveq resets.
> +\end{description}
> +
> +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Reset Stats}
> +
> +The structure corresponding to the transmitq reset stats is virtio_net_stats_tx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq reset stats
> +can be obtained.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{tx_reset}.
> +
> +\begin{description}
> + \item [tx_reset]
> + The number of transmitq resets.
> +\end{description}
> +
> +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If virtio_net_ctrl_queue_stats is incorrect (such as the following), the device
> +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> +the device MUST abort the entire command.
I guess "fail" is better than "abort".
> +\begin{itemize}
> + \item \field{queue_num} exceeds the queue range.
> + \item \field{type} is not a known value.
> + \item The type of vq does not match \field{type}. E.g. the driver tries to query
> + RX stats through a TX index.
> + \item The feature corresponding to the specified \field{type} was not successfully
> + negotiated.
> + \item The size of the buffer allocated by the driver for \field{command-specific-data-reply}
> + is less than the total size of the stats specialed by
> + \field{virtio_net_ctrl_queue_stats}.
> +\end{itemize}
> +
> +The device MUST write the requested stats structures in
> +\field{command-specific-data-reply} in the order specified by the structure
> +virtio_net_ctrl_queue_stats.
Are the counters reset during device reset?
Thanks
> +
> +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +When a driver tries to obtain a certain stats, it MUST confirm that the relevant
> +feature negotiation is successful.
> +
> +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to the vq
> +specified by \field{queue_num}.
> +
> +The \field{command-specific-data-reply} buffer allocated by the driver MUST be
> +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> +
> +When the driver reads the response, it MUST read
> +\field{command-specific-data-reply} one by one based on the \field{type}.
>
> \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> Types / Network Device / Legacy Interface: Framing Requirements}
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
2022-03-15 3:24 [virtio-dev] [PATCH v12] virtio-net: support device stats Xuan Zhuo
@ 2023-07-10 7:28 ` Xuan Zhuo
2023-07-10 7:28 ` [virtio-comment] " Xuan Zhuo
2023-07-12 11:34 ` [virtio-dev] " Michael S. Tsirkin
2 siblings, 0 replies; 21+ messages in thread
From: Xuan Zhuo @ 2023-07-10 7:28 UTC (permalink / raw)
To: Xuan Zhuo
Cc: jasowang, Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
hi, guys
After a lot of internal discussions, I removed some unimportant counters. Based
on this v12 patch I am repling to, most of the requirements have been met.
The patch link https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
We still have these counters, let's see if they can be standardized.
## limit
* tx_bps_limit_drops
* tx_pps_limit_drops
* rx_bps_limit_drops
* rx_pps_limit_drops
In a cloud scenario, multiple users purchase different VMs, and these VMs share
the capabilities of the same host. In order to ensure that each VM will not
affect others, the network card(virtio-net) capability of each VM is limited.
These users purchase VMs, this limit has already been determined.
So if the network card traffic of a vm exceeds the upper limit, packet loss will
occur. It is necessary for us to count these packet losses. And the device
should expose to the user.
## session
* tx_session_full_drops The number of packet drops in the sending direction when
the session is full
* rx_session_full_drops The number of packets lost when the session is full in the receiving direction
Our dpu supports tcp connection tracking, but there is an upper limit to the
number of connections, and if it exceeds, packet loss will also occur.
## ACL
* tx_acl_drops ACL packet loss in the sending direction
* rx_acl_drops The number of ACL packets lost in the receiving direction
In our cloud service, for network cards, users are allowed to configure security
rules,such as which IPs can access which ports of this machine.
Thanks
On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> This patch allows the driver to obtain some statistics from the device.
>
> In the back-end implementation, we can count a lot of such information,
> which can be used for debugging and judging the running status of the
> back-end. We hope to directly display it to the user through ethtool.
>
> To get stats atomically, try to get stats for all queue pairs in one
> command.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> conformance.tex | 2 +
> content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 405 insertions(+), 3 deletions(-)
>
> diff --git a/conformance.tex b/conformance.tex
> index 42f8537..c67f877 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
> +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance}
> @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance}
> diff --git a/content.tex b/content.tex
> index c6f116c..81f325d 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> channel.
>
> +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level statistics
> + to the driver through the control channel.
> +
> \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO
> (fragmenting the packet) the USO splits large UDP packet
> to several segments when each of these smaller packets has UDP header.
> @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
> \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6.
> \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> \end{description}
> @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> u8 command;
> u8 command-specific-data[];
> u8 ack;
> + u8 command-specific-data-reply[];
> };
>
> /* ack values */
> @@ -4023,9 +4028,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \end{lstlisting}
>
> The \field{class}, \field{command} and command-specific-data are set by the
> -driver, and the device sets the \field{ack} byte. There is little it can
> -do except issue a diagnostic if \field{ack} is not
> -VIRTIO_NET_OK.
> +driver, and the device sets the \field{ack} byte and optionally
> +\field{command-specific-data-reply}. There is little the driver can
> +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> +
> +The command VIRTIO_NET_CTRL_STATS_GET contains \field{command-specific-data-reply}.
>
> \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> \label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> @@ -4471,6 +4478,399 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> according to the native endian of the guest rather than
> (necessarily when not using the legacy interface) little-endian.
>
> +\paragraph{Device Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> +get the device stats from the device in \field{command-specific-data-reply}.
> +
> +To get the stats, the following definitions are used:
> +\begin{lstlisting}
> +#define VIRTIO_NET_CTRL_STATS 6
> +#define VIRTIO_NET_CTRL_STATS_GET 0
> +
> +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> +
> +\end{lstlisting}
> +
> +Use the command VIRTIO_NET_CTRL_STATS_GET and \field{command-specific-data}
> +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> +The result is returned by \field{command-specific-data-reply}.
> +The stats ware returned in the order of the type specified in the
> +\field{virtio_net_ctrl_queue_stats}.
> +
> +The following layout structures are used:
> +
> +\field{command-specific-data}
> +\begin{lstlisting}
> +struct virtio_net_ctrl_queue_stats {
> + u16 nstats;
> + struct {
> + u16 queue_num;
> + u16 type;
> + } stats[];
> +};
> +\end{lstlisting}
> +
> +\field{command-specific-data-reply}
> +\begin{lstlisting}
> +struct virtio_net_stats_cvq {
> + le64 command_num;
> + le64 ok_num;
> +};
> +
> +struct virtio_net_stats_rx_basic {
> + le64 rx_packets;
> + le64 rx_bytes;
> +
> + le64 rx_notification;
> + le64 rx_interrupt;
> +
> + le64 rx_drop;
> + le64 rx_drop_overruns;
> +};
> +
> +struct virtio_net_stats_rx_csum {
> + le64 rx_csum_valid;
> + le64 rx_needs_csum;
> + le64 rx_csum_bad;
> + le64 rx_csum_none;
> +};
> +
> +struct virtio_net_stats_rx_gso {
> + le64 rx_gso_packets;
> + le64 rx_gso_bytes;
> + le64 rx_gso_packets_coalesced;
> + le64 rx_gso_bytes_coalesced;
> + le64 rx_gso_segments;
> + le64 rx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_rx_reset {
> + le64 rx_reset;
> +};
> +
> +struct virtio_net_stats_tx_basic {
> + le64 tx_packets;
> + le64 tx_bytes;
> +
> + le64 tx_notification;
> + le64 tx_interrupt;
> +
> + le64 tx_drop;
> + le64 tx_drop_malformed;
> +};
> +
> +struct virtio_net_stats_tx_csum {
> + le64 tx_csum_none;
> + le64 tx_needs_csum;
> +};
> +
> +struct virtio_net_stats_tx_gso {
> + le64 tx_gso_packets;
> + le64 tx_gso_bytes;
> + le64 tx_gso_packets_split;
> + le64 tx_gso_bytes_split;
> + le64 tx_gso_segments;
> + le64 tx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_tx_reset {
> + le64 tx_reset;
> +};
> +
> +\end{lstlisting}
> +
> +\begin{description}
> + \item [nstats]
> + The number of \field{stats}.
> +
> + \item [queue_num]
> + The number of the virtqueue to obtain the statistics.
> +
> + \item [type]
> + The type of the stats to be obtained.
> +
> +\end{description}
> +
> +Correspondence between the vq type, the stats type, the stats structure and the
> +required features.
> +\begin{tabular}{ |l|l|l|l| }
> + \hline
> + VQ Type & Stats Type & Stats Structure & Features \\ \hline
> +
> + controlq & VIRTIO_NET_STATS_TYPE_CVQ & virtio_net_stats_cvq & \\ \hline
> +
> + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC & virtio_net_stats_rx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_CSUM & virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_GSO & virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> + VIRTIO_NET_F_GUEST_TSO6 or\newline
> + VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_RESET & virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> +
> + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC & virtio_net_stats_tx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_CSUM & virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_GSO & virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> + VIRTIO_NET_F_HOST_TSO6 or\newline
> + VIRTIO_NET_F_HOST_USO or\newline
> + VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_RESET & virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> + \hline
> +\end{tabular}
> +
> +
> +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> +
> +The structure corresponding to the controlq stats is virtio_net_stats_cvq.
> +
> +\begin{description}
> + \item [command_num]
> + The number of commands, including the current command.
> +
> + \item [ok_num]
> + The number of commands (including the current command) where the ack was VIRTIO_NET_OK.
> +\end{description}
> +
> +
> +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Basic Stats}
> +
> +The structure corresponding to the receiveq basic stats is virtio_net_stats_rx_basic.
> +
> +Receiveq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> +
> +\begin{description}
> + \item [rx_packets]
> + The number of packets received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_bytes]
> + The number of bytes received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_notification]
> + The number of driver notifications.
> +
> + \item [rx_interrupt]
> + The number of device interrupts.
> +
> + \item [rx_drop]
> + The number of packets dropped by the receiveq. Contains all kinds of
> + packet drop.
> +
> + \item [rx_drop_overruns]
> + The number of packets dropped by the receiveq when no more descriptors
> + were available.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Basic Stats}
> +
> +The structure corresponding to the transmitq basic stats is virtio_net_stats_tx_basic.
> +
> +Transmitq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> +
> +\begin{description}
> + \item [tx_packets]
> + The number of packets sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
> +
> + \item [tx_bytes]
> + The number of bytes sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
> +
> + \item [tx_notification]
> + The number of driver notifications.
> +
> + \item [tx_interrupt]
> + The number of device interrupts.
> +
> + \item [tx_drop]
> + The number of packets dropped by the transmitq. Contains all kinds of
> + packet drop.
> +
> + \item [tx_drop_malformed]
> + The number of packets dropped when the descriptor is in an error state.
> + For example, the buffer is too short.
> +
> +\end{description}
> +
> +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq CSUM Stats}
> +
> +The structure corresponding to the receiveq csum stats is virtio_net_stats_rx_csum.
> +
> +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the receiveq
> +csum stats can be obtained.
> +
> +The following are the receiveq csum stats:
> +
> +\begin{description}
> + \item [rx_csum_valid]
> + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> +
> + \item [rx_needs_csum]
> + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> +
> + \item [rx_csum_bad]
> + The number of packets with abnormal csum.
> +
> + \item [rx_csum_none]
> + The number of packets without hardware csum. The packet here refers to
> + the non-TCP/UDP packet that the backend cannot recognize.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq CSUM Stats}
> +
> +The structure corresponding to the transmitq csum stats is virtio_net_stats_tx_csum.
> +
> +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the transmitq csum
> +stats can be obtained.
> +
> +The following are the transmitq csum stats:
> +
> +\begin{description}
> + \item [tx_csum_none]
> + The number of packets that didn't require hardware csum.
> +
> + \item [tx_needs_csum]
> + The number of packets that required hardware csum.
> +
> +\end{description}
> +
> +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO Stats}
> +
> +The structure corresponding to the receiveq gso stats is virtio_net_stats_rx_gso.
> +
> +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> +been negotiated, the receiveq gso stats can be obtained.
> +
> +Rx gso packets refer to packets passed by the device to the driver where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [rx_gso_packets]
> + The number of the rx gso packets.
> +
> + \item [rx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the rx gso packets.
> +
> + \item [rx_gso_packets_coalesced]
> + The number of the rx gso packages generated by coalescing.
> +
> + \item [rx_gso_bytes_coalesced]
> + The number of bytes(excluding the virtio net header) of the rx gso packets generated by coalescing.
> +
> + \item [rx_gso_segments]
> + The number of coalesced segments.
> +
> + \item [rx_gso_segments_bytes]
> + The number of bytes of coalesced segments.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq GSO Stats}
> +
> +The structure corresponding to the transmitq gso stats is virtio_net_stats_tx_gso.
> +
> +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> +been negotiated, the transmitq gso stats can be obtained.
> +
> +Tx gso packets refer to packets passed by the driver to the device where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [tx_gso_packets]
> + The number of the tx gso packets.
> +
> + \item [tx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the tx gso packets.
> +
> + \item [tx_gso_packets_split]
> + The number of the tx gso packets that been split.
> +
> + \item [tx_gso_bytes_split]
> + The number of bytes(excluding the virtio net header) of the tx gso packets that been split.
> +
> + \item [tx_gso_segments]
> + The number of segments split from the gso package.
> +
> + \item [tx_gso_segments_bytes]
> + The number of bytes(excluding the virtio net header) of segments split from the gso package.
> +\end{description}
> +
> +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Reset Stats}
> +
> +The structure corresponding to the receiveq reset stats is virtio_net_stats_rx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq reset stats
> +can be obtained.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{rx_reset}.
> +
> +\begin{description}
> + \item [rx_reset]
> + The number of receiveq resets.
> +\end{description}
> +
> +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Reset Stats}
> +
> +The structure corresponding to the transmitq reset stats is virtio_net_stats_tx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq reset stats
> +can be obtained.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{tx_reset}.
> +
> +\begin{description}
> + \item [tx_reset]
> + The number of transmitq resets.
> +\end{description}
> +
> +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If virtio_net_ctrl_queue_stats is incorrect (such as the following), the device
> +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> +the device MUST abort the entire command.
> +\begin{itemize}
> + \item \field{queue_num} exceeds the queue range.
> + \item \field{type} is not a known value.
> + \item The type of vq does not match \field{type}. E.g. the driver tries to query
> + RX stats through a TX index.
> + \item The feature corresponding to the specified \field{type} was not successfully
> + negotiated.
> + \item The size of the buffer allocated by the driver for \field{command-specific-data-reply}
> + is less than the total size of the stats specialed by
> + \field{virtio_net_ctrl_queue_stats}.
> +\end{itemize}
> +
> +The device MUST write the requested stats structures in
> +\field{command-specific-data-reply} in the order specified by the structure
> +virtio_net_ctrl_queue_stats.
> +
> +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +When a driver tries to obtain a certain stats, it MUST confirm that the relevant
> +feature negotiation is successful.
> +
> +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to the vq
> +specified by \field{queue_num}.
> +
> +The \field{command-specific-data-reply} buffer allocated by the driver MUST be
> +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> +
> +When the driver reads the response, it MUST read
> +\field{command-specific-data-reply} one by one based on the \field{type}.
>
> \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> Types / Network Device / Legacy Interface: Framing Requirements}
> --
> 2.31.0
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-comment] Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
@ 2023-07-10 7:28 ` Xuan Zhuo
0 siblings, 0 replies; 21+ messages in thread
From: Xuan Zhuo @ 2023-07-10 7:28 UTC (permalink / raw)
To: Xuan Zhuo
Cc: jasowang, Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
hi, guys
After a lot of internal discussions, I removed some unimportant counters. Based
on this v12 patch I am repling to, most of the requirements have been met.
The patch link https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
We still have these counters, let's see if they can be standardized.
## limit
* tx_bps_limit_drops
* tx_pps_limit_drops
* rx_bps_limit_drops
* rx_pps_limit_drops
In a cloud scenario, multiple users purchase different VMs, and these VMs share
the capabilities of the same host. In order to ensure that each VM will not
affect others, the network card(virtio-net) capability of each VM is limited.
These users purchase VMs, this limit has already been determined.
So if the network card traffic of a vm exceeds the upper limit, packet loss will
occur. It is necessary for us to count these packet losses. And the device
should expose to the user.
## session
* tx_session_full_drops The number of packet drops in the sending direction when
the session is full
* rx_session_full_drops The number of packets lost when the session is full in the receiving direction
Our dpu supports tcp connection tracking, but there is an upper limit to the
number of connections, and if it exceeds, packet loss will also occur.
## ACL
* tx_acl_drops ACL packet loss in the sending direction
* rx_acl_drops The number of ACL packets lost in the receiving direction
In our cloud service, for network cards, users are allowed to configure security
rules,such as which IPs can access which ports of this machine.
Thanks
On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> This patch allows the driver to obtain some statistics from the device.
>
> In the back-end implementation, we can count a lot of such information,
> which can be used for debugging and judging the running status of the
> back-end. We hope to directly display it to the user through ethtool.
>
> To get stats atomically, try to get stats for all queue pairs in one
> command.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> conformance.tex | 2 +
> content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 405 insertions(+), 3 deletions(-)
>
> diff --git a/conformance.tex b/conformance.tex
> index 42f8537..c67f877 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
> +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance}
> @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance}
> diff --git a/content.tex b/content.tex
> index c6f116c..81f325d 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> channel.
>
> +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level statistics
> + to the driver through the control channel.
> +
> \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO
> (fragmenting the packet) the USO splits large UDP packet
> to several segments when each of these smaller packets has UDP header.
> @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
> \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6.
> \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> \end{description}
> @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> u8 command;
> u8 command-specific-data[];
> u8 ack;
> + u8 command-specific-data-reply[];
> };
>
> /* ack values */
> @@ -4023,9 +4028,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \end{lstlisting}
>
> The \field{class}, \field{command} and command-specific-data are set by the
> -driver, and the device sets the \field{ack} byte. There is little it can
> -do except issue a diagnostic if \field{ack} is not
> -VIRTIO_NET_OK.
> +driver, and the device sets the \field{ack} byte and optionally
> +\field{command-specific-data-reply}. There is little the driver can
> +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> +
> +The command VIRTIO_NET_CTRL_STATS_GET contains \field{command-specific-data-reply}.
>
> \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> \label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> @@ -4471,6 +4478,399 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> according to the native endian of the guest rather than
> (necessarily when not using the legacy interface) little-endian.
>
> +\paragraph{Device Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> +get the device stats from the device in \field{command-specific-data-reply}.
> +
> +To get the stats, the following definitions are used:
> +\begin{lstlisting}
> +#define VIRTIO_NET_CTRL_STATS 6
> +#define VIRTIO_NET_CTRL_STATS_GET 0
> +
> +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> +
> +\end{lstlisting}
> +
> +Use the command VIRTIO_NET_CTRL_STATS_GET and \field{command-specific-data}
> +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> +The result is returned by \field{command-specific-data-reply}.
> +The stats ware returned in the order of the type specified in the
> +\field{virtio_net_ctrl_queue_stats}.
> +
> +The following layout structures are used:
> +
> +\field{command-specific-data}
> +\begin{lstlisting}
> +struct virtio_net_ctrl_queue_stats {
> + u16 nstats;
> + struct {
> + u16 queue_num;
> + u16 type;
> + } stats[];
> +};
> +\end{lstlisting}
> +
> +\field{command-specific-data-reply}
> +\begin{lstlisting}
> +struct virtio_net_stats_cvq {
> + le64 command_num;
> + le64 ok_num;
> +};
> +
> +struct virtio_net_stats_rx_basic {
> + le64 rx_packets;
> + le64 rx_bytes;
> +
> + le64 rx_notification;
> + le64 rx_interrupt;
> +
> + le64 rx_drop;
> + le64 rx_drop_overruns;
> +};
> +
> +struct virtio_net_stats_rx_csum {
> + le64 rx_csum_valid;
> + le64 rx_needs_csum;
> + le64 rx_csum_bad;
> + le64 rx_csum_none;
> +};
> +
> +struct virtio_net_stats_rx_gso {
> + le64 rx_gso_packets;
> + le64 rx_gso_bytes;
> + le64 rx_gso_packets_coalesced;
> + le64 rx_gso_bytes_coalesced;
> + le64 rx_gso_segments;
> + le64 rx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_rx_reset {
> + le64 rx_reset;
> +};
> +
> +struct virtio_net_stats_tx_basic {
> + le64 tx_packets;
> + le64 tx_bytes;
> +
> + le64 tx_notification;
> + le64 tx_interrupt;
> +
> + le64 tx_drop;
> + le64 tx_drop_malformed;
> +};
> +
> +struct virtio_net_stats_tx_csum {
> + le64 tx_csum_none;
> + le64 tx_needs_csum;
> +};
> +
> +struct virtio_net_stats_tx_gso {
> + le64 tx_gso_packets;
> + le64 tx_gso_bytes;
> + le64 tx_gso_packets_split;
> + le64 tx_gso_bytes_split;
> + le64 tx_gso_segments;
> + le64 tx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_tx_reset {
> + le64 tx_reset;
> +};
> +
> +\end{lstlisting}
> +
> +\begin{description}
> + \item [nstats]
> + The number of \field{stats}.
> +
> + \item [queue_num]
> + The number of the virtqueue to obtain the statistics.
> +
> + \item [type]
> + The type of the stats to be obtained.
> +
> +\end{description}
> +
> +Correspondence between the vq type, the stats type, the stats structure and the
> +required features.
> +\begin{tabular}{ |l|l|l|l| }
> + \hline
> + VQ Type & Stats Type & Stats Structure & Features \\ \hline
> +
> + controlq & VIRTIO_NET_STATS_TYPE_CVQ & virtio_net_stats_cvq & \\ \hline
> +
> + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC & virtio_net_stats_rx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_CSUM & virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_GSO & virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> + VIRTIO_NET_F_GUEST_TSO6 or\newline
> + VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_RESET & virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> +
> + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC & virtio_net_stats_tx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_CSUM & virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_GSO & virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> + VIRTIO_NET_F_HOST_TSO6 or\newline
> + VIRTIO_NET_F_HOST_USO or\newline
> + VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_RESET & virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> + \hline
> +\end{tabular}
> +
> +
> +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> +
> +The structure corresponding to the controlq stats is virtio_net_stats_cvq.
> +
> +\begin{description}
> + \item [command_num]
> + The number of commands, including the current command.
> +
> + \item [ok_num]
> + The number of commands (including the current command) where the ack was VIRTIO_NET_OK.
> +\end{description}
> +
> +
> +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Basic Stats}
> +
> +The structure corresponding to the receiveq basic stats is virtio_net_stats_rx_basic.
> +
> +Receiveq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> +
> +\begin{description}
> + \item [rx_packets]
> + The number of packets received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_bytes]
> + The number of bytes received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_notification]
> + The number of driver notifications.
> +
> + \item [rx_interrupt]
> + The number of device interrupts.
> +
> + \item [rx_drop]
> + The number of packets dropped by the receiveq. Contains all kinds of
> + packet drop.
> +
> + \item [rx_drop_overruns]
> + The number of packets dropped by the receiveq when no more descriptors
> + were available.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Basic Stats}
> +
> +The structure corresponding to the transmitq basic stats is virtio_net_stats_tx_basic.
> +
> +Transmitq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> +
> +\begin{description}
> + \item [tx_packets]
> + The number of packets sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
> +
> + \item [tx_bytes]
> + The number of bytes sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
> +
> + \item [tx_notification]
> + The number of driver notifications.
> +
> + \item [tx_interrupt]
> + The number of device interrupts.
> +
> + \item [tx_drop]
> + The number of packets dropped by the transmitq. Contains all kinds of
> + packet drop.
> +
> + \item [tx_drop_malformed]
> + The number of packets dropped when the descriptor is in an error state.
> + For example, the buffer is too short.
> +
> +\end{description}
> +
> +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq CSUM Stats}
> +
> +The structure corresponding to the receiveq csum stats is virtio_net_stats_rx_csum.
> +
> +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the receiveq
> +csum stats can be obtained.
> +
> +The following are the receiveq csum stats:
> +
> +\begin{description}
> + \item [rx_csum_valid]
> + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> +
> + \item [rx_needs_csum]
> + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> +
> + \item [rx_csum_bad]
> + The number of packets with abnormal csum.
> +
> + \item [rx_csum_none]
> + The number of packets without hardware csum. The packet here refers to
> + the non-TCP/UDP packet that the backend cannot recognize.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq CSUM Stats}
> +
> +The structure corresponding to the transmitq csum stats is virtio_net_stats_tx_csum.
> +
> +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the transmitq csum
> +stats can be obtained.
> +
> +The following are the transmitq csum stats:
> +
> +\begin{description}
> + \item [tx_csum_none]
> + The number of packets that didn't require hardware csum.
> +
> + \item [tx_needs_csum]
> + The number of packets that required hardware csum.
> +
> +\end{description}
> +
> +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO Stats}
> +
> +The structure corresponding to the receiveq gso stats is virtio_net_stats_rx_gso.
> +
> +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> +been negotiated, the receiveq gso stats can be obtained.
> +
> +Rx gso packets refer to packets passed by the device to the driver where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [rx_gso_packets]
> + The number of the rx gso packets.
> +
> + \item [rx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the rx gso packets.
> +
> + \item [rx_gso_packets_coalesced]
> + The number of the rx gso packages generated by coalescing.
> +
> + \item [rx_gso_bytes_coalesced]
> + The number of bytes(excluding the virtio net header) of the rx gso packets generated by coalescing.
> +
> + \item [rx_gso_segments]
> + The number of coalesced segments.
> +
> + \item [rx_gso_segments_bytes]
> + The number of bytes of coalesced segments.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq GSO Stats}
> +
> +The structure corresponding to the transmitq gso stats is virtio_net_stats_tx_gso.
> +
> +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> +been negotiated, the transmitq gso stats can be obtained.
> +
> +Tx gso packets refer to packets passed by the driver to the device where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [tx_gso_packets]
> + The number of the tx gso packets.
> +
> + \item [tx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the tx gso packets.
> +
> + \item [tx_gso_packets_split]
> + The number of the tx gso packets that been split.
> +
> + \item [tx_gso_bytes_split]
> + The number of bytes(excluding the virtio net header) of the tx gso packets that been split.
> +
> + \item [tx_gso_segments]
> + The number of segments split from the gso package.
> +
> + \item [tx_gso_segments_bytes]
> + The number of bytes(excluding the virtio net header) of segments split from the gso package.
> +\end{description}
> +
> +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Reset Stats}
> +
> +The structure corresponding to the receiveq reset stats is virtio_net_stats_rx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq reset stats
> +can be obtained.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{rx_reset}.
> +
> +\begin{description}
> + \item [rx_reset]
> + The number of receiveq resets.
> +\end{description}
> +
> +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Reset Stats}
> +
> +The structure corresponding to the transmitq reset stats is virtio_net_stats_tx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq reset stats
> +can be obtained.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{tx_reset}.
> +
> +\begin{description}
> + \item [tx_reset]
> + The number of transmitq resets.
> +\end{description}
> +
> +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If virtio_net_ctrl_queue_stats is incorrect (such as the following), the device
> +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> +the device MUST abort the entire command.
> +\begin{itemize}
> + \item \field{queue_num} exceeds the queue range.
> + \item \field{type} is not a known value.
> + \item The type of vq does not match \field{type}. E.g. the driver tries to query
> + RX stats through a TX index.
> + \item The feature corresponding to the specified \field{type} was not successfully
> + negotiated.
> + \item The size of the buffer allocated by the driver for \field{command-specific-data-reply}
> + is less than the total size of the stats specialed by
> + \field{virtio_net_ctrl_queue_stats}.
> +\end{itemize}
> +
> +The device MUST write the requested stats structures in
> +\field{command-specific-data-reply} in the order specified by the structure
> +virtio_net_ctrl_queue_stats.
> +
> +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +When a driver tries to obtain a certain stats, it MUST confirm that the relevant
> +feature negotiation is successful.
> +
> +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to the vq
> +specified by \field{queue_num}.
> +
> +The \field{command-specific-data-reply} buffer allocated by the driver MUST be
> +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> +
> +When the driver reads the response, it MUST read
> +\field{command-specific-data-reply} one by one based on the \field{type}.
>
> \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> Types / Network Device / Legacy Interface: Framing Requirements}
> --
> 2.31.0
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
2023-07-10 7:28 ` [virtio-comment] " Xuan Zhuo
@ 2023-07-12 8:08 ` Jason Wang
-1 siblings, 0 replies; 21+ messages in thread
From: Jason Wang @ 2023-07-12 8:08 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
[-- Attachment #1: Type: text/plain, Size: 24557 bytes --]
On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
wrote:
> hi, guys
>
> After a lot of internal discussions, I removed some unimportant counters.
> Based
> on this v12 patch I am repling to, most of the requirements have been met.
>
> The patch link
> https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
>
> We still have these counters, let's see if they can be standardized.
>
> ## limit
>
> * tx_bps_limit_drops
> * tx_pps_limit_drops
> * rx_bps_limit_drops
> * rx_pps_limit_drops
>
> In a cloud scenario, multiple users purchase different VMs, and these VMs
> share
> the capabilities of the same host. In order to ensure that each VM will not
> affect others, the network card(virtio-net) capability of each VM is
> limited.
> These users purchase VMs, this limit has already been determined.
>
This seems a feature beyond the counters but QOS. I think we virtio spec
need to support QOS before we can discuss any QOS related counters.
>
> So if the network card traffic of a vm exceeds the upper limit, packet
> loss will
> occur. It is necessary for us to count these packet losses. And the device
> should expose to the user.
>
> ## session
>
> * tx_session_full_drops The number of packet drops in the sending
> direction when
> the session is full
> * rx_session_full_drops The number of packets lost when the session is
> full in the receiving direction
>
> Our dpu supports tcp connection tracking, but there is an upper limit to
> the
> number of connections, and if it exceeds, packet loss will also occur.
>
Similarly, if connect tracking offload is supported, it needs to be
implemented in the spec first then we can have related counters.
>
> ## ACL
>
> * tx_acl_drops ACL packet loss in the sending direction
> * rx_acl_drops The number of ACL packets lost in the receiving direction
>
> In our cloud service, for network cards, users are allowed to configure
> security
> rules,such as which IPs can access which ports of this machine.
>
Same as above, ACL should be supported by the spec first then the counters.
In conclusion, the features must be self contained. Otherwise you are doing
vDPA actually and those counters need to be accessed in a vendor specific
way.
Thanks
>
>
> Thanks
>
>
> On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> wrote:
> > This patch allows the driver to obtain some statistics from the device.
> >
> > In the back-end implementation, we can count a lot of such information,
> > which can be used for debugging and judging the running status of the
> > back-end. We hope to directly display it to the user through ethtool.
> >
> > To get stats atomically, try to get stats for all queue pairs in one
> > command.
> >
> > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > conformance.tex | 2 +
> > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > 2 files changed, 405 insertions(+), 3 deletions(-)
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 42f8537..c67f877 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> / Conformance Targets}
> > \item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Automatic receive steering in multiqueue
> mode}
> > \item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Offloads State Configuration / Setting
> Offloads State}
> > \item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > +\item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Device Stats}
> > \end{itemize}
> >
> > \conformance{\subsection}{Block Driver
> Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> Conformance}
> > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> / Conformance Targets}
> > \item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Gratuitous Packet Sending}
> > \item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Automatic receive steering in multiqueue
> mode}
> > \item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > +\item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Device Stats}
> > \end{itemize}
> >
> > \conformance{\subsection}{Block Device
> Conformance}\label{sec:Conformance / Device Conformance / Block Device
> Conformance}
> > diff --git a/content.tex b/content.tex
> > index c6f116c..81f325d 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> Network Device / Feature bits
> > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > channel.
> >
> > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> statistics
> > + to the driver through the control channel.
> > +
> > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> Unlike UFO
> > (fragmenting the packet) the USO splits large UDP packet
> > to several segments when each of these smaller packets has UDP header.
> > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> requirements}\label{sec:Device Types / Network Device
> > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> VIRTIO_NET_F_HOST_TSO6.
> > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > \end{description}
> > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> Types / Network Device / Devi
> > u8 command;
> > u8 command-specific-data[];
> > u8 ack;
> > + u8 command-specific-data-reply[];
> > };
> >
> > /* ack values */
> > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> Virtqueue}\label{sec:Device Types / Network Device / Devi
> > \end{lstlisting}
> >
> > The \field{class}, \field{command} and command-specific-data are set by
> the
> > -driver, and the device sets the \field{ack} byte. There is little it can
> > -do except issue a diagnostic if \field{ack} is not
> > -VIRTIO_NET_OK.
> > +driver, and the device sets the \field{ack} byte and optionally
> > +\field{command-specific-data-reply}. There is little the driver can
> > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > +
> > +The command VIRTIO_NET_CTRL_STATS_GET contains
> \field{command-specific-data-reply}.
> >
> > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > \label{sec:Device Types / Network Device / Device Operation / Control
> Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> Virtqueue}\label{sec:Device Types / Network Device / Devi
> > according to the native endian of the guest rather than
> > (necessarily when not using the legacy interface) little-endian.
> >
> > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> Device Operation / Control Virtqueue / Device Stats}
> > +
> > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > +get the device stats from the device in
> \field{command-specific-data-reply}.
> > +
> > +To get the stats, the following definitions are used:
> > +\begin{lstlisting}
> > +#define VIRTIO_NET_CTRL_STATS 6
> > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > +
> > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > +
> > +\end{lstlisting}
> > +
> > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> \field{command-specific-data}
> > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > +The result is returned by \field{command-specific-data-reply}.
> > +The stats ware returned in the order of the type specified in the
> > +\field{virtio_net_ctrl_queue_stats}.
> > +
> > +The following layout structures are used:
> > +
> > +\field{command-specific-data}
> > +\begin{lstlisting}
> > +struct virtio_net_ctrl_queue_stats {
> > + u16 nstats;
> > + struct {
> > + u16 queue_num;
> > + u16 type;
> > + } stats[];
> > +};
> > +\end{lstlisting}
> > +
> > +\field{command-specific-data-reply}
> > +\begin{lstlisting}
> > +struct virtio_net_stats_cvq {
> > + le64 command_num;
> > + le64 ok_num;
> > +};
> > +
> > +struct virtio_net_stats_rx_basic {
> > + le64 rx_packets;
> > + le64 rx_bytes;
> > +
> > + le64 rx_notification;
> > + le64 rx_interrupt;
> > +
> > + le64 rx_drop;
> > + le64 rx_drop_overruns;
> > +};
> > +
> > +struct virtio_net_stats_rx_csum {
> > + le64 rx_csum_valid;
> > + le64 rx_needs_csum;
> > + le64 rx_csum_bad;
> > + le64 rx_csum_none;
> > +};
> > +
> > +struct virtio_net_stats_rx_gso {
> > + le64 rx_gso_packets;
> > + le64 rx_gso_bytes;
> > + le64 rx_gso_packets_coalesced;
> > + le64 rx_gso_bytes_coalesced;
> > + le64 rx_gso_segments;
> > + le64 rx_gso_segments_bytes;
> > +};
> > +
> > +struct virtio_net_stats_rx_reset {
> > + le64 rx_reset;
> > +};
> > +
> > +struct virtio_net_stats_tx_basic {
> > + le64 tx_packets;
> > + le64 tx_bytes;
> > +
> > + le64 tx_notification;
> > + le64 tx_interrupt;
> > +
> > + le64 tx_drop;
> > + le64 tx_drop_malformed;
> > +};
> > +
> > +struct virtio_net_stats_tx_csum {
> > + le64 tx_csum_none;
> > + le64 tx_needs_csum;
> > +};
> > +
> > +struct virtio_net_stats_tx_gso {
> > + le64 tx_gso_packets;
> > + le64 tx_gso_bytes;
> > + le64 tx_gso_packets_split;
> > + le64 tx_gso_bytes_split;
> > + le64 tx_gso_segments;
> > + le64 tx_gso_segments_bytes;
> > +};
> > +
> > +struct virtio_net_stats_tx_reset {
> > + le64 tx_reset;
> > +};
> > +
> > +\end{lstlisting}
> > +
> > +\begin{description}
> > + \item [nstats]
> > + The number of \field{stats}.
> > +
> > + \item [queue_num]
> > + The number of the virtqueue to obtain the statistics.
> > +
> > + \item [type]
> > + The type of the stats to be obtained.
> > +
> > +\end{description}
> > +
> > +Correspondence between the vq type, the stats type, the stats structure
> and the
> > +required features.
> > +\begin{tabular}{ |l|l|l|l| }
> > + \hline
> > + VQ Type & Stats Type & Stats
> Structure & Features \\ \hline
> > +
> > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> virtio_net_stats_cvq & \\ \hline
> > +
> > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> virtio_net_stats_rx_basic & \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > +
> VIRTIO_NET_F_GUEST_TSO6 or\newline
> > +
> VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > +
> > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> virtio_net_stats_tx_basic & \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > +
> VIRTIO_NET_F_HOST_TSO6 or\newline
> > +
> VIRTIO_NET_F_HOST_USO or\newline
> > +
> VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > + \hline
> > +\end{tabular}
> > +
> > +
> > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > +
> > +The structure corresponding to the controlq stats is
> virtio_net_stats_cvq.
> > +
> > +\begin{description}
> > + \item [command_num]
> > + The number of commands, including the current command.
> > +
> > + \item [ok_num]
> > + The number of commands (including the current command) where
> the ack was VIRTIO_NET_OK.
> > +\end{description}
> > +
> > +
> > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> Basic Stats}
> > +
> > +The structure corresponding to the receiveq basic stats is
> virtio_net_stats_rx_basic.
> > +
> > +Receiveq basic stats doesn't need any features, as long as the device
> supports
> > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > +
> > +\begin{description}
> > + \item [rx_packets]
> > + The number of packets received by device (not the packets
> passed to the
> > + guest), including the dropped packets by device.
> > +
> > + \item [rx_bytes]
> > + The number of bytes received by device (not the packets passed
> to the
> > + guest), including the dropped packets by device.
> > +
> > + \item [rx_notification]
> > + The number of driver notifications.
> > +
> > + \item [rx_interrupt]
> > + The number of device interrupts.
> > +
> > + \item [rx_drop]
> > + The number of packets dropped by the receiveq. Contains all
> kinds of
> > + packet drop.
> > +
> > + \item [rx_drop_overruns]
> > + The number of packets dropped by the receiveq when no more
> descriptors
> > + were available.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> Basic Stats}
> > +
> > +The structure corresponding to the transmitq basic stats is
> virtio_net_stats_tx_basic.
> > +
> > +Transmitq basic stats doesn't need any features, as long as the device
> supports
> > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > +
> > +\begin{description}
> > + \item [tx_packets]
> > + The number of packets sent by device (not the packets got from
> the
> > + guest), excluding the dropped packets by device.
> > +
> > + \item [tx_bytes]
> > + The number of bytes sent by device (not the packets got from the
> > + guest), excluding the dropped packets by device.
> > +
> > + \item [tx_notification]
> > + The number of driver notifications.
> > +
> > + \item [tx_interrupt]
> > + The number of device interrupts.
> > +
> > + \item [tx_drop]
> > + The number of packets dropped by the transmitq. Contains all
> kinds of
> > + packet drop.
> > +
> > + \item [tx_drop_malformed]
> > + The number of packets dropped when the descriptor is in an
> error state.
> > + For example, the buffer is too short.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> CSUM Stats}
> > +
> > +The structure corresponding to the receiveq csum stats is
> virtio_net_stats_rx_csum.
> > +
> > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> receiveq
> > +csum stats can be obtained.
> > +
> > +The following are the receiveq csum stats:
> > +
> > +\begin{description}
> > + \item [rx_csum_valid]
> > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > +
> > + \item [rx_needs_csum]
> > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > +
> > + \item [rx_csum_bad]
> > + The number of packets with abnormal csum.
> > +
> > + \item [rx_csum_none]
> > + The number of packets without hardware csum. The packet here
> refers to
> > + the non-TCP/UDP packet that the backend cannot recognize.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> CSUM Stats}
> > +
> > +The structure corresponding to the transmitq csum stats is
> virtio_net_stats_tx_csum.
> > +
> > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> transmitq csum
> > +stats can be obtained.
> > +
> > +The following are the transmitq csum stats:
> > +
> > +\begin{description}
> > + \item [tx_csum_none]
> > + The number of packets that didn't require hardware csum.
> > +
> > + \item [tx_needs_csum]
> > + The number of packets that required hardware csum.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> Stats}
> > +
> > +The structure corresponding to the receiveq gso stats is
> virtio_net_stats_rx_gso.
> > +
> > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > +been negotiated, the receiveq gso stats can be obtained.
> > +
> > +Rx gso packets refer to packets passed by the device to the driver where
> > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > +
> > +\begin{description}
> > + \item [rx_gso_packets]
> > + The number of the rx gso packets.
> > +
> > + \item [rx_gso_bytes]
> > + The number of bytes(excluding the virtio net header) of the rx
> gso packets.
> > +
> > + \item [rx_gso_packets_coalesced]
> > + The number of the rx gso packages generated by coalescing.
> > +
> > + \item [rx_gso_bytes_coalesced]
> > + The number of bytes(excluding the virtio net header) of the rx
> gso packets generated by coalescing.
> > +
> > + \item [rx_gso_segments]
> > + The number of coalesced segments.
> > +
> > + \item [rx_gso_segments_bytes]
> > + The number of bytes of coalesced segments.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> GSO Stats}
> > +
> > +The structure corresponding to the transmitq gso stats is
> virtio_net_stats_tx_gso.
> > +
> > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > +been negotiated, the transmitq gso stats can be obtained.
> > +
> > +Tx gso packets refer to packets passed by the driver to the device where
> > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > +
> > +\begin{description}
> > + \item [tx_gso_packets]
> > + The number of the tx gso packets.
> > +
> > + \item [tx_gso_bytes]
> > + The number of bytes(excluding the virtio net header) of the tx
> gso packets.
> > +
> > + \item [tx_gso_packets_split]
> > + The number of the tx gso packets that been split.
> > +
> > + \item [tx_gso_bytes_split]
> > + The number of bytes(excluding the virtio net header) of the tx
> gso packets that been split.
> > +
> > + \item [tx_gso_segments]
> > + The number of segments split from the gso package.
> > +
> > + \item [tx_gso_segments_bytes]
> > + The number of bytes(excluding the virtio net header) of
> segments split from the gso package.
> > +\end{description}
> > +
> > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> Reset Stats}
> > +
> > +The structure corresponding to the receiveq reset stats is
> virtio_net_stats_rx_reset.
> > +
> > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> reset stats
> > +can be obtained.
> > +
> > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> Virtqueue Reset}
> > +for more about \field{rx_reset}.
> > +
> > +\begin{description}
> > + \item [rx_reset]
> > + The number of receiveq resets.
> > +\end{description}
> > +
> > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> Reset Stats}
> > +
> > +The structure corresponding to the transmitq reset stats is
> virtio_net_stats_tx_reset.
> > +
> > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> reset stats
> > +can be obtained.
> > +
> > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> Virtqueue Reset}
> > +for more about \field{tx_reset}.
> > +
> > +\begin{description}
> > + \item [tx_reset]
> > + The number of transmitq resets.
> > +\end{description}
> > +
> > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats}
> > +
> > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> the device
> > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > +the device MUST abort the entire command.
> > +\begin{itemize}
> > + \item \field{queue_num} exceeds the queue range.
> > + \item \field{type} is not a known value.
> > + \item The type of vq does not match \field{type}. E.g. the driver
> tries to query
> > + RX stats through a TX index.
> > + \item The feature corresponding to the specified \field{type} was
> not successfully
> > + negotiated.
> > + \item The size of the buffer allocated by the driver for
> \field{command-specific-data-reply}
> > + is less than the total size of the stats specialed by
> > + \field{virtio_net_ctrl_queue_stats}.
> > +\end{itemize}
> > +
> > +The device MUST write the requested stats structures in
> > +\field{command-specific-data-reply} in the order specified by the
> structure
> > +virtio_net_ctrl_queue_stats.
> > +
> > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats}
> > +
> > +When a driver tries to obtain a certain stats, it MUST confirm that the
> relevant
> > +feature negotiation is successful.
> > +
> > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> the vq
> > +specified by \field{queue_num}.
> > +
> > +The \field{command-specific-data-reply} buffer allocated by the driver
> MUST be
> > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > +
> > +When the driver reads the response, it MUST read
> > +\field{command-specific-data-reply} one by one based on the
> \field{type}.
> >
> > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > Types / Network Device / Legacy Interface: Framing Requirements}
> > --
> > 2.31.0
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
>
>
[-- Attachment #2: Type: text/html, Size: 29421 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-comment] Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
@ 2023-07-12 8:08 ` Jason Wang
0 siblings, 0 replies; 21+ messages in thread
From: Jason Wang @ 2023-07-12 8:08 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
[-- Attachment #1: Type: text/plain, Size: 24557 bytes --]
On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
wrote:
> hi, guys
>
> After a lot of internal discussions, I removed some unimportant counters.
> Based
> on this v12 patch I am repling to, most of the requirements have been met.
>
> The patch link
> https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
>
> We still have these counters, let's see if they can be standardized.
>
> ## limit
>
> * tx_bps_limit_drops
> * tx_pps_limit_drops
> * rx_bps_limit_drops
> * rx_pps_limit_drops
>
> In a cloud scenario, multiple users purchase different VMs, and these VMs
> share
> the capabilities of the same host. In order to ensure that each VM will not
> affect others, the network card(virtio-net) capability of each VM is
> limited.
> These users purchase VMs, this limit has already been determined.
>
This seems a feature beyond the counters but QOS. I think we virtio spec
need to support QOS before we can discuss any QOS related counters.
>
> So if the network card traffic of a vm exceeds the upper limit, packet
> loss will
> occur. It is necessary for us to count these packet losses. And the device
> should expose to the user.
>
> ## session
>
> * tx_session_full_drops The number of packet drops in the sending
> direction when
> the session is full
> * rx_session_full_drops The number of packets lost when the session is
> full in the receiving direction
>
> Our dpu supports tcp connection tracking, but there is an upper limit to
> the
> number of connections, and if it exceeds, packet loss will also occur.
>
Similarly, if connect tracking offload is supported, it needs to be
implemented in the spec first then we can have related counters.
>
> ## ACL
>
> * tx_acl_drops ACL packet loss in the sending direction
> * rx_acl_drops The number of ACL packets lost in the receiving direction
>
> In our cloud service, for network cards, users are allowed to configure
> security
> rules,such as which IPs can access which ports of this machine.
>
Same as above, ACL should be supported by the spec first then the counters.
In conclusion, the features must be self contained. Otherwise you are doing
vDPA actually and those counters need to be accessed in a vendor specific
way.
Thanks
>
>
> Thanks
>
>
> On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> wrote:
> > This patch allows the driver to obtain some statistics from the device.
> >
> > In the back-end implementation, we can count a lot of such information,
> > which can be used for debugging and judging the running status of the
> > back-end. We hope to directly display it to the user through ethtool.
> >
> > To get stats atomically, try to get stats for all queue pairs in one
> > command.
> >
> > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > conformance.tex | 2 +
> > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > 2 files changed, 405 insertions(+), 3 deletions(-)
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 42f8537..c67f877 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> / Conformance Targets}
> > \item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Automatic receive steering in multiqueue
> mode}
> > \item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Offloads State Configuration / Setting
> Offloads State}
> > \item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > +\item \ref{drivernormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Device Stats}
> > \end{itemize}
> >
> > \conformance{\subsection}{Block Driver
> Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> Conformance}
> > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> / Conformance Targets}
> > \item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Gratuitous Packet Sending}
> > \item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Automatic receive steering in multiqueue
> mode}
> > \item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > +\item \ref{devicenormative:Device Types / Network Device / Device
> Operation / Control Virtqueue / Device Stats}
> > \end{itemize}
> >
> > \conformance{\subsection}{Block Device
> Conformance}\label{sec:Conformance / Device Conformance / Block Device
> Conformance}
> > diff --git a/content.tex b/content.tex
> > index c6f116c..81f325d 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> Network Device / Feature bits
> > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > channel.
> >
> > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> statistics
> > + to the driver through the control channel.
> > +
> > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> Unlike UFO
> > (fragmenting the packet) the USO splits large UDP packet
> > to several segments when each of these smaller packets has UDP header.
> > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> requirements}\label{sec:Device Types / Network Device
> > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> VIRTIO_NET_F_HOST_TSO6.
> > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > \end{description}
> > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> Types / Network Device / Devi
> > u8 command;
> > u8 command-specific-data[];
> > u8 ack;
> > + u8 command-specific-data-reply[];
> > };
> >
> > /* ack values */
> > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> Virtqueue}\label{sec:Device Types / Network Device / Devi
> > \end{lstlisting}
> >
> > The \field{class}, \field{command} and command-specific-data are set by
> the
> > -driver, and the device sets the \field{ack} byte. There is little it can
> > -do except issue a diagnostic if \field{ack} is not
> > -VIRTIO_NET_OK.
> > +driver, and the device sets the \field{ack} byte and optionally
> > +\field{command-specific-data-reply}. There is little the driver can
> > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > +
> > +The command VIRTIO_NET_CTRL_STATS_GET contains
> \field{command-specific-data-reply}.
> >
> > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > \label{sec:Device Types / Network Device / Device Operation / Control
> Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> Virtqueue}\label{sec:Device Types / Network Device / Devi
> > according to the native endian of the guest rather than
> > (necessarily when not using the legacy interface) little-endian.
> >
> > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> Device Operation / Control Virtqueue / Device Stats}
> > +
> > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > +get the device stats from the device in
> \field{command-specific-data-reply}.
> > +
> > +To get the stats, the following definitions are used:
> > +\begin{lstlisting}
> > +#define VIRTIO_NET_CTRL_STATS 6
> > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > +
> > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > +
> > +\end{lstlisting}
> > +
> > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> \field{command-specific-data}
> > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > +The result is returned by \field{command-specific-data-reply}.
> > +The stats ware returned in the order of the type specified in the
> > +\field{virtio_net_ctrl_queue_stats}.
> > +
> > +The following layout structures are used:
> > +
> > +\field{command-specific-data}
> > +\begin{lstlisting}
> > +struct virtio_net_ctrl_queue_stats {
> > + u16 nstats;
> > + struct {
> > + u16 queue_num;
> > + u16 type;
> > + } stats[];
> > +};
> > +\end{lstlisting}
> > +
> > +\field{command-specific-data-reply}
> > +\begin{lstlisting}
> > +struct virtio_net_stats_cvq {
> > + le64 command_num;
> > + le64 ok_num;
> > +};
> > +
> > +struct virtio_net_stats_rx_basic {
> > + le64 rx_packets;
> > + le64 rx_bytes;
> > +
> > + le64 rx_notification;
> > + le64 rx_interrupt;
> > +
> > + le64 rx_drop;
> > + le64 rx_drop_overruns;
> > +};
> > +
> > +struct virtio_net_stats_rx_csum {
> > + le64 rx_csum_valid;
> > + le64 rx_needs_csum;
> > + le64 rx_csum_bad;
> > + le64 rx_csum_none;
> > +};
> > +
> > +struct virtio_net_stats_rx_gso {
> > + le64 rx_gso_packets;
> > + le64 rx_gso_bytes;
> > + le64 rx_gso_packets_coalesced;
> > + le64 rx_gso_bytes_coalesced;
> > + le64 rx_gso_segments;
> > + le64 rx_gso_segments_bytes;
> > +};
> > +
> > +struct virtio_net_stats_rx_reset {
> > + le64 rx_reset;
> > +};
> > +
> > +struct virtio_net_stats_tx_basic {
> > + le64 tx_packets;
> > + le64 tx_bytes;
> > +
> > + le64 tx_notification;
> > + le64 tx_interrupt;
> > +
> > + le64 tx_drop;
> > + le64 tx_drop_malformed;
> > +};
> > +
> > +struct virtio_net_stats_tx_csum {
> > + le64 tx_csum_none;
> > + le64 tx_needs_csum;
> > +};
> > +
> > +struct virtio_net_stats_tx_gso {
> > + le64 tx_gso_packets;
> > + le64 tx_gso_bytes;
> > + le64 tx_gso_packets_split;
> > + le64 tx_gso_bytes_split;
> > + le64 tx_gso_segments;
> > + le64 tx_gso_segments_bytes;
> > +};
> > +
> > +struct virtio_net_stats_tx_reset {
> > + le64 tx_reset;
> > +};
> > +
> > +\end{lstlisting}
> > +
> > +\begin{description}
> > + \item [nstats]
> > + The number of \field{stats}.
> > +
> > + \item [queue_num]
> > + The number of the virtqueue to obtain the statistics.
> > +
> > + \item [type]
> > + The type of the stats to be obtained.
> > +
> > +\end{description}
> > +
> > +Correspondence between the vq type, the stats type, the stats structure
> and the
> > +required features.
> > +\begin{tabular}{ |l|l|l|l| }
> > + \hline
> > + VQ Type & Stats Type & Stats
> Structure & Features \\ \hline
> > +
> > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> virtio_net_stats_cvq & \\ \hline
> > +
> > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> virtio_net_stats_rx_basic & \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > +
> VIRTIO_NET_F_GUEST_TSO6 or\newline
> > +
> VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > +
> > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> virtio_net_stats_tx_basic & \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > +
> VIRTIO_NET_F_HOST_TSO6 or\newline
> > +
> VIRTIO_NET_F_HOST_USO or\newline
> > +
> VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > + \hline
> > +\end{tabular}
> > +
> > +
> > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > +
> > +The structure corresponding to the controlq stats is
> virtio_net_stats_cvq.
> > +
> > +\begin{description}
> > + \item [command_num]
> > + The number of commands, including the current command.
> > +
> > + \item [ok_num]
> > + The number of commands (including the current command) where
> the ack was VIRTIO_NET_OK.
> > +\end{description}
> > +
> > +
> > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> Basic Stats}
> > +
> > +The structure corresponding to the receiveq basic stats is
> virtio_net_stats_rx_basic.
> > +
> > +Receiveq basic stats doesn't need any features, as long as the device
> supports
> > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > +
> > +\begin{description}
> > + \item [rx_packets]
> > + The number of packets received by device (not the packets
> passed to the
> > + guest), including the dropped packets by device.
> > +
> > + \item [rx_bytes]
> > + The number of bytes received by device (not the packets passed
> to the
> > + guest), including the dropped packets by device.
> > +
> > + \item [rx_notification]
> > + The number of driver notifications.
> > +
> > + \item [rx_interrupt]
> > + The number of device interrupts.
> > +
> > + \item [rx_drop]
> > + The number of packets dropped by the receiveq. Contains all
> kinds of
> > + packet drop.
> > +
> > + \item [rx_drop_overruns]
> > + The number of packets dropped by the receiveq when no more
> descriptors
> > + were available.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> Basic Stats}
> > +
> > +The structure corresponding to the transmitq basic stats is
> virtio_net_stats_tx_basic.
> > +
> > +Transmitq basic stats doesn't need any features, as long as the device
> supports
> > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > +
> > +\begin{description}
> > + \item [tx_packets]
> > + The number of packets sent by device (not the packets got from
> the
> > + guest), excluding the dropped packets by device.
> > +
> > + \item [tx_bytes]
> > + The number of bytes sent by device (not the packets got from the
> > + guest), excluding the dropped packets by device.
> > +
> > + \item [tx_notification]
> > + The number of driver notifications.
> > +
> > + \item [tx_interrupt]
> > + The number of device interrupts.
> > +
> > + \item [tx_drop]
> > + The number of packets dropped by the transmitq. Contains all
> kinds of
> > + packet drop.
> > +
> > + \item [tx_drop_malformed]
> > + The number of packets dropped when the descriptor is in an
> error state.
> > + For example, the buffer is too short.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> CSUM Stats}
> > +
> > +The structure corresponding to the receiveq csum stats is
> virtio_net_stats_rx_csum.
> > +
> > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> receiveq
> > +csum stats can be obtained.
> > +
> > +The following are the receiveq csum stats:
> > +
> > +\begin{description}
> > + \item [rx_csum_valid]
> > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > +
> > + \item [rx_needs_csum]
> > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > +
> > + \item [rx_csum_bad]
> > + The number of packets with abnormal csum.
> > +
> > + \item [rx_csum_none]
> > + The number of packets without hardware csum. The packet here
> refers to
> > + the non-TCP/UDP packet that the backend cannot recognize.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> CSUM Stats}
> > +
> > +The structure corresponding to the transmitq csum stats is
> virtio_net_stats_tx_csum.
> > +
> > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> transmitq csum
> > +stats can be obtained.
> > +
> > +The following are the transmitq csum stats:
> > +
> > +\begin{description}
> > + \item [tx_csum_none]
> > + The number of packets that didn't require hardware csum.
> > +
> > + \item [tx_needs_csum]
> > + The number of packets that required hardware csum.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> Stats}
> > +
> > +The structure corresponding to the receiveq gso stats is
> virtio_net_stats_rx_gso.
> > +
> > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > +been negotiated, the receiveq gso stats can be obtained.
> > +
> > +Rx gso packets refer to packets passed by the device to the driver where
> > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > +
> > +\begin{description}
> > + \item [rx_gso_packets]
> > + The number of the rx gso packets.
> > +
> > + \item [rx_gso_bytes]
> > + The number of bytes(excluding the virtio net header) of the rx
> gso packets.
> > +
> > + \item [rx_gso_packets_coalesced]
> > + The number of the rx gso packages generated by coalescing.
> > +
> > + \item [rx_gso_bytes_coalesced]
> > + The number of bytes(excluding the virtio net header) of the rx
> gso packets generated by coalescing.
> > +
> > + \item [rx_gso_segments]
> > + The number of coalesced segments.
> > +
> > + \item [rx_gso_segments_bytes]
> > + The number of bytes of coalesced segments.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> GSO Stats}
> > +
> > +The structure corresponding to the transmitq gso stats is
> virtio_net_stats_tx_gso.
> > +
> > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > +been negotiated, the transmitq gso stats can be obtained.
> > +
> > +Tx gso packets refer to packets passed by the driver to the device where
> > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > +
> > +\begin{description}
> > + \item [tx_gso_packets]
> > + The number of the tx gso packets.
> > +
> > + \item [tx_gso_bytes]
> > + The number of bytes(excluding the virtio net header) of the tx
> gso packets.
> > +
> > + \item [tx_gso_packets_split]
> > + The number of the tx gso packets that been split.
> > +
> > + \item [tx_gso_bytes_split]
> > + The number of bytes(excluding the virtio net header) of the tx
> gso packets that been split.
> > +
> > + \item [tx_gso_segments]
> > + The number of segments split from the gso package.
> > +
> > + \item [tx_gso_segments_bytes]
> > + The number of bytes(excluding the virtio net header) of
> segments split from the gso package.
> > +\end{description}
> > +
> > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> Reset Stats}
> > +
> > +The structure corresponding to the receiveq reset stats is
> virtio_net_stats_rx_reset.
> > +
> > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> reset stats
> > +can be obtained.
> > +
> > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> Virtqueue Reset}
> > +for more about \field{rx_reset}.
> > +
> > +\begin{description}
> > + \item [rx_reset]
> > + The number of receiveq resets.
> > +\end{description}
> > +
> > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> Reset Stats}
> > +
> > +The structure corresponding to the transmitq reset stats is
> virtio_net_stats_tx_reset.
> > +
> > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> reset stats
> > +can be obtained.
> > +
> > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> Virtqueue Reset}
> > +for more about \field{tx_reset}.
> > +
> > +\begin{description}
> > + \item [tx_reset]
> > + The number of transmitq resets.
> > +\end{description}
> > +
> > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats}
> > +
> > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> the device
> > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > +the device MUST abort the entire command.
> > +\begin{itemize}
> > + \item \field{queue_num} exceeds the queue range.
> > + \item \field{type} is not a known value.
> > + \item The type of vq does not match \field{type}. E.g. the driver
> tries to query
> > + RX stats through a TX index.
> > + \item The feature corresponding to the specified \field{type} was
> not successfully
> > + negotiated.
> > + \item The size of the buffer allocated by the driver for
> \field{command-specific-data-reply}
> > + is less than the total size of the stats specialed by
> > + \field{virtio_net_ctrl_queue_stats}.
> > +\end{itemize}
> > +
> > +The device MUST write the requested stats structures in
> > +\field{command-specific-data-reply} in the order specified by the
> structure
> > +virtio_net_ctrl_queue_stats.
> > +
> > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> Device / Device Operation / Control Virtqueue / Device Stats}
> > +
> > +When a driver tries to obtain a certain stats, it MUST confirm that the
> relevant
> > +feature negotiation is successful.
> > +
> > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> the vq
> > +specified by \field{queue_num}.
> > +
> > +The \field{command-specific-data-reply} buffer allocated by the driver
> MUST be
> > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > +
> > +When the driver reads the response, it MUST read
> > +\field{command-specific-data-reply} one by one based on the
> \field{type}.
> >
> > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > Types / Network Device / Legacy Interface: Framing Requirements}
> > --
> > 2.31.0
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
>
>
[-- Attachment #2: Type: text/html, Size: 29421 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
2023-07-12 8:08 ` [virtio-comment] " Jason Wang
@ 2023-07-12 9:11 ` Xuan Zhuo
-1 siblings, 0 replies; 21+ messages in thread
From: Xuan Zhuo @ 2023-07-12 9:11 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
On Wed, 12 Jul 2023 16:08:48 +0800, Jason Wang <jasowang@redhat.com> wrote:
> On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> wrote:
>
> > hi, guys
> >
> > After a lot of internal discussions, I removed some unimportant counters.
> > Based
> > on this v12 patch I am repling to, most of the requirements have been met.
> >
> > The patch link
> > https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
> >
> > We still have these counters, let's see if they can be standardized.
> >
> > ## limit
> >
> > * tx_bps_limit_drops
> > * tx_pps_limit_drops
> > * rx_bps_limit_drops
> > * rx_pps_limit_drops
> >
> > In a cloud scenario, multiple users purchase different VMs, and these VMs
> > share
> > the capabilities of the same host. In order to ensure that each VM will not
> > affect others, the network card(virtio-net) capability of each VM is
> > limited.
> > These users purchase VMs, this limit has already been determined.
> >
>
> This seems a feature beyond the counters but QOS. I think we virtio spec
> need to support QOS before we can discuss any QOS related counters.
>
>
> >
> > So if the network card traffic of a vm exceeds the upper limit, packet
> > loss will
> > occur. It is necessary for us to count these packet losses. And the device
> > should expose to the user.
> >
> > ## session
> >
> > * tx_session_full_drops The number of packet drops in the sending
> > direction when
> > the session is full
> > * rx_session_full_drops The number of packets lost when the session is
> > full in the receiving direction
> >
> > Our dpu supports tcp connection tracking, but there is an upper limit to
> > the
> > number of connections, and if it exceeds, packet loss will also occur.
> >
>
> Similarly, if connect tracking offload is supported, it needs to be
> implemented in the spec first then we can have related counters.
>
>
> >
> > ## ACL
> >
> > * tx_acl_drops ACL packet loss in the sending direction
> > * rx_acl_drops The number of ACL packets lost in the receiving direction
> >
> > In our cloud service, for network cards, users are allowed to configure
> > security
> > rules,such as which IPs can access which ports of this machine.
> >
>
> Same as above, ACL should be supported by the spec first then the counters.
>
> In conclusion, the features must be self contained. Otherwise you are doing
> vDPA actually and those counters need to be accessed in a vendor specific
> way.
Yes that's the point, as we've discussed here.
http://lore.kernel.org/all/1686550355.2503424-1-xuanzhuo@linux.alibaba.com
There are many similar counters. There may not be many usage scenarios, so I
didn't list them here.
Our acl, seesion, and limit are not configured by the user at the driver layer,
and I don't think these should be configured at the driver. So at least as
far as our usage scenarios are concerned, these are some functions that have
nothing to do with virtio spec.
So what I want most is that the virto spec supports a vendor channel.
Of course, I am ok with Parav's abstraction of "limit".
Some implementations of txq are lossy and some are not creating backpressure/flow control to driver so driver can rate limit it naturally.
So a tx packet drop counter is needed to cover the lossy implementations which is abstract enough regardless of reason on why device dropped it.
A more granular counter becomes vendor specific that we can possibly avoid or place under different command.
But acl and session may not be very good to abstract.
Thanks.
>
> Thanks
>
>
> >
> >
> > Thanks
> >
> >
> > On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > wrote:
> > > This patch allows the driver to obtain some statistics from the device.
> > >
> > > In the back-end implementation, we can count a lot of such information,
> > > which can be used for debugging and judging the running status of the
> > > back-end. We hope to directly display it to the user through ethtool.
> > >
> > > To get stats atomically, try to get stats for all queue pairs in one
> > > command.
> > >
> > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > > conformance.tex | 2 +
> > > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 405 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/conformance.tex b/conformance.tex
> > > index 42f8537..c67f877 100644
> > > --- a/conformance.tex
> > > +++ b/conformance.tex
> > > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > / Conformance Targets}
> > > \item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > mode}
> > > \item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Offloads State Configuration / Setting
> > Offloads State}
> > > \item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > +\item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Device Stats}
> > > \end{itemize}
> > >
> > > \conformance{\subsection}{Block Driver
> > Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> > Conformance}
> > > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > / Conformance Targets}
> > > \item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > \item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > mode}
> > > \item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > > +\item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Device Stats}
> > > \end{itemize}
> > >
> > > \conformance{\subsection}{Block Device
> > Conformance}\label{sec:Conformance / Device Conformance / Block Device
> > Conformance}
> > > diff --git a/content.tex b/content.tex
> > > index c6f116c..81f325d 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> > Network Device / Feature bits
> > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > > channel.
> > >
> > > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> > statistics
> > > + to the driver through the control channel.
> > > +
> > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> > Unlike UFO
> > > (fragmenting the packet) the USO splits large UDP packet
> > > to several segments when each of these smaller packets has UDP header.
> > > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> > requirements}\label{sec:Device Types / Network Device
> > > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> > VIRTIO_NET_F_HOST_TSO6.
> > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \end{description}
> > > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > Types / Network Device / Devi
> > > u8 command;
> > > u8 command-specific-data[];
> > > u8 ack;
> > > + u8 command-specific-data-reply[];
> > > };
> > >
> > > /* ack values */
> > > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > \end{lstlisting}
> > >
> > > The \field{class}, \field{command} and command-specific-data are set by
> > the
> > > -driver, and the device sets the \field{ack} byte. There is little it can
> > > -do except issue a diagnostic if \field{ack} is not
> > > -VIRTIO_NET_OK.
> > > +driver, and the device sets the \field{ack} byte and optionally
> > > +\field{command-specific-data-reply}. There is little the driver can
> > > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > > +
> > > +The command VIRTIO_NET_CTRL_STATS_GET contains
> > \field{command-specific-data-reply}.
> > >
> > > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > > \label{sec:Device Types / Network Device / Device Operation / Control
> > Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > according to the native endian of the guest rather than
> > > (necessarily when not using the legacy interface) little-endian.
> > >
> > > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> > Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > > +get the device stats from the device in
> > \field{command-specific-data-reply}.
> > > +
> > > +To get the stats, the following definitions are used:
> > > +\begin{lstlisting}
> > > +#define VIRTIO_NET_CTRL_STATS 6
> > > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > > +
> > > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > > +
> > > +\end{lstlisting}
> > > +
> > > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> > \field{command-specific-data}
> > > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > > +The result is returned by \field{command-specific-data-reply}.
> > > +The stats ware returned in the order of the type specified in the
> > > +\field{virtio_net_ctrl_queue_stats}.
> > > +
> > > +The following layout structures are used:
> > > +
> > > +\field{command-specific-data}
> > > +\begin{lstlisting}
> > > +struct virtio_net_ctrl_queue_stats {
> > > + u16 nstats;
> > > + struct {
> > > + u16 queue_num;
> > > + u16 type;
> > > + } stats[];
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\field{command-specific-data-reply}
> > > +\begin{lstlisting}
> > > +struct virtio_net_stats_cvq {
> > > + le64 command_num;
> > > + le64 ok_num;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_basic {
> > > + le64 rx_packets;
> > > + le64 rx_bytes;
> > > +
> > > + le64 rx_notification;
> > > + le64 rx_interrupt;
> > > +
> > > + le64 rx_drop;
> > > + le64 rx_drop_overruns;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_csum {
> > > + le64 rx_csum_valid;
> > > + le64 rx_needs_csum;
> > > + le64 rx_csum_bad;
> > > + le64 rx_csum_none;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_gso {
> > > + le64 rx_gso_packets;
> > > + le64 rx_gso_bytes;
> > > + le64 rx_gso_packets_coalesced;
> > > + le64 rx_gso_bytes_coalesced;
> > > + le64 rx_gso_segments;
> > > + le64 rx_gso_segments_bytes;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_reset {
> > > + le64 rx_reset;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_basic {
> > > + le64 tx_packets;
> > > + le64 tx_bytes;
> > > +
> > > + le64 tx_notification;
> > > + le64 tx_interrupt;
> > > +
> > > + le64 tx_drop;
> > > + le64 tx_drop_malformed;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_csum {
> > > + le64 tx_csum_none;
> > > + le64 tx_needs_csum;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_gso {
> > > + le64 tx_gso_packets;
> > > + le64 tx_gso_bytes;
> > > + le64 tx_gso_packets_split;
> > > + le64 tx_gso_bytes_split;
> > > + le64 tx_gso_segments;
> > > + le64 tx_gso_segments_bytes;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_reset {
> > > + le64 tx_reset;
> > > +};
> > > +
> > > +\end{lstlisting}
> > > +
> > > +\begin{description}
> > > + \item [nstats]
> > > + The number of \field{stats}.
> > > +
> > > + \item [queue_num]
> > > + The number of the virtqueue to obtain the statistics.
> > > +
> > > + \item [type]
> > > + The type of the stats to be obtained.
> > > +
> > > +\end{description}
> > > +
> > > +Correspondence between the vq type, the stats type, the stats structure
> > and the
> > > +required features.
> > > +\begin{tabular}{ |l|l|l|l| }
> > > + \hline
> > > + VQ Type & Stats Type & Stats
> > Structure & Features \\ \hline
> > > +
> > > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> > virtio_net_stats_cvq & \\ \hline
> > > +
> > > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> > virtio_net_stats_rx_basic & \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> > virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> > virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > > +
> > VIRTIO_NET_F_GUEST_TSO6 or\newline
> > > +
> > VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> > virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > > +
> > > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> > virtio_net_stats_tx_basic & \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> > virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> > virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > > +
> > VIRTIO_NET_F_HOST_TSO6 or\newline
> > > +
> > VIRTIO_NET_F_HOST_USO or\newline
> > > +
> > VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> > virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > > + \hline
> > > +\end{tabular}
> > > +
> > > +
> > > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> > Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > > +
> > > +The structure corresponding to the controlq stats is
> > virtio_net_stats_cvq.
> > > +
> > > +\begin{description}
> > > + \item [command_num]
> > > + The number of commands, including the current command.
> > > +
> > > + \item [ok_num]
> > > + The number of commands (including the current command) where
> > the ack was VIRTIO_NET_OK.
> > > +\end{description}
> > > +
> > > +
> > > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > Basic Stats}
> > > +
> > > +The structure corresponding to the receiveq basic stats is
> > virtio_net_stats_rx_basic.
> > > +
> > > +Receiveq basic stats doesn't need any features, as long as the device
> > supports
> > > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > > +
> > > +\begin{description}
> > > + \item [rx_packets]
> > > + The number of packets received by device (not the packets
> > passed to the
> > > + guest), including the dropped packets by device.
> > > +
> > > + \item [rx_bytes]
> > > + The number of bytes received by device (not the packets passed
> > to the
> > > + guest), including the dropped packets by device.
> > > +
> > > + \item [rx_notification]
> > > + The number of driver notifications.
> > > +
> > > + \item [rx_interrupt]
> > > + The number of device interrupts.
> > > +
> > > + \item [rx_drop]
> > > + The number of packets dropped by the receiveq. Contains all
> > kinds of
> > > + packet drop.
> > > +
> > > + \item [rx_drop_overruns]
> > > + The number of packets dropped by the receiveq when no more
> > descriptors
> > > + were available.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > Basic Stats}
> > > +
> > > +The structure corresponding to the transmitq basic stats is
> > virtio_net_stats_tx_basic.
> > > +
> > > +Transmitq basic stats doesn't need any features, as long as the device
> > supports
> > > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > > +
> > > +\begin{description}
> > > + \item [tx_packets]
> > > + The number of packets sent by device (not the packets got from
> > the
> > > + guest), excluding the dropped packets by device.
> > > +
> > > + \item [tx_bytes]
> > > + The number of bytes sent by device (not the packets got from the
> > > + guest), excluding the dropped packets by device.
> > > +
> > > + \item [tx_notification]
> > > + The number of driver notifications.
> > > +
> > > + \item [tx_interrupt]
> > > + The number of device interrupts.
> > > +
> > > + \item [tx_drop]
> > > + The number of packets dropped by the transmitq. Contains all
> > kinds of
> > > + packet drop.
> > > +
> > > + \item [tx_drop_malformed]
> > > + The number of packets dropped when the descriptor is in an
> > error state.
> > > + For example, the buffer is too short.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > CSUM Stats}
> > > +
> > > +The structure corresponding to the receiveq csum stats is
> > virtio_net_stats_rx_csum.
> > > +
> > > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> > receiveq
> > > +csum stats can be obtained.
> > > +
> > > +The following are the receiveq csum stats:
> > > +
> > > +\begin{description}
> > > + \item [rx_csum_valid]
> > > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > > +
> > > + \item [rx_needs_csum]
> > > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > > +
> > > + \item [rx_csum_bad]
> > > + The number of packets with abnormal csum.
> > > +
> > > + \item [rx_csum_none]
> > > + The number of packets without hardware csum. The packet here
> > refers to
> > > + the non-TCP/UDP packet that the backend cannot recognize.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > CSUM Stats}
> > > +
> > > +The structure corresponding to the transmitq csum stats is
> > virtio_net_stats_tx_csum.
> > > +
> > > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> > transmitq csum
> > > +stats can be obtained.
> > > +
> > > +The following are the transmitq csum stats:
> > > +
> > > +\begin{description}
> > > + \item [tx_csum_none]
> > > + The number of packets that didn't require hardware csum.
> > > +
> > > + \item [tx_needs_csum]
> > > + The number of packets that required hardware csum.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> > Stats}
> > > +
> > > +The structure corresponding to the receiveq gso stats is
> > virtio_net_stats_rx_gso.
> > > +
> > > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > > +been negotiated, the receiveq gso stats can be obtained.
> > > +
> > > +Rx gso packets refer to packets passed by the device to the driver where
> > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > +
> > > +\begin{description}
> > > + \item [rx_gso_packets]
> > > + The number of the rx gso packets.
> > > +
> > > + \item [rx_gso_bytes]
> > > + The number of bytes(excluding the virtio net header) of the rx
> > gso packets.
> > > +
> > > + \item [rx_gso_packets_coalesced]
> > > + The number of the rx gso packages generated by coalescing.
> > > +
> > > + \item [rx_gso_bytes_coalesced]
> > > + The number of bytes(excluding the virtio net header) of the rx
> > gso packets generated by coalescing.
> > > +
> > > + \item [rx_gso_segments]
> > > + The number of coalesced segments.
> > > +
> > > + \item [rx_gso_segments_bytes]
> > > + The number of bytes of coalesced segments.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > GSO Stats}
> > > +
> > > +The structure corresponding to the transmitq gso stats is
> > virtio_net_stats_tx_gso.
> > > +
> > > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > > +been negotiated, the transmitq gso stats can be obtained.
> > > +
> > > +Tx gso packets refer to packets passed by the driver to the device where
> > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > +
> > > +\begin{description}
> > > + \item [tx_gso_packets]
> > > + The number of the tx gso packets.
> > > +
> > > + \item [tx_gso_bytes]
> > > + The number of bytes(excluding the virtio net header) of the tx
> > gso packets.
> > > +
> > > + \item [tx_gso_packets_split]
> > > + The number of the tx gso packets that been split.
> > > +
> > > + \item [tx_gso_bytes_split]
> > > + The number of bytes(excluding the virtio net header) of the tx
> > gso packets that been split.
> > > +
> > > + \item [tx_gso_segments]
> > > + The number of segments split from the gso package.
> > > +
> > > + \item [tx_gso_segments_bytes]
> > > + The number of bytes(excluding the virtio net header) of
> > segments split from the gso package.
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > Reset Stats}
> > > +
> > > +The structure corresponding to the receiveq reset stats is
> > virtio_net_stats_rx_reset.
> > > +
> > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> > reset stats
> > > +can be obtained.
> > > +
> > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > Virtqueue Reset}
> > > +for more about \field{rx_reset}.
> > > +
> > > +\begin{description}
> > > + \item [rx_reset]
> > > + The number of receiveq resets.
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > Reset Stats}
> > > +
> > > +The structure corresponding to the transmitq reset stats is
> > virtio_net_stats_tx_reset.
> > > +
> > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> > reset stats
> > > +can be obtained.
> > > +
> > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > Virtqueue Reset}
> > > +for more about \field{tx_reset}.
> > > +
> > > +\begin{description}
> > > + \item [tx_reset]
> > > + The number of transmitq resets.
> > > +\end{description}
> > > +
> > > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> > the device
> > > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > > +the device MUST abort the entire command.
> > > +\begin{itemize}
> > > + \item \field{queue_num} exceeds the queue range.
> > > + \item \field{type} is not a known value.
> > > + \item The type of vq does not match \field{type}. E.g. the driver
> > tries to query
> > > + RX stats through a TX index.
> > > + \item The feature corresponding to the specified \field{type} was
> > not successfully
> > > + negotiated.
> > > + \item The size of the buffer allocated by the driver for
> > \field{command-specific-data-reply}
> > > + is less than the total size of the stats specialed by
> > > + \field{virtio_net_ctrl_queue_stats}.
> > > +\end{itemize}
> > > +
> > > +The device MUST write the requested stats structures in
> > > +\field{command-specific-data-reply} in the order specified by the
> > structure
> > > +virtio_net_ctrl_queue_stats.
> > > +
> > > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +When a driver tries to obtain a certain stats, it MUST confirm that the
> > relevant
> > > +feature negotiation is successful.
> > > +
> > > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> > the vq
> > > +specified by \field{queue_num}.
> > > +
> > > +The \field{command-specific-data-reply} buffer allocated by the driver
> > MUST be
> > > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > > +
> > > +When the driver reads the response, it MUST read
> > > +\field{command-specific-data-reply} one by one based on the
> > \field{type}.
> > >
> > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > Types / Network Device / Legacy Interface: Framing Requirements}
> > > --
> > > 2.31.0
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-comment] Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
@ 2023-07-12 9:11 ` Xuan Zhuo
0 siblings, 0 replies; 21+ messages in thread
From: Xuan Zhuo @ 2023-07-12 9:11 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
On Wed, 12 Jul 2023 16:08:48 +0800, Jason Wang <jasowang@redhat.com> wrote:
> On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> wrote:
>
> > hi, guys
> >
> > After a lot of internal discussions, I removed some unimportant counters.
> > Based
> > on this v12 patch I am repling to, most of the requirements have been met.
> >
> > The patch link
> > https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
> >
> > We still have these counters, let's see if they can be standardized.
> >
> > ## limit
> >
> > * tx_bps_limit_drops
> > * tx_pps_limit_drops
> > * rx_bps_limit_drops
> > * rx_pps_limit_drops
> >
> > In a cloud scenario, multiple users purchase different VMs, and these VMs
> > share
> > the capabilities of the same host. In order to ensure that each VM will not
> > affect others, the network card(virtio-net) capability of each VM is
> > limited.
> > These users purchase VMs, this limit has already been determined.
> >
>
> This seems a feature beyond the counters but QOS. I think we virtio spec
> need to support QOS before we can discuss any QOS related counters.
>
>
> >
> > So if the network card traffic of a vm exceeds the upper limit, packet
> > loss will
> > occur. It is necessary for us to count these packet losses. And the device
> > should expose to the user.
> >
> > ## session
> >
> > * tx_session_full_drops The number of packet drops in the sending
> > direction when
> > the session is full
> > * rx_session_full_drops The number of packets lost when the session is
> > full in the receiving direction
> >
> > Our dpu supports tcp connection tracking, but there is an upper limit to
> > the
> > number of connections, and if it exceeds, packet loss will also occur.
> >
>
> Similarly, if connect tracking offload is supported, it needs to be
> implemented in the spec first then we can have related counters.
>
>
> >
> > ## ACL
> >
> > * tx_acl_drops ACL packet loss in the sending direction
> > * rx_acl_drops The number of ACL packets lost in the receiving direction
> >
> > In our cloud service, for network cards, users are allowed to configure
> > security
> > rules,such as which IPs can access which ports of this machine.
> >
>
> Same as above, ACL should be supported by the spec first then the counters.
>
> In conclusion, the features must be self contained. Otherwise you are doing
> vDPA actually and those counters need to be accessed in a vendor specific
> way.
Yes that's the point, as we've discussed here.
http://lore.kernel.org/all/1686550355.2503424-1-xuanzhuo@linux.alibaba.com
There are many similar counters. There may not be many usage scenarios, so I
didn't list them here.
Our acl, seesion, and limit are not configured by the user at the driver layer,
and I don't think these should be configured at the driver. So at least as
far as our usage scenarios are concerned, these are some functions that have
nothing to do with virtio spec.
So what I want most is that the virto spec supports a vendor channel.
Of course, I am ok with Parav's abstraction of "limit".
Some implementations of txq are lossy and some are not creating backpressure/flow control to driver so driver can rate limit it naturally.
So a tx packet drop counter is needed to cover the lossy implementations which is abstract enough regardless of reason on why device dropped it.
A more granular counter becomes vendor specific that we can possibly avoid or place under different command.
But acl and session may not be very good to abstract.
Thanks.
>
> Thanks
>
>
> >
> >
> > Thanks
> >
> >
> > On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > wrote:
> > > This patch allows the driver to obtain some statistics from the device.
> > >
> > > In the back-end implementation, we can count a lot of such information,
> > > which can be used for debugging and judging the running status of the
> > > back-end. We hope to directly display it to the user through ethtool.
> > >
> > > To get stats atomically, try to get stats for all queue pairs in one
> > > command.
> > >
> > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > > conformance.tex | 2 +
> > > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 405 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/conformance.tex b/conformance.tex
> > > index 42f8537..c67f877 100644
> > > --- a/conformance.tex
> > > +++ b/conformance.tex
> > > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > / Conformance Targets}
> > > \item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > mode}
> > > \item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Offloads State Configuration / Setting
> > Offloads State}
> > > \item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > +\item \ref{drivernormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Device Stats}
> > > \end{itemize}
> > >
> > > \conformance{\subsection}{Block Driver
> > Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> > Conformance}
> > > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > / Conformance Targets}
> > > \item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > \item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > mode}
> > > \item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > > +\item \ref{devicenormative:Device Types / Network Device / Device
> > Operation / Control Virtqueue / Device Stats}
> > > \end{itemize}
> > >
> > > \conformance{\subsection}{Block Device
> > Conformance}\label{sec:Conformance / Device Conformance / Block Device
> > Conformance}
> > > diff --git a/content.tex b/content.tex
> > > index c6f116c..81f325d 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> > Network Device / Feature bits
> > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > > channel.
> > >
> > > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> > statistics
> > > + to the driver through the control channel.
> > > +
> > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> > Unlike UFO
> > > (fragmenting the packet) the USO splits large UDP packet
> > > to several segments when each of these smaller packets has UDP header.
> > > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> > requirements}\label{sec:Device Types / Network Device
> > > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> > VIRTIO_NET_F_HOST_TSO6.
> > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \end{description}
> > > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > Types / Network Device / Devi
> > > u8 command;
> > > u8 command-specific-data[];
> > > u8 ack;
> > > + u8 command-specific-data-reply[];
> > > };
> > >
> > > /* ack values */
> > > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > \end{lstlisting}
> > >
> > > The \field{class}, \field{command} and command-specific-data are set by
> > the
> > > -driver, and the device sets the \field{ack} byte. There is little it can
> > > -do except issue a diagnostic if \field{ack} is not
> > > -VIRTIO_NET_OK.
> > > +driver, and the device sets the \field{ack} byte and optionally
> > > +\field{command-specific-data-reply}. There is little the driver can
> > > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > > +
> > > +The command VIRTIO_NET_CTRL_STATS_GET contains
> > \field{command-specific-data-reply}.
> > >
> > > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > > \label{sec:Device Types / Network Device / Device Operation / Control
> > Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > according to the native endian of the guest rather than
> > > (necessarily when not using the legacy interface) little-endian.
> > >
> > > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> > Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > > +get the device stats from the device in
> > \field{command-specific-data-reply}.
> > > +
> > > +To get the stats, the following definitions are used:
> > > +\begin{lstlisting}
> > > +#define VIRTIO_NET_CTRL_STATS 6
> > > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > > +
> > > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > > +
> > > +\end{lstlisting}
> > > +
> > > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> > \field{command-specific-data}
> > > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > > +The result is returned by \field{command-specific-data-reply}.
> > > +The stats ware returned in the order of the type specified in the
> > > +\field{virtio_net_ctrl_queue_stats}.
> > > +
> > > +The following layout structures are used:
> > > +
> > > +\field{command-specific-data}
> > > +\begin{lstlisting}
> > > +struct virtio_net_ctrl_queue_stats {
> > > + u16 nstats;
> > > + struct {
> > > + u16 queue_num;
> > > + u16 type;
> > > + } stats[];
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\field{command-specific-data-reply}
> > > +\begin{lstlisting}
> > > +struct virtio_net_stats_cvq {
> > > + le64 command_num;
> > > + le64 ok_num;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_basic {
> > > + le64 rx_packets;
> > > + le64 rx_bytes;
> > > +
> > > + le64 rx_notification;
> > > + le64 rx_interrupt;
> > > +
> > > + le64 rx_drop;
> > > + le64 rx_drop_overruns;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_csum {
> > > + le64 rx_csum_valid;
> > > + le64 rx_needs_csum;
> > > + le64 rx_csum_bad;
> > > + le64 rx_csum_none;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_gso {
> > > + le64 rx_gso_packets;
> > > + le64 rx_gso_bytes;
> > > + le64 rx_gso_packets_coalesced;
> > > + le64 rx_gso_bytes_coalesced;
> > > + le64 rx_gso_segments;
> > > + le64 rx_gso_segments_bytes;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_reset {
> > > + le64 rx_reset;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_basic {
> > > + le64 tx_packets;
> > > + le64 tx_bytes;
> > > +
> > > + le64 tx_notification;
> > > + le64 tx_interrupt;
> > > +
> > > + le64 tx_drop;
> > > + le64 tx_drop_malformed;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_csum {
> > > + le64 tx_csum_none;
> > > + le64 tx_needs_csum;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_gso {
> > > + le64 tx_gso_packets;
> > > + le64 tx_gso_bytes;
> > > + le64 tx_gso_packets_split;
> > > + le64 tx_gso_bytes_split;
> > > + le64 tx_gso_segments;
> > > + le64 tx_gso_segments_bytes;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_reset {
> > > + le64 tx_reset;
> > > +};
> > > +
> > > +\end{lstlisting}
> > > +
> > > +\begin{description}
> > > + \item [nstats]
> > > + The number of \field{stats}.
> > > +
> > > + \item [queue_num]
> > > + The number of the virtqueue to obtain the statistics.
> > > +
> > > + \item [type]
> > > + The type of the stats to be obtained.
> > > +
> > > +\end{description}
> > > +
> > > +Correspondence between the vq type, the stats type, the stats structure
> > and the
> > > +required features.
> > > +\begin{tabular}{ |l|l|l|l| }
> > > + \hline
> > > + VQ Type & Stats Type & Stats
> > Structure & Features \\ \hline
> > > +
> > > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> > virtio_net_stats_cvq & \\ \hline
> > > +
> > > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> > virtio_net_stats_rx_basic & \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> > virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> > virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > > +
> > VIRTIO_NET_F_GUEST_TSO6 or\newline
> > > +
> > VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> > virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > > +
> > > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> > virtio_net_stats_tx_basic & \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> > virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> > virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > > +
> > VIRTIO_NET_F_HOST_TSO6 or\newline
> > > +
> > VIRTIO_NET_F_HOST_USO or\newline
> > > +
> > VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> > virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > > + \hline
> > > +\end{tabular}
> > > +
> > > +
> > > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> > Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > > +
> > > +The structure corresponding to the controlq stats is
> > virtio_net_stats_cvq.
> > > +
> > > +\begin{description}
> > > + \item [command_num]
> > > + The number of commands, including the current command.
> > > +
> > > + \item [ok_num]
> > > + The number of commands (including the current command) where
> > the ack was VIRTIO_NET_OK.
> > > +\end{description}
> > > +
> > > +
> > > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > Basic Stats}
> > > +
> > > +The structure corresponding to the receiveq basic stats is
> > virtio_net_stats_rx_basic.
> > > +
> > > +Receiveq basic stats doesn't need any features, as long as the device
> > supports
> > > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > > +
> > > +\begin{description}
> > > + \item [rx_packets]
> > > + The number of packets received by device (not the packets
> > passed to the
> > > + guest), including the dropped packets by device.
> > > +
> > > + \item [rx_bytes]
> > > + The number of bytes received by device (not the packets passed
> > to the
> > > + guest), including the dropped packets by device.
> > > +
> > > + \item [rx_notification]
> > > + The number of driver notifications.
> > > +
> > > + \item [rx_interrupt]
> > > + The number of device interrupts.
> > > +
> > > + \item [rx_drop]
> > > + The number of packets dropped by the receiveq. Contains all
> > kinds of
> > > + packet drop.
> > > +
> > > + \item [rx_drop_overruns]
> > > + The number of packets dropped by the receiveq when no more
> > descriptors
> > > + were available.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > Basic Stats}
> > > +
> > > +The structure corresponding to the transmitq basic stats is
> > virtio_net_stats_tx_basic.
> > > +
> > > +Transmitq basic stats doesn't need any features, as long as the device
> > supports
> > > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > > +
> > > +\begin{description}
> > > + \item [tx_packets]
> > > + The number of packets sent by device (not the packets got from
> > the
> > > + guest), excluding the dropped packets by device.
> > > +
> > > + \item [tx_bytes]
> > > + The number of bytes sent by device (not the packets got from the
> > > + guest), excluding the dropped packets by device.
> > > +
> > > + \item [tx_notification]
> > > + The number of driver notifications.
> > > +
> > > + \item [tx_interrupt]
> > > + The number of device interrupts.
> > > +
> > > + \item [tx_drop]
> > > + The number of packets dropped by the transmitq. Contains all
> > kinds of
> > > + packet drop.
> > > +
> > > + \item [tx_drop_malformed]
> > > + The number of packets dropped when the descriptor is in an
> > error state.
> > > + For example, the buffer is too short.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > CSUM Stats}
> > > +
> > > +The structure corresponding to the receiveq csum stats is
> > virtio_net_stats_rx_csum.
> > > +
> > > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> > receiveq
> > > +csum stats can be obtained.
> > > +
> > > +The following are the receiveq csum stats:
> > > +
> > > +\begin{description}
> > > + \item [rx_csum_valid]
> > > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > > +
> > > + \item [rx_needs_csum]
> > > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > > +
> > > + \item [rx_csum_bad]
> > > + The number of packets with abnormal csum.
> > > +
> > > + \item [rx_csum_none]
> > > + The number of packets without hardware csum. The packet here
> > refers to
> > > + the non-TCP/UDP packet that the backend cannot recognize.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > CSUM Stats}
> > > +
> > > +The structure corresponding to the transmitq csum stats is
> > virtio_net_stats_tx_csum.
> > > +
> > > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> > transmitq csum
> > > +stats can be obtained.
> > > +
> > > +The following are the transmitq csum stats:
> > > +
> > > +\begin{description}
> > > + \item [tx_csum_none]
> > > + The number of packets that didn't require hardware csum.
> > > +
> > > + \item [tx_needs_csum]
> > > + The number of packets that required hardware csum.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> > Stats}
> > > +
> > > +The structure corresponding to the receiveq gso stats is
> > virtio_net_stats_rx_gso.
> > > +
> > > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > > +been negotiated, the receiveq gso stats can be obtained.
> > > +
> > > +Rx gso packets refer to packets passed by the device to the driver where
> > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > +
> > > +\begin{description}
> > > + \item [rx_gso_packets]
> > > + The number of the rx gso packets.
> > > +
> > > + \item [rx_gso_bytes]
> > > + The number of bytes(excluding the virtio net header) of the rx
> > gso packets.
> > > +
> > > + \item [rx_gso_packets_coalesced]
> > > + The number of the rx gso packages generated by coalescing.
> > > +
> > > + \item [rx_gso_bytes_coalesced]
> > > + The number of bytes(excluding the virtio net header) of the rx
> > gso packets generated by coalescing.
> > > +
> > > + \item [rx_gso_segments]
> > > + The number of coalesced segments.
> > > +
> > > + \item [rx_gso_segments_bytes]
> > > + The number of bytes of coalesced segments.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > GSO Stats}
> > > +
> > > +The structure corresponding to the transmitq gso stats is
> > virtio_net_stats_tx_gso.
> > > +
> > > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > > +been negotiated, the transmitq gso stats can be obtained.
> > > +
> > > +Tx gso packets refer to packets passed by the driver to the device where
> > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > +
> > > +\begin{description}
> > > + \item [tx_gso_packets]
> > > + The number of the tx gso packets.
> > > +
> > > + \item [tx_gso_bytes]
> > > + The number of bytes(excluding the virtio net header) of the tx
> > gso packets.
> > > +
> > > + \item [tx_gso_packets_split]
> > > + The number of the tx gso packets that been split.
> > > +
> > > + \item [tx_gso_bytes_split]
> > > + The number of bytes(excluding the virtio net header) of the tx
> > gso packets that been split.
> > > +
> > > + \item [tx_gso_segments]
> > > + The number of segments split from the gso package.
> > > +
> > > + \item [tx_gso_segments_bytes]
> > > + The number of bytes(excluding the virtio net header) of
> > segments split from the gso package.
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > Reset Stats}
> > > +
> > > +The structure corresponding to the receiveq reset stats is
> > virtio_net_stats_rx_reset.
> > > +
> > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> > reset stats
> > > +can be obtained.
> > > +
> > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > Virtqueue Reset}
> > > +for more about \field{rx_reset}.
> > > +
> > > +\begin{description}
> > > + \item [rx_reset]
> > > + The number of receiveq resets.
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > Reset Stats}
> > > +
> > > +The structure corresponding to the transmitq reset stats is
> > virtio_net_stats_tx_reset.
> > > +
> > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> > reset stats
> > > +can be obtained.
> > > +
> > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > Virtqueue Reset}
> > > +for more about \field{tx_reset}.
> > > +
> > > +\begin{description}
> > > + \item [tx_reset]
> > > + The number of transmitq resets.
> > > +\end{description}
> > > +
> > > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> > the device
> > > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > > +the device MUST abort the entire command.
> > > +\begin{itemize}
> > > + \item \field{queue_num} exceeds the queue range.
> > > + \item \field{type} is not a known value.
> > > + \item The type of vq does not match \field{type}. E.g. the driver
> > tries to query
> > > + RX stats through a TX index.
> > > + \item The feature corresponding to the specified \field{type} was
> > not successfully
> > > + negotiated.
> > > + \item The size of the buffer allocated by the driver for
> > \field{command-specific-data-reply}
> > > + is less than the total size of the stats specialed by
> > > + \field{virtio_net_ctrl_queue_stats}.
> > > +\end{itemize}
> > > +
> > > +The device MUST write the requested stats structures in
> > > +\field{command-specific-data-reply} in the order specified by the
> > structure
> > > +virtio_net_ctrl_queue_stats.
> > > +
> > > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> > Device / Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +When a driver tries to obtain a certain stats, it MUST confirm that the
> > relevant
> > > +feature negotiation is successful.
> > > +
> > > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> > the vq
> > > +specified by \field{queue_num}.
> > > +
> > > +The \field{command-specific-data-reply} buffer allocated by the driver
> > MUST be
> > > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > > +
> > > +When the driver reads the response, it MUST read
> > > +\field{command-specific-data-reply} one by one based on the
> > \field{type}.
> > >
> > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > Types / Network Device / Legacy Interface: Framing Requirements}
> > > --
> > > 2.31.0
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > >
> >
> >
>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
2022-03-15 3:24 [virtio-dev] [PATCH v12] virtio-net: support device stats Xuan Zhuo
2022-03-22 7:57 ` [virtio-dev] " Jason Wang
2023-07-10 7:28 ` [virtio-comment] " Xuan Zhuo
@ 2023-07-12 11:34 ` Michael S. Tsirkin
2023-07-12 11:44 ` Xuan Zhuo
2 siblings, 1 reply; 21+ messages in thread
From: Michael S. Tsirkin @ 2023-07-12 11:34 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: virtio-dev, jasowang, Parav Pandit
On Tue, Mar 15, 2022 at 11:24:02AM +0800, Xuan Zhuo wrote:
> This patch allows the driver to obtain some statistics from the device.
>
> In the back-end implementation, we can count a lot of such information,
> which can be used for debugging and judging the running status of the
> back-end. We hope to directly display it to the user through ethtool.
>
> To get stats atomically, try to get stats for all queue pairs in one
> command.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Functionally, I think this is close to ok now. But the text needs
of work. Are you trying to target 1.3 with this?
Feedback from other hw vendors would be nice. Parav could you take
a look and say whether the list of counters seems rich enough for
you? Any counters you'd like to add?
> ---
> conformance.tex | 2 +
> content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 405 insertions(+), 3 deletions(-)
>
> diff --git a/conformance.tex b/conformance.tex
> index 42f8537..c67f877 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
> +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance}
> @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> \end{itemize}
>
> \conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance}
> diff --git a/content.tex b/content.tex
> index c6f116c..81f325d 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> channel.
>
> +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level statistics
> + to the driver through the control channel.
> +
> \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO
> (fragmenting the packet) the USO splits large UDP packet
> to several segments when each of these smaller packets has UDP header.
> @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
> \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6.
> \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> \end{description}
> @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> u8 command;
> u8 command-specific-data[];
> u8 ack;
> + u8 command-specific-data-reply[];
> };
>
> /* ack values */
> @@ -4023,9 +4028,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \end{lstlisting}
>
> The \field{class}, \field{command} and command-specific-data are set by the
> -driver, and the device sets the \field{ack} byte. There is little it can
> -do except issue a diagnostic if \field{ack} is not
> -VIRTIO_NET_OK.
> +driver, and the device sets the \field{ack} byte and optionally
> +\field{command-specific-data-reply}. There is little the driver can
> +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> +
> +The command VIRTIO_NET_CTRL_STATS_GET contains \field{command-specific-data-reply}.
>
> \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> \label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> @@ -4471,6 +4478,399 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> according to the native endian of the guest rather than
> (necessarily when not using the legacy interface) little-endian.
>
> +\paragraph{Device Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> +get the device stats from the device in \field{command-specific-data-reply}.
> +
> +To get the stats, the following definitions are used:
> +\begin{lstlisting}
> +#define VIRTIO_NET_CTRL_STATS 6
> +#define VIRTIO_NET_CTRL_STATS_GET 0
> +
> +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> +
> +\end{lstlisting}
> +
> +Use the command VIRTIO_NET_CTRL_STATS_GET and \field{command-specific-data}
> +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> +The result is returned by \field{command-specific-data-reply}.
> +The stats ware returned in the order of the type specified in the
> +\field{virtio_net_ctrl_queue_stats}.
> +
> +The following layout structures are used:
> +
> +\field{command-specific-data}
> +\begin{lstlisting}
> +struct virtio_net_ctrl_queue_stats {
> + u16 nstats;
> + struct {
> + u16 queue_num;
> + u16 type;
> + } stats[];
> +};
> +\end{lstlisting}
> +
> +\field{command-specific-data-reply}
> +\begin{lstlisting}
> +struct virtio_net_stats_cvq {
> + le64 command_num;
> + le64 ok_num;
> +};
> +
> +struct virtio_net_stats_rx_basic {
> + le64 rx_packets;
> + le64 rx_bytes;
> +
> + le64 rx_notification;
> + le64 rx_interrupt;
> +
> + le64 rx_drop;
> + le64 rx_drop_overruns;
> +};
> +
> +struct virtio_net_stats_rx_csum {
> + le64 rx_csum_valid;
> + le64 rx_needs_csum;
> + le64 rx_csum_bad;
> + le64 rx_csum_none;
> +};
> +
> +struct virtio_net_stats_rx_gso {
> + le64 rx_gso_packets;
> + le64 rx_gso_bytes;
> + le64 rx_gso_packets_coalesced;
> + le64 rx_gso_bytes_coalesced;
> + le64 rx_gso_segments;
> + le64 rx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_rx_reset {
> + le64 rx_reset;
> +};
> +
> +struct virtio_net_stats_tx_basic {
> + le64 tx_packets;
> + le64 tx_bytes;
> +
> + le64 tx_notification;
> + le64 tx_interrupt;
> +
> + le64 tx_drop;
> + le64 tx_drop_malformed;
> +};
> +
> +struct virtio_net_stats_tx_csum {
> + le64 tx_csum_none;
> + le64 tx_needs_csum;
> +};
> +
> +struct virtio_net_stats_tx_gso {
> + le64 tx_gso_packets;
> + le64 tx_gso_bytes;
> + le64 tx_gso_packets_split;
> + le64 tx_gso_bytes_split;
> + le64 tx_gso_segments;
> + le64 tx_gso_segments_bytes;
> +};
> +
> +struct virtio_net_stats_tx_reset {
> + le64 tx_reset;
> +};
> +
> +\end{lstlisting}
> +
> +\begin{description}
> + \item [nstats]
> + The number of \field{stats}.
> +
> + \item [queue_num]
> + The number of the virtqueue to obtain the statistics.
> +
> + \item [type]
> + The type of the stats to be obtained.
> +
> +\end{description}
> +
> +Correspondence between the vq type, the stats type, the stats structure and the
> +required features.
> +\begin{tabular}{ |l|l|l|l| }
> + \hline
> + VQ Type & Stats Type & Stats Structure & Features \\ \hline
> +
> + controlq & VIRTIO_NET_STATS_TYPE_CVQ & virtio_net_stats_cvq & \\ \hline
> +
> + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC & virtio_net_stats_rx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_CSUM & virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_GSO & virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> + VIRTIO_NET_F_GUEST_TSO6 or\newline
> + VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_RX_RESET & virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> +
> + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC & virtio_net_stats_tx_basic & \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_CSUM & virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_GSO & virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> + VIRTIO_NET_F_HOST_TSO6 or\newline
> + VIRTIO_NET_F_HOST_USO or\newline
> + VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> + & VIRTIO_NET_STATS_TYPE_TX_RESET & virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> + \hline
> +\end{tabular}
> +
> +
> +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> +
> +The structure corresponding to the controlq stats is virtio_net_stats_cvq.
> +
> +\begin{description}
> + \item [command_num]
> + The number of commands, including the current command.
> +
> + \item [ok_num]
> + The number of commands (including the current command) where the ack was VIRTIO_NET_OK.
> +\end{description}
> +
> +
> +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Basic Stats}
> +
> +The structure corresponding to the receiveq basic stats is virtio_net_stats_rx_basic.
> +
> +Receiveq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> +
> +\begin{description}
> + \item [rx_packets]
> + The number of packets received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_bytes]
> + The number of bytes received by device (not the packets passed to the
> + guest), including the dropped packets by device.
> +
> + \item [rx_notification]
> + The number of driver notifications.
> +
> + \item [rx_interrupt]
> + The number of device interrupts.
> +
> + \item [rx_drop]
> + The number of packets dropped by the receiveq. Contains all kinds of
> + packet drop.
> +
> + \item [rx_drop_overruns]
> + The number of packets dropped by the receiveq when no more descriptors
> + were available.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Basic Stats}
> +
> +The structure corresponding to the transmitq basic stats is virtio_net_stats_tx_basic.
> +
> +Transmitq basic stats doesn't need any features, as long as the device supports
> +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> +
> +\begin{description}
> + \item [tx_packets]
> + The number of packets sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
> +
> + \item [tx_bytes]
> + The number of bytes sent by device (not the packets got from the
> + guest), excluding the dropped packets by device.
> +
> + \item [tx_notification]
> + The number of driver notifications.
> +
> + \item [tx_interrupt]
> + The number of device interrupts.
> +
> + \item [tx_drop]
> + The number of packets dropped by the transmitq. Contains all kinds of
> + packet drop.
> +
> + \item [tx_drop_malformed]
> + The number of packets dropped when the descriptor is in an error state.
> + For example, the buffer is too short.
> +
> +\end{description}
> +
> +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq CSUM Stats}
> +
> +The structure corresponding to the receiveq csum stats is virtio_net_stats_rx_csum.
> +
> +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the receiveq
> +csum stats can be obtained.
> +
> +The following are the receiveq csum stats:
> +
> +\begin{description}
> + \item [rx_csum_valid]
> + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> +
> + \item [rx_needs_csum]
> + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> +
> + \item [rx_csum_bad]
> + The number of packets with abnormal csum.
> +
> + \item [rx_csum_none]
> + The number of packets without hardware csum. The packet here refers to
> + the non-TCP/UDP packet that the backend cannot recognize.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq CSUM Stats}
> +
> +The structure corresponding to the transmitq csum stats is virtio_net_stats_tx_csum.
> +
> +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the transmitq csum
> +stats can be obtained.
> +
> +The following are the transmitq csum stats:
> +
> +\begin{description}
> + \item [tx_csum_none]
> + The number of packets that didn't require hardware csum.
> +
> + \item [tx_needs_csum]
> + The number of packets that required hardware csum.
> +
> +\end{description}
> +
> +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO Stats}
> +
> +The structure corresponding to the receiveq gso stats is virtio_net_stats_rx_gso.
> +
> +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> +been negotiated, the receiveq gso stats can be obtained.
> +
> +Rx gso packets refer to packets passed by the device to the driver where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [rx_gso_packets]
> + The number of the rx gso packets.
> +
> + \item [rx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the rx gso packets.
> +
> + \item [rx_gso_packets_coalesced]
> + The number of the rx gso packages generated by coalescing.
> +
> + \item [rx_gso_bytes_coalesced]
> + The number of bytes(excluding the virtio net header) of the rx gso packets generated by coalescing.
> +
> + \item [rx_gso_segments]
> + The number of coalesced segments.
> +
> + \item [rx_gso_segments_bytes]
> + The number of bytes of coalesced segments.
> +
> +\end{description}
> +
> +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq GSO Stats}
> +
> +The structure corresponding to the transmitq gso stats is virtio_net_stats_tx_gso.
> +
> +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> +been negotiated, the transmitq gso stats can be obtained.
> +
> +Tx gso packets refer to packets passed by the driver to the device where
> +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> +
> +\begin{description}
> + \item [tx_gso_packets]
> + The number of the tx gso packets.
> +
> + \item [tx_gso_bytes]
> + The number of bytes(excluding the virtio net header) of the tx gso packets.
> +
> + \item [tx_gso_packets_split]
> + The number of the tx gso packets that been split.
> +
> + \item [tx_gso_bytes_split]
> + The number of bytes(excluding the virtio net header) of the tx gso packets that been split.
> +
> + \item [tx_gso_segments]
> + The number of segments split from the gso package.
> +
> + \item [tx_gso_segments_bytes]
> + The number of bytes(excluding the virtio net header) of segments split from the gso package.
> +\end{description}
> +
> +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Reset Stats}
> +
> +The structure corresponding to the receiveq reset stats is virtio_net_stats_rx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq reset stats
> +can be obtained.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{rx_reset}.
> +
> +\begin{description}
> + \item [rx_reset]
> + The number of receiveq resets.
> +\end{description}
> +
> +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Reset Stats}
> +
> +The structure corresponding to the transmitq reset stats is virtio_net_stats_tx_reset.
> +
> +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq reset stats
> +can be obtained.
> +
> +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> +for more about \field{tx_reset}.
> +
> +\begin{description}
> + \item [tx_reset]
> + The number of transmitq resets.
> +\end{description}
> +
> +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +If virtio_net_ctrl_queue_stats is incorrect (such as the following), the device
> +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> +the device MUST abort the entire command.
> +\begin{itemize}
> + \item \field{queue_num} exceeds the queue range.
> + \item \field{type} is not a known value.
> + \item The type of vq does not match \field{type}. E.g. the driver tries to query
> + RX stats through a TX index.
> + \item The feature corresponding to the specified \field{type} was not successfully
> + negotiated.
> + \item The size of the buffer allocated by the driver for \field{command-specific-data-reply}
> + is less than the total size of the stats specialed by
> + \field{virtio_net_ctrl_queue_stats}.
> +\end{itemize}
> +
> +The device MUST write the requested stats structures in
> +\field{command-specific-data-reply} in the order specified by the structure
> +virtio_net_ctrl_queue_stats.
> +
> +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> +
> +When a driver tries to obtain a certain stats, it MUST confirm that the relevant
> +feature negotiation is successful.
> +
> +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to the vq
> +specified by \field{queue_num}.
> +
> +The \field{command-specific-data-reply} buffer allocated by the driver MUST be
> +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> +
> +When the driver reads the response, it MUST read
> +\field{command-specific-data-reply} one by one based on the \field{type}.
>
> \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> Types / Network Device / Legacy Interface: Framing Requirements}
> --
> 2.31.0
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
2023-07-12 11:34 ` [virtio-dev] " Michael S. Tsirkin
@ 2023-07-12 11:44 ` Xuan Zhuo
2023-07-12 11:54 ` Michael S. Tsirkin
0 siblings, 1 reply; 21+ messages in thread
From: Xuan Zhuo @ 2023-07-12 11:44 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtio-dev, jasowang, Parav Pandit
On Wed, 12 Jul 2023 07:34:38 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Mar 15, 2022 at 11:24:02AM +0800, Xuan Zhuo wrote:
> > This patch allows the driver to obtain some statistics from the device.
> >
> > In the back-end implementation, we can count a lot of such information,
> > which can be used for debugging and judging the running status of the
> > back-end. We hope to directly display it to the user through ethtool.
> >
> > To get stats atomically, try to get stats for all queue pairs in one
> > command.
> >
> > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
>
> Functionally, I think this is close to ok now. But the text needs
> of work. Are you trying to target 1.3 with this?
I personally worry about that 1.3 may be too late, if possible, I would like to
respond as soon as possible.
I really don't really care if it can get into 1.3 or not but I do hope that this
can be done as soon as possible.
Thanks.
>
> Feedback from other hw vendors would be nice. Parav could you take
> a look and say whether the list of counters seems rich enough for
> you? Any counters you'd like to add?
>
>
> > ---
> > conformance.tex | 2 +
> > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > 2 files changed, 405 insertions(+), 3 deletions(-)
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 42f8537..c67f877 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State}
> > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > \end{itemize}
> >
> > \conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance}
> > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > \end{itemize}
> >
> > \conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance}
> > diff --git a/content.tex b/content.tex
> > index c6f116c..81f325d 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
> > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > channel.
> >
> > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level statistics
> > + to the driver through the control channel.
> > +
> > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO
> > (fragmenting the packet) the USO splits large UDP packet
> > to several segments when each of these smaller packets has UDP header.
> > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
> > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6.
> > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > \end{description}
> > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > u8 command;
> > u8 command-specific-data[];
> > u8 ack;
> > + u8 command-specific-data-reply[];
> > };
> >
> > /* ack values */
> > @@ -4023,9 +4028,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > \end{lstlisting}
> >
> > The \field{class}, \field{command} and command-specific-data are set by the
> > -driver, and the device sets the \field{ack} byte. There is little it can
> > -do except issue a diagnostic if \field{ack} is not
> > -VIRTIO_NET_OK.
> > +driver, and the device sets the \field{ack} byte and optionally
> > +\field{command-specific-data-reply}. There is little the driver can
> > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > +
> > +The command VIRTIO_NET_CTRL_STATS_GET contains \field{command-specific-data-reply}.
> >
> > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > \label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > @@ -4471,6 +4478,399 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > according to the native endian of the guest rather than
> > (necessarily when not using the legacy interface) little-endian.
> >
> > +\paragraph{Device Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > +
> > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > +get the device stats from the device in \field{command-specific-data-reply}.
> > +
> > +To get the stats, the following definitions are used:
> > +\begin{lstlisting}
> > +#define VIRTIO_NET_CTRL_STATS 6
> > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > +
> > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > +
> > +\end{lstlisting}
> > +
> > +Use the command VIRTIO_NET_CTRL_STATS_GET and \field{command-specific-data}
> > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > +The result is returned by \field{command-specific-data-reply}.
> > +The stats ware returned in the order of the type specified in the
> > +\field{virtio_net_ctrl_queue_stats}.
> > +
> > +The following layout structures are used:
> > +
> > +\field{command-specific-data}
> > +\begin{lstlisting}
> > +struct virtio_net_ctrl_queue_stats {
> > + u16 nstats;
> > + struct {
> > + u16 queue_num;
> > + u16 type;
> > + } stats[];
> > +};
> > +\end{lstlisting}
> > +
> > +\field{command-specific-data-reply}
> > +\begin{lstlisting}
> > +struct virtio_net_stats_cvq {
> > + le64 command_num;
> > + le64 ok_num;
> > +};
> > +
> > +struct virtio_net_stats_rx_basic {
> > + le64 rx_packets;
> > + le64 rx_bytes;
> > +
> > + le64 rx_notification;
> > + le64 rx_interrupt;
> > +
> > + le64 rx_drop;
> > + le64 rx_drop_overruns;
> > +};
> > +
> > +struct virtio_net_stats_rx_csum {
> > + le64 rx_csum_valid;
> > + le64 rx_needs_csum;
> > + le64 rx_csum_bad;
> > + le64 rx_csum_none;
> > +};
> > +
> > +struct virtio_net_stats_rx_gso {
> > + le64 rx_gso_packets;
> > + le64 rx_gso_bytes;
> > + le64 rx_gso_packets_coalesced;
> > + le64 rx_gso_bytes_coalesced;
> > + le64 rx_gso_segments;
> > + le64 rx_gso_segments_bytes;
> > +};
> > +
> > +struct virtio_net_stats_rx_reset {
> > + le64 rx_reset;
> > +};
> > +
> > +struct virtio_net_stats_tx_basic {
> > + le64 tx_packets;
> > + le64 tx_bytes;
> > +
> > + le64 tx_notification;
> > + le64 tx_interrupt;
> > +
> > + le64 tx_drop;
> > + le64 tx_drop_malformed;
> > +};
> > +
> > +struct virtio_net_stats_tx_csum {
> > + le64 tx_csum_none;
> > + le64 tx_needs_csum;
> > +};
> > +
> > +struct virtio_net_stats_tx_gso {
> > + le64 tx_gso_packets;
> > + le64 tx_gso_bytes;
> > + le64 tx_gso_packets_split;
> > + le64 tx_gso_bytes_split;
> > + le64 tx_gso_segments;
> > + le64 tx_gso_segments_bytes;
> > +};
> > +
> > +struct virtio_net_stats_tx_reset {
> > + le64 tx_reset;
> > +};
> > +
> > +\end{lstlisting}
> > +
> > +\begin{description}
> > + \item [nstats]
> > + The number of \field{stats}.
> > +
> > + \item [queue_num]
> > + The number of the virtqueue to obtain the statistics.
> > +
> > + \item [type]
> > + The type of the stats to be obtained.
> > +
> > +\end{description}
> > +
> > +Correspondence between the vq type, the stats type, the stats structure and the
> > +required features.
> > +\begin{tabular}{ |l|l|l|l| }
> > + \hline
> > + VQ Type & Stats Type & Stats Structure & Features \\ \hline
> > +
> > + controlq & VIRTIO_NET_STATS_TYPE_CVQ & virtio_net_stats_cvq & \\ \hline
> > +
> > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC & virtio_net_stats_rx_basic & \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_CSUM & virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_GSO & virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > + VIRTIO_NET_F_GUEST_TSO6 or\newline
> > + VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_RX_RESET & virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > +
> > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC & virtio_net_stats_tx_basic & \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_CSUM & virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_GSO & virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > + VIRTIO_NET_F_HOST_TSO6 or\newline
> > + VIRTIO_NET_F_HOST_USO or\newline
> > + VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > + & VIRTIO_NET_STATS_TYPE_TX_RESET & virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > + \hline
> > +\end{tabular}
> > +
> > +
> > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > +
> > +The structure corresponding to the controlq stats is virtio_net_stats_cvq.
> > +
> > +\begin{description}
> > + \item [command_num]
> > + The number of commands, including the current command.
> > +
> > + \item [ok_num]
> > + The number of commands (including the current command) where the ack was VIRTIO_NET_OK.
> > +\end{description}
> > +
> > +
> > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Basic Stats}
> > +
> > +The structure corresponding to the receiveq basic stats is virtio_net_stats_rx_basic.
> > +
> > +Receiveq basic stats doesn't need any features, as long as the device supports
> > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > +
> > +\begin{description}
> > + \item [rx_packets]
> > + The number of packets received by device (not the packets passed to the
> > + guest), including the dropped packets by device.
> > +
> > + \item [rx_bytes]
> > + The number of bytes received by device (not the packets passed to the
> > + guest), including the dropped packets by device.
> > +
> > + \item [rx_notification]
> > + The number of driver notifications.
> > +
> > + \item [rx_interrupt]
> > + The number of device interrupts.
> > +
> > + \item [rx_drop]
> > + The number of packets dropped by the receiveq. Contains all kinds of
> > + packet drop.
> > +
> > + \item [rx_drop_overruns]
> > + The number of packets dropped by the receiveq when no more descriptors
> > + were available.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Basic Stats}
> > +
> > +The structure corresponding to the transmitq basic stats is virtio_net_stats_tx_basic.
> > +
> > +Transmitq basic stats doesn't need any features, as long as the device supports
> > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > +
> > +\begin{description}
> > + \item [tx_packets]
> > + The number of packets sent by device (not the packets got from the
> > + guest), excluding the dropped packets by device.
> > +
> > + \item [tx_bytes]
> > + The number of bytes sent by device (not the packets got from the
> > + guest), excluding the dropped packets by device.
> > +
> > + \item [tx_notification]
> > + The number of driver notifications.
> > +
> > + \item [tx_interrupt]
> > + The number of device interrupts.
> > +
> > + \item [tx_drop]
> > + The number of packets dropped by the transmitq. Contains all kinds of
> > + packet drop.
> > +
> > + \item [tx_drop_malformed]
> > + The number of packets dropped when the descriptor is in an error state.
> > + For example, the buffer is too short.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq CSUM Stats}
> > +
> > +The structure corresponding to the receiveq csum stats is virtio_net_stats_rx_csum.
> > +
> > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the receiveq
> > +csum stats can be obtained.
> > +
> > +The following are the receiveq csum stats:
> > +
> > +\begin{description}
> > + \item [rx_csum_valid]
> > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > +
> > + \item [rx_needs_csum]
> > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > +
> > + \item [rx_csum_bad]
> > + The number of packets with abnormal csum.
> > +
> > + \item [rx_csum_none]
> > + The number of packets without hardware csum. The packet here refers to
> > + the non-TCP/UDP packet that the backend cannot recognize.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq CSUM Stats}
> > +
> > +The structure corresponding to the transmitq csum stats is virtio_net_stats_tx_csum.
> > +
> > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the transmitq csum
> > +stats can be obtained.
> > +
> > +The following are the transmitq csum stats:
> > +
> > +\begin{description}
> > + \item [tx_csum_none]
> > + The number of packets that didn't require hardware csum.
> > +
> > + \item [tx_needs_csum]
> > + The number of packets that required hardware csum.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO Stats}
> > +
> > +The structure corresponding to the receiveq gso stats is virtio_net_stats_rx_gso.
> > +
> > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > +been negotiated, the receiveq gso stats can be obtained.
> > +
> > +Rx gso packets refer to packets passed by the device to the driver where
> > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > +
> > +\begin{description}
> > + \item [rx_gso_packets]
> > + The number of the rx gso packets.
> > +
> > + \item [rx_gso_bytes]
> > + The number of bytes(excluding the virtio net header) of the rx gso packets.
> > +
> > + \item [rx_gso_packets_coalesced]
> > + The number of the rx gso packages generated by coalescing.
> > +
> > + \item [rx_gso_bytes_coalesced]
> > + The number of bytes(excluding the virtio net header) of the rx gso packets generated by coalescing.
> > +
> > + \item [rx_gso_segments]
> > + The number of coalesced segments.
> > +
> > + \item [rx_gso_segments_bytes]
> > + The number of bytes of coalesced segments.
> > +
> > +\end{description}
> > +
> > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq GSO Stats}
> > +
> > +The structure corresponding to the transmitq gso stats is virtio_net_stats_tx_gso.
> > +
> > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > +been negotiated, the transmitq gso stats can be obtained.
> > +
> > +Tx gso packets refer to packets passed by the driver to the device where
> > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > +
> > +\begin{description}
> > + \item [tx_gso_packets]
> > + The number of the tx gso packets.
> > +
> > + \item [tx_gso_bytes]
> > + The number of bytes(excluding the virtio net header) of the tx gso packets.
> > +
> > + \item [tx_gso_packets_split]
> > + The number of the tx gso packets that been split.
> > +
> > + \item [tx_gso_bytes_split]
> > + The number of bytes(excluding the virtio net header) of the tx gso packets that been split.
> > +
> > + \item [tx_gso_segments]
> > + The number of segments split from the gso package.
> > +
> > + \item [tx_gso_segments_bytes]
> > + The number of bytes(excluding the virtio net header) of segments split from the gso package.
> > +\end{description}
> > +
> > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Reset Stats}
> > +
> > +The structure corresponding to the receiveq reset stats is virtio_net_stats_rx_reset.
> > +
> > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq reset stats
> > +can be obtained.
> > +
> > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> > +for more about \field{rx_reset}.
> > +
> > +\begin{description}
> > + \item [rx_reset]
> > + The number of receiveq resets.
> > +\end{description}
> > +
> > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Reset Stats}
> > +
> > +The structure corresponding to the transmitq reset stats is virtio_net_stats_tx_reset.
> > +
> > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq reset stats
> > +can be obtained.
> > +
> > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> > +for more about \field{tx_reset}.
> > +
> > +\begin{description}
> > + \item [tx_reset]
> > + The number of transmitq resets.
> > +\end{description}
> > +
> > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > +
> > +If virtio_net_ctrl_queue_stats is incorrect (such as the following), the device
> > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > +the device MUST abort the entire command.
> > +\begin{itemize}
> > + \item \field{queue_num} exceeds the queue range.
> > + \item \field{type} is not a known value.
> > + \item The type of vq does not match \field{type}. E.g. the driver tries to query
> > + RX stats through a TX index.
> > + \item The feature corresponding to the specified \field{type} was not successfully
> > + negotiated.
> > + \item The size of the buffer allocated by the driver for \field{command-specific-data-reply}
> > + is less than the total size of the stats specialed by
> > + \field{virtio_net_ctrl_queue_stats}.
> > +\end{itemize}
> > +
> > +The device MUST write the requested stats structures in
> > +\field{command-specific-data-reply} in the order specified by the structure
> > +virtio_net_ctrl_queue_stats.
> > +
> > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > +
> > +When a driver tries to obtain a certain stats, it MUST confirm that the relevant
> > +feature negotiation is successful.
> > +
> > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to the vq
> > +specified by \field{queue_num}.
> > +
> > +The \field{command-specific-data-reply} buffer allocated by the driver MUST be
> > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > +
> > +When the driver reads the response, it MUST read
> > +\field{command-specific-data-reply} one by one based on the \field{type}.
> >
> > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > Types / Network Device / Legacy Interface: Framing Requirements}
> > --
> > 2.31.0
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
2023-07-12 11:44 ` Xuan Zhuo
@ 2023-07-12 11:54 ` Michael S. Tsirkin
2023-07-12 12:24 ` Cornelia Huck
0 siblings, 1 reply; 21+ messages in thread
From: Michael S. Tsirkin @ 2023-07-12 11:54 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: virtio-dev, jasowang, Parav Pandit
On Wed, Jul 12, 2023 at 07:44:01PM +0800, Xuan Zhuo wrote:
> On Wed, 12 Jul 2023 07:34:38 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Tue, Mar 15, 2022 at 11:24:02AM +0800, Xuan Zhuo wrote:
> > > This patch allows the driver to obtain some statistics from the device.
> > >
> > > In the back-end implementation, we can count a lot of such information,
> > > which can be used for debugging and judging the running status of the
> > > back-end. We hope to directly display it to the user through ethtool.
> > >
> > > To get stats atomically, try to get stats for all queue pairs in one
> > > command.
> > >
> > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > Functionally, I think this is close to ok now. But the text needs
> > of work. Are you trying to target 1.3 with this?
>
> I personally worry about that 1.3 may be too late, if possible, I would like to
> respond as soon as possible.
>
> I really don't really care if it can get into 1.3 or not but I do hope that this
> can be done as soon as possible.
>
> Thanks.
Yes we were supposed to freeze for 1.3. This change can be merged on a
main branch after 1.3 forks and is under review.
>
> >
> > Feedback from other hw vendors would be nice. Parav could you take
> > a look and say whether the list of counters seems rich enough for
> > you? Any counters you'd like to add?
> >
> >
> > > ---
> > > conformance.tex | 2 +
> > > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 405 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/conformance.tex b/conformance.tex
> > > index 42f8537..c67f877 100644
> > > --- a/conformance.tex
> > > +++ b/conformance.tex
> > > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> > > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State}
> > > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > > \end{itemize}
> > >
> > > \conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance}
> > > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode}
> > > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > > +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > > \end{itemize}
> > >
> > > \conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance}
> > > diff --git a/content.tex b/content.tex
> > > index c6f116c..81f325d 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
> > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > > channel.
> > >
> > > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level statistics
> > > + to the driver through the control channel.
> > > +
> > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO
> > > (fragmenting the packet) the USO splits large UDP packet
> > > to several segments when each of these smaller packets has UDP header.
> > > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
> > > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6.
> > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > \end{description}
> > > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > u8 command;
> > > u8 command-specific-data[];
> > > u8 ack;
> > > + u8 command-specific-data-reply[];
> > > };
> > >
> > > /* ack values */
> > > @@ -4023,9 +4028,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > \end{lstlisting}
> > >
> > > The \field{class}, \field{command} and command-specific-data are set by the
> > > -driver, and the device sets the \field{ack} byte. There is little it can
> > > -do except issue a diagnostic if \field{ack} is not
> > > -VIRTIO_NET_OK.
> > > +driver, and the device sets the \field{ack} byte and optionally
> > > +\field{command-specific-data-reply}. There is little the driver can
> > > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > > +
> > > +The command VIRTIO_NET_CTRL_STATS_GET contains \field{command-specific-data-reply}.
> > >
> > > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > > \label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > > @@ -4471,6 +4478,399 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > according to the native endian of the guest rather than
> > > (necessarily when not using the legacy interface) little-endian.
> > >
> > > +\paragraph{Device Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > > +get the device stats from the device in \field{command-specific-data-reply}.
> > > +
> > > +To get the stats, the following definitions are used:
> > > +\begin{lstlisting}
> > > +#define VIRTIO_NET_CTRL_STATS 6
> > > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > > +
> > > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > > +
> > > +\end{lstlisting}
> > > +
> > > +Use the command VIRTIO_NET_CTRL_STATS_GET and \field{command-specific-data}
> > > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > > +The result is returned by \field{command-specific-data-reply}.
> > > +The stats ware returned in the order of the type specified in the
> > > +\field{virtio_net_ctrl_queue_stats}.
> > > +
> > > +The following layout structures are used:
> > > +
> > > +\field{command-specific-data}
> > > +\begin{lstlisting}
> > > +struct virtio_net_ctrl_queue_stats {
> > > + u16 nstats;
> > > + struct {
> > > + u16 queue_num;
> > > + u16 type;
> > > + } stats[];
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\field{command-specific-data-reply}
> > > +\begin{lstlisting}
> > > +struct virtio_net_stats_cvq {
> > > + le64 command_num;
> > > + le64 ok_num;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_basic {
> > > + le64 rx_packets;
> > > + le64 rx_bytes;
> > > +
> > > + le64 rx_notification;
> > > + le64 rx_interrupt;
> > > +
> > > + le64 rx_drop;
> > > + le64 rx_drop_overruns;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_csum {
> > > + le64 rx_csum_valid;
> > > + le64 rx_needs_csum;
> > > + le64 rx_csum_bad;
> > > + le64 rx_csum_none;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_gso {
> > > + le64 rx_gso_packets;
> > > + le64 rx_gso_bytes;
> > > + le64 rx_gso_packets_coalesced;
> > > + le64 rx_gso_bytes_coalesced;
> > > + le64 rx_gso_segments;
> > > + le64 rx_gso_segments_bytes;
> > > +};
> > > +
> > > +struct virtio_net_stats_rx_reset {
> > > + le64 rx_reset;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_basic {
> > > + le64 tx_packets;
> > > + le64 tx_bytes;
> > > +
> > > + le64 tx_notification;
> > > + le64 tx_interrupt;
> > > +
> > > + le64 tx_drop;
> > > + le64 tx_drop_malformed;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_csum {
> > > + le64 tx_csum_none;
> > > + le64 tx_needs_csum;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_gso {
> > > + le64 tx_gso_packets;
> > > + le64 tx_gso_bytes;
> > > + le64 tx_gso_packets_split;
> > > + le64 tx_gso_bytes_split;
> > > + le64 tx_gso_segments;
> > > + le64 tx_gso_segments_bytes;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_reset {
> > > + le64 tx_reset;
> > > +};
> > > +
> > > +\end{lstlisting}
> > > +
> > > +\begin{description}
> > > + \item [nstats]
> > > + The number of \field{stats}.
> > > +
> > > + \item [queue_num]
> > > + The number of the virtqueue to obtain the statistics.
> > > +
> > > + \item [type]
> > > + The type of the stats to be obtained.
> > > +
> > > +\end{description}
> > > +
> > > +Correspondence between the vq type, the stats type, the stats structure and the
> > > +required features.
> > > +\begin{tabular}{ |l|l|l|l| }
> > > + \hline
> > > + VQ Type & Stats Type & Stats Structure & Features \\ \hline
> > > +
> > > + controlq & VIRTIO_NET_STATS_TYPE_CVQ & virtio_net_stats_cvq & \\ \hline
> > > +
> > > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC & virtio_net_stats_rx_basic & \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_CSUM & virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_GSO & virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > > + VIRTIO_NET_F_GUEST_TSO6 or\newline
> > > + VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_RX_RESET & virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > > +
> > > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC & virtio_net_stats_tx_basic & \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_CSUM & virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_GSO & virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > > + VIRTIO_NET_F_HOST_TSO6 or\newline
> > > + VIRTIO_NET_F_HOST_USO or\newline
> > > + VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > > + & VIRTIO_NET_STATS_TYPE_TX_RESET & virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > > + \hline
> > > +\end{tabular}
> > > +
> > > +
> > > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > > +
> > > +The structure corresponding to the controlq stats is virtio_net_stats_cvq.
> > > +
> > > +\begin{description}
> > > + \item [command_num]
> > > + The number of commands, including the current command.
> > > +
> > > + \item [ok_num]
> > > + The number of commands (including the current command) where the ack was VIRTIO_NET_OK.
> > > +\end{description}
> > > +
> > > +
> > > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Basic Stats}
> > > +
> > > +The structure corresponding to the receiveq basic stats is virtio_net_stats_rx_basic.
> > > +
> > > +Receiveq basic stats doesn't need any features, as long as the device supports
> > > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > > +
> > > +\begin{description}
> > > + \item [rx_packets]
> > > + The number of packets received by device (not the packets passed to the
> > > + guest), including the dropped packets by device.
> > > +
> > > + \item [rx_bytes]
> > > + The number of bytes received by device (not the packets passed to the
> > > + guest), including the dropped packets by device.
> > > +
> > > + \item [rx_notification]
> > > + The number of driver notifications.
> > > +
> > > + \item [rx_interrupt]
> > > + The number of device interrupts.
> > > +
> > > + \item [rx_drop]
> > > + The number of packets dropped by the receiveq. Contains all kinds of
> > > + packet drop.
> > > +
> > > + \item [rx_drop_overruns]
> > > + The number of packets dropped by the receiveq when no more descriptors
> > > + were available.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Basic Stats}
> > > +
> > > +The structure corresponding to the transmitq basic stats is virtio_net_stats_tx_basic.
> > > +
> > > +Transmitq basic stats doesn't need any features, as long as the device supports
> > > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > > +
> > > +\begin{description}
> > > + \item [tx_packets]
> > > + The number of packets sent by device (not the packets got from the
> > > + guest), excluding the dropped packets by device.
> > > +
> > > + \item [tx_bytes]
> > > + The number of bytes sent by device (not the packets got from the
> > > + guest), excluding the dropped packets by device.
> > > +
> > > + \item [tx_notification]
> > > + The number of driver notifications.
> > > +
> > > + \item [tx_interrupt]
> > > + The number of device interrupts.
> > > +
> > > + \item [tx_drop]
> > > + The number of packets dropped by the transmitq. Contains all kinds of
> > > + packet drop.
> > > +
> > > + \item [tx_drop_malformed]
> > > + The number of packets dropped when the descriptor is in an error state.
> > > + For example, the buffer is too short.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq CSUM Stats}
> > > +
> > > +The structure corresponding to the receiveq csum stats is virtio_net_stats_rx_csum.
> > > +
> > > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the receiveq
> > > +csum stats can be obtained.
> > > +
> > > +The following are the receiveq csum stats:
> > > +
> > > +\begin{description}
> > > + \item [rx_csum_valid]
> > > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > > +
> > > + \item [rx_needs_csum]
> > > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > > +
> > > + \item [rx_csum_bad]
> > > + The number of packets with abnormal csum.
> > > +
> > > + \item [rx_csum_none]
> > > + The number of packets without hardware csum. The packet here refers to
> > > + the non-TCP/UDP packet that the backend cannot recognize.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq CSUM Stats}
> > > +
> > > +The structure corresponding to the transmitq csum stats is virtio_net_stats_tx_csum.
> > > +
> > > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the transmitq csum
> > > +stats can be obtained.
> > > +
> > > +The following are the transmitq csum stats:
> > > +
> > > +\begin{description}
> > > + \item [tx_csum_none]
> > > + The number of packets that didn't require hardware csum.
> > > +
> > > + \item [tx_needs_csum]
> > > + The number of packets that required hardware csum.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO Stats}
> > > +
> > > +The structure corresponding to the receiveq gso stats is virtio_net_stats_rx_gso.
> > > +
> > > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > > +been negotiated, the receiveq gso stats can be obtained.
> > > +
> > > +Rx gso packets refer to packets passed by the device to the driver where
> > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > +
> > > +\begin{description}
> > > + \item [rx_gso_packets]
> > > + The number of the rx gso packets.
> > > +
> > > + \item [rx_gso_bytes]
> > > + The number of bytes(excluding the virtio net header) of the rx gso packets.
> > > +
> > > + \item [rx_gso_packets_coalesced]
> > > + The number of the rx gso packages generated by coalescing.
> > > +
> > > + \item [rx_gso_bytes_coalesced]
> > > + The number of bytes(excluding the virtio net header) of the rx gso packets generated by coalescing.
> > > +
> > > + \item [rx_gso_segments]
> > > + The number of coalesced segments.
> > > +
> > > + \item [rx_gso_segments_bytes]
> > > + The number of bytes of coalesced segments.
> > > +
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq GSO Stats}
> > > +
> > > +The structure corresponding to the transmitq gso stats is virtio_net_stats_tx_gso.
> > > +
> > > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > > +been negotiated, the transmitq gso stats can be obtained.
> > > +
> > > +Tx gso packets refer to packets passed by the driver to the device where
> > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > +
> > > +\begin{description}
> > > + \item [tx_gso_packets]
> > > + The number of the tx gso packets.
> > > +
> > > + \item [tx_gso_bytes]
> > > + The number of bytes(excluding the virtio net header) of the tx gso packets.
> > > +
> > > + \item [tx_gso_packets_split]
> > > + The number of the tx gso packets that been split.
> > > +
> > > + \item [tx_gso_bytes_split]
> > > + The number of bytes(excluding the virtio net header) of the tx gso packets that been split.
> > > +
> > > + \item [tx_gso_segments]
> > > + The number of segments split from the gso package.
> > > +
> > > + \item [tx_gso_segments_bytes]
> > > + The number of bytes(excluding the virtio net header) of segments split from the gso package.
> > > +\end{description}
> > > +
> > > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Receiveq Reset Stats}
> > > +
> > > +The structure corresponding to the receiveq reset stats is virtio_net_stats_rx_reset.
> > > +
> > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq reset stats
> > > +can be obtained.
> > > +
> > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> > > +for more about \field{rx_reset}.
> > > +
> > > +\begin{description}
> > > + \item [rx_reset]
> > > + The number of receiveq resets.
> > > +\end{description}
> > > +
> > > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats / Transmitq Reset Stats}
> > > +
> > > +The structure corresponding to the transmitq reset stats is virtio_net_stats_tx_reset.
> > > +
> > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq reset stats
> > > +can be obtained.
> > > +
> > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}
> > > +for more about \field{tx_reset}.
> > > +
> > > +\begin{description}
> > > + \item [tx_reset]
> > > + The number of transmitq resets.
> > > +\end{description}
> > > +
> > > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +If virtio_net_ctrl_queue_stats is incorrect (such as the following), the device
> > > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > > +the device MUST abort the entire command.
> > > +\begin{itemize}
> > > + \item \field{queue_num} exceeds the queue range.
> > > + \item \field{type} is not a known value.
> > > + \item The type of vq does not match \field{type}. E.g. the driver tries to query
> > > + RX stats through a TX index.
> > > + \item The feature corresponding to the specified \field{type} was not successfully
> > > + negotiated.
> > > + \item The size of the buffer allocated by the driver for \field{command-specific-data-reply}
> > > + is less than the total size of the stats specialed by
> > > + \field{virtio_net_ctrl_queue_stats}.
> > > +\end{itemize}
> > > +
> > > +The device MUST write the requested stats structures in
> > > +\field{command-specific-data-reply} in the order specified by the structure
> > > +virtio_net_ctrl_queue_stats.
> > > +
> > > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network Device / Device Operation / Control Virtqueue / Device Stats}
> > > +
> > > +When a driver tries to obtain a certain stats, it MUST confirm that the relevant
> > > +feature negotiation is successful.
> > > +
> > > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to the vq
> > > +specified by \field{queue_num}.
> > > +
> > > +The \field{command-specific-data-reply} buffer allocated by the driver MUST be
> > > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > > +
> > > +When the driver reads the response, it MUST read
> > > +\field{command-specific-data-reply} one by one based on the \field{type}.
> > >
> > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > Types / Network Device / Legacy Interface: Framing Requirements}
> > > --
> > > 2.31.0
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
2023-07-12 11:54 ` Michael S. Tsirkin
@ 2023-07-12 12:24 ` Cornelia Huck
2023-07-12 12:33 ` Michael S. Tsirkin
0 siblings, 1 reply; 21+ messages in thread
From: Cornelia Huck @ 2023-07-12 12:24 UTC (permalink / raw)
To: Michael S. Tsirkin, Xuan Zhuo; +Cc: virtio-dev, jasowang, Parav Pandit
On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Jul 12, 2023 at 07:44:01PM +0800, Xuan Zhuo wrote:
>> On Wed, 12 Jul 2023 07:34:38 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> > On Tue, Mar 15, 2022 at 11:24:02AM +0800, Xuan Zhuo wrote:
>> > > This patch allows the driver to obtain some statistics from the device.
>> > >
>> > > In the back-end implementation, we can count a lot of such information,
>> > > which can be used for debugging and judging the running status of the
>> > > back-end. We hope to directly display it to the user through ethtool.
>> > >
>> > > To get stats atomically, try to get stats for all queue pairs in one
>> > > command.
>> > >
>> > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>> > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
>> >
>> > Functionally, I think this is close to ok now. But the text needs
>> > of work. Are you trying to target 1.3 with this?
>>
>> I personally worry about that 1.3 may be too late, if possible, I would like to
>> respond as soon as possible.
>>
>> I really don't really care if it can get into 1.3 or not but I do hope that this
>> can be done as soon as possible.
>>
>> Thanks.
>
> Yes we were supposed to freeze for 1.3. This change can be merged on a
> main branch after 1.3 forks and is under review.
Nod, that's what I would prefer to do. Being merged on virtio-next
should be enough for including device/driver implementations.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
2023-07-12 12:24 ` Cornelia Huck
@ 2023-07-12 12:33 ` Michael S. Tsirkin
2023-07-21 12:24 ` [virtio-dev] 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats) Cornelia Huck
0 siblings, 1 reply; 21+ messages in thread
From: Michael S. Tsirkin @ 2023-07-12 12:33 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Xuan Zhuo, virtio-dev, jasowang, Parav Pandit
On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote:
> On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Wed, Jul 12, 2023 at 07:44:01PM +0800, Xuan Zhuo wrote:
> >> On Wed, 12 Jul 2023 07:34:38 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> > On Tue, Mar 15, 2022 at 11:24:02AM +0800, Xuan Zhuo wrote:
> >> > > This patch allows the driver to obtain some statistics from the device.
> >> > >
> >> > > In the back-end implementation, we can count a lot of such information,
> >> > > which can be used for debugging and judging the running status of the
> >> > > back-end. We hope to directly display it to the user through ethtool.
> >> > >
> >> > > To get stats atomically, try to get stats for all queue pairs in one
> >> > > command.
> >> > >
> >> > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >> > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> >> >
> >> > Functionally, I think this is close to ok now. But the text needs
> >> > of work. Are you trying to target 1.3 with this?
> >>
> >> I personally worry about that 1.3 may be too late, if possible, I would like to
> >> respond as soon as possible.
> >>
> >> I really don't really care if it can get into 1.3 or not but I do hope that this
> >> can be done as soon as possible.
> >>
> >> Thanks.
> >
> > Yes we were supposed to freeze for 1.3. This change can be merged on a
> > main branch after 1.3 forks and is under review.
>
> Nod, that's what I would prefer to do. Being merged on virtio-next
> should be enough for including device/driver implementations.
Except I'd prefer a v1.3 branch instead of a next branch - adding things
on the branch should be harder, not easier.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
2023-07-12 9:11 ` [virtio-comment] " Xuan Zhuo
@ 2023-07-13 2:21 ` Jason Wang
-1 siblings, 0 replies; 21+ messages in thread
From: Jason Wang @ 2023-07-13 2:21 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
On Wed, Jul 12, 2023 at 5:19 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
>
> On Wed, 12 Jul 2023 16:08:48 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > wrote:
> >
> > > hi, guys
> > >
> > > After a lot of internal discussions, I removed some unimportant counters.
> > > Based
> > > on this v12 patch I am repling to, most of the requirements have been met.
> > >
> > > The patch link
> > > https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
> > >
> > > We still have these counters, let's see if they can be standardized.
> > >
> > > ## limit
> > >
> > > * tx_bps_limit_drops
> > > * tx_pps_limit_drops
> > > * rx_bps_limit_drops
> > > * rx_pps_limit_drops
> > >
> > > In a cloud scenario, multiple users purchase different VMs, and these VMs
> > > share
> > > the capabilities of the same host. In order to ensure that each VM will not
> > > affect others, the network card(virtio-net) capability of each VM is
> > > limited.
> > > These users purchase VMs, this limit has already been determined.
> > >
> >
> > This seems a feature beyond the counters but QOS. I think we virtio spec
> > need to support QOS before we can discuss any QOS related counters.
> >
> >
> > >
> > > So if the network card traffic of a vm exceeds the upper limit, packet
> > > loss will
> > > occur. It is necessary for us to count these packet losses. And the device
> > > should expose to the user.
> > >
> > > ## session
> > >
> > > * tx_session_full_drops The number of packet drops in the sending
> > > direction when
> > > the session is full
> > > * rx_session_full_drops The number of packets lost when the session is
> > > full in the receiving direction
> > >
> > > Our dpu supports tcp connection tracking, but there is an upper limit to
> > > the
> > > number of connections, and if it exceeds, packet loss will also occur.
> > >
> >
> > Similarly, if connect tracking offload is supported, it needs to be
> > implemented in the spec first then we can have related counters.
> >
> >
> > >
> > > ## ACL
> > >
> > > * tx_acl_drops ACL packet loss in the sending direction
> > > * rx_acl_drops The number of ACL packets lost in the receiving direction
> > >
> > > In our cloud service, for network cards, users are allowed to configure
> > > security
> > > rules,such as which IPs can access which ports of this machine.
> > >
> >
> > Same as above, ACL should be supported by the spec first then the counters.
> >
> > In conclusion, the features must be self contained. Otherwise you are doing
> > vDPA actually and those counters need to be accessed in a vendor specific
> > way.
>
> Yes that's the point, as we've discussed here.
>
> http://lore.kernel.org/all/1686550355.2503424-1-xuanzhuo@linux.alibaba.com
>
> There are many similar counters. There may not be many usage scenarios, so I
> didn't list them here.
>
> Our acl, seesion, and limit are not configured by the user at the driver layer,
> and I don't think these should be configured at the driver.
Sounds like something related to OPI. But if the features were not
configured by driver, any reason to let it be noticeable by it?
Exposing things like tx_acl_drops may have security implications,
enabling software to probe the ACL rules?
Thanks
> So at least as
> far as our usage scenarios are concerned, these are some functions that have
> nothing to do with virtio spec.
>
> So what I want most is that the virto spec supports a vendor channel.
>
> Of course, I am ok with Parav's abstraction of "limit".
>
> Some implementations of txq are lossy and some are not creating backpressure/flow control to driver so driver can rate limit it naturally.
> So a tx packet drop counter is needed to cover the lossy implementations which is abstract enough regardless of reason on why device dropped it.
> A more granular counter becomes vendor specific that we can possibly avoid or place under different command.
>
> But acl and session may not be very good to abstract.
>
> Thanks.
>
>
> >
> > Thanks
> >
> >
> > >
> > >
> > > Thanks
> > >
> > >
> > > On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > wrote:
> > > > This patch allows the driver to obtain some statistics from the device.
> > > >
> > > > In the back-end implementation, we can count a lot of such information,
> > > > which can be used for debugging and judging the running status of the
> > > > back-end. We hope to directly display it to the user through ethtool.
> > > >
> > > > To get stats atomically, try to get stats for all queue pairs in one
> > > > command.
> > > >
> > > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > > conformance.tex | 2 +
> > > > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > > > 2 files changed, 405 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/conformance.tex b/conformance.tex
> > > > index 42f8537..c67f877 100644
> > > > --- a/conformance.tex
> > > > +++ b/conformance.tex
> > > > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > / Conformance Targets}
> > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > mode}
> > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Offloads State Configuration / Setting
> > > Offloads State}
> > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > > +\item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Device Stats}
> > > > \end{itemize}
> > > >
> > > > \conformance{\subsection}{Block Driver
> > > Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> > > Conformance}
> > > > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > / Conformance Targets}
> > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > mode}
> > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > > > +\item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Device Stats}
> > > > \end{itemize}
> > > >
> > > > \conformance{\subsection}{Block Device
> > > Conformance}\label{sec:Conformance / Device Conformance / Block Device
> > > Conformance}
> > > > diff --git a/content.tex b/content.tex
> > > > index c6f116c..81f325d 100644
> > > > --- a/content.tex
> > > > +++ b/content.tex
> > > > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> > > Network Device / Feature bits
> > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > > > channel.
> > > >
> > > > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> > > statistics
> > > > + to the driver through the control channel.
> > > > +
> > > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> > > Unlike UFO
> > > > (fragmenting the packet) the USO splits large UDP packet
> > > > to several segments when each of these smaller packets has UDP header.
> > > > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> > > requirements}\label{sec:Device Types / Network Device
> > > > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> > > VIRTIO_NET_F_HOST_TSO6.
> > > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \end{description}
> > > > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > > Types / Network Device / Devi
> > > > u8 command;
> > > > u8 command-specific-data[];
> > > > u8 ack;
> > > > + u8 command-specific-data-reply[];
> > > > };
> > > >
> > > > /* ack values */
> > > > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > \end{lstlisting}
> > > >
> > > > The \field{class}, \field{command} and command-specific-data are set by
> > > the
> > > > -driver, and the device sets the \field{ack} byte. There is little it can
> > > > -do except issue a diagnostic if \field{ack} is not
> > > > -VIRTIO_NET_OK.
> > > > +driver, and the device sets the \field{ack} byte and optionally
> > > > +\field{command-specific-data-reply}. There is little the driver can
> > > > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > > > +
> > > > +The command VIRTIO_NET_CTRL_STATS_GET contains
> > > \field{command-specific-data-reply}.
> > > >
> > > > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > > > \label{sec:Device Types / Network Device / Device Operation / Control
> > > Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > > > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > according to the native endian of the guest rather than
> > > > (necessarily when not using the legacy interface) little-endian.
> > > >
> > > > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> > > Device Operation / Control Virtqueue / Device Stats}
> > > > +
> > > > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > > > +get the device stats from the device in
> > > \field{command-specific-data-reply}.
> > > > +
> > > > +To get the stats, the following definitions are used:
> > > > +\begin{lstlisting}
> > > > +#define VIRTIO_NET_CTRL_STATS 6
> > > > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > > > +
> > > > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > > > +
> > > > +\end{lstlisting}
> > > > +
> > > > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> > > \field{command-specific-data}
> > > > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > > > +The result is returned by \field{command-specific-data-reply}.
> > > > +The stats ware returned in the order of the type specified in the
> > > > +\field{virtio_net_ctrl_queue_stats}.
> > > > +
> > > > +The following layout structures are used:
> > > > +
> > > > +\field{command-specific-data}
> > > > +\begin{lstlisting}
> > > > +struct virtio_net_ctrl_queue_stats {
> > > > + u16 nstats;
> > > > + struct {
> > > > + u16 queue_num;
> > > > + u16 type;
> > > > + } stats[];
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +\field{command-specific-data-reply}
> > > > +\begin{lstlisting}
> > > > +struct virtio_net_stats_cvq {
> > > > + le64 command_num;
> > > > + le64 ok_num;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_basic {
> > > > + le64 rx_packets;
> > > > + le64 rx_bytes;
> > > > +
> > > > + le64 rx_notification;
> > > > + le64 rx_interrupt;
> > > > +
> > > > + le64 rx_drop;
> > > > + le64 rx_drop_overruns;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_csum {
> > > > + le64 rx_csum_valid;
> > > > + le64 rx_needs_csum;
> > > > + le64 rx_csum_bad;
> > > > + le64 rx_csum_none;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_gso {
> > > > + le64 rx_gso_packets;
> > > > + le64 rx_gso_bytes;
> > > > + le64 rx_gso_packets_coalesced;
> > > > + le64 rx_gso_bytes_coalesced;
> > > > + le64 rx_gso_segments;
> > > > + le64 rx_gso_segments_bytes;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_reset {
> > > > + le64 rx_reset;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_basic {
> > > > + le64 tx_packets;
> > > > + le64 tx_bytes;
> > > > +
> > > > + le64 tx_notification;
> > > > + le64 tx_interrupt;
> > > > +
> > > > + le64 tx_drop;
> > > > + le64 tx_drop_malformed;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_csum {
> > > > + le64 tx_csum_none;
> > > > + le64 tx_needs_csum;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_gso {
> > > > + le64 tx_gso_packets;
> > > > + le64 tx_gso_bytes;
> > > > + le64 tx_gso_packets_split;
> > > > + le64 tx_gso_bytes_split;
> > > > + le64 tx_gso_segments;
> > > > + le64 tx_gso_segments_bytes;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_reset {
> > > > + le64 tx_reset;
> > > > +};
> > > > +
> > > > +\end{lstlisting}
> > > > +
> > > > +\begin{description}
> > > > + \item [nstats]
> > > > + The number of \field{stats}.
> > > > +
> > > > + \item [queue_num]
> > > > + The number of the virtqueue to obtain the statistics.
> > > > +
> > > > + \item [type]
> > > > + The type of the stats to be obtained.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +Correspondence between the vq type, the stats type, the stats structure
> > > and the
> > > > +required features.
> > > > +\begin{tabular}{ |l|l|l|l| }
> > > > + \hline
> > > > + VQ Type & Stats Type & Stats
> > > Structure & Features \\ \hline
> > > > +
> > > > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> > > virtio_net_stats_cvq & \\ \hline
> > > > +
> > > > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> > > virtio_net_stats_rx_basic & \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> > > virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> > > virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > > > +
> > > VIRTIO_NET_F_GUEST_TSO6 or\newline
> > > > +
> > > VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> > > virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > > > +
> > > > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> > > virtio_net_stats_tx_basic & \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> > > virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> > > virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > > > +
> > > VIRTIO_NET_F_HOST_TSO6 or\newline
> > > > +
> > > VIRTIO_NET_F_HOST_USO or\newline
> > > > +
> > > VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> > > virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > > > + \hline
> > > > +\end{tabular}
> > > > +
> > > > +
> > > > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> > > Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > > > +
> > > > +The structure corresponding to the controlq stats is
> > > virtio_net_stats_cvq.
> > > > +
> > > > +\begin{description}
> > > > + \item [command_num]
> > > > + The number of commands, including the current command.
> > > > +
> > > > + \item [ok_num]
> > > > + The number of commands (including the current command) where
> > > the ack was VIRTIO_NET_OK.
> > > > +\end{description}
> > > > +
> > > > +
> > > > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > Basic Stats}
> > > > +
> > > > +The structure corresponding to the receiveq basic stats is
> > > virtio_net_stats_rx_basic.
> > > > +
> > > > +Receiveq basic stats doesn't need any features, as long as the device
> > > supports
> > > > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_packets]
> > > > + The number of packets received by device (not the packets
> > > passed to the
> > > > + guest), including the dropped packets by device.
> > > > +
> > > > + \item [rx_bytes]
> > > > + The number of bytes received by device (not the packets passed
> > > to the
> > > > + guest), including the dropped packets by device.
> > > > +
> > > > + \item [rx_notification]
> > > > + The number of driver notifications.
> > > > +
> > > > + \item [rx_interrupt]
> > > > + The number of device interrupts.
> > > > +
> > > > + \item [rx_drop]
> > > > + The number of packets dropped by the receiveq. Contains all
> > > kinds of
> > > > + packet drop.
> > > > +
> > > > + \item [rx_drop_overruns]
> > > > + The number of packets dropped by the receiveq when no more
> > > descriptors
> > > > + were available.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > Basic Stats}
> > > > +
> > > > +The structure corresponding to the transmitq basic stats is
> > > virtio_net_stats_tx_basic.
> > > > +
> > > > +Transmitq basic stats doesn't need any features, as long as the device
> > > supports
> > > > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_packets]
> > > > + The number of packets sent by device (not the packets got from
> > > the
> > > > + guest), excluding the dropped packets by device.
> > > > +
> > > > + \item [tx_bytes]
> > > > + The number of bytes sent by device (not the packets got from the
> > > > + guest), excluding the dropped packets by device.
> > > > +
> > > > + \item [tx_notification]
> > > > + The number of driver notifications.
> > > > +
> > > > + \item [tx_interrupt]
> > > > + The number of device interrupts.
> > > > +
> > > > + \item [tx_drop]
> > > > + The number of packets dropped by the transmitq. Contains all
> > > kinds of
> > > > + packet drop.
> > > > +
> > > > + \item [tx_drop_malformed]
> > > > + The number of packets dropped when the descriptor is in an
> > > error state.
> > > > + For example, the buffer is too short.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > CSUM Stats}
> > > > +
> > > > +The structure corresponding to the receiveq csum stats is
> > > virtio_net_stats_rx_csum.
> > > > +
> > > > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> > > receiveq
> > > > +csum stats can be obtained.
> > > > +
> > > > +The following are the receiveq csum stats:
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_csum_valid]
> > > > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > > > +
> > > > + \item [rx_needs_csum]
> > > > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > > > +
> > > > + \item [rx_csum_bad]
> > > > + The number of packets with abnormal csum.
> > > > +
> > > > + \item [rx_csum_none]
> > > > + The number of packets without hardware csum. The packet here
> > > refers to
> > > > + the non-TCP/UDP packet that the backend cannot recognize.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > CSUM Stats}
> > > > +
> > > > +The structure corresponding to the transmitq csum stats is
> > > virtio_net_stats_tx_csum.
> > > > +
> > > > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> > > transmitq csum
> > > > +stats can be obtained.
> > > > +
> > > > +The following are the transmitq csum stats:
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_csum_none]
> > > > + The number of packets that didn't require hardware csum.
> > > > +
> > > > + \item [tx_needs_csum]
> > > > + The number of packets that required hardware csum.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> > > Stats}
> > > > +
> > > > +The structure corresponding to the receiveq gso stats is
> > > virtio_net_stats_rx_gso.
> > > > +
> > > > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > > > +been negotiated, the receiveq gso stats can be obtained.
> > > > +
> > > > +Rx gso packets refer to packets passed by the device to the driver where
> > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_gso_packets]
> > > > + The number of the rx gso packets.
> > > > +
> > > > + \item [rx_gso_bytes]
> > > > + The number of bytes(excluding the virtio net header) of the rx
> > > gso packets.
> > > > +
> > > > + \item [rx_gso_packets_coalesced]
> > > > + The number of the rx gso packages generated by coalescing.
> > > > +
> > > > + \item [rx_gso_bytes_coalesced]
> > > > + The number of bytes(excluding the virtio net header) of the rx
> > > gso packets generated by coalescing.
> > > > +
> > > > + \item [rx_gso_segments]
> > > > + The number of coalesced segments.
> > > > +
> > > > + \item [rx_gso_segments_bytes]
> > > > + The number of bytes of coalesced segments.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > GSO Stats}
> > > > +
> > > > +The structure corresponding to the transmitq gso stats is
> > > virtio_net_stats_tx_gso.
> > > > +
> > > > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > > > +been negotiated, the transmitq gso stats can be obtained.
> > > > +
> > > > +Tx gso packets refer to packets passed by the driver to the device where
> > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_gso_packets]
> > > > + The number of the tx gso packets.
> > > > +
> > > > + \item [tx_gso_bytes]
> > > > + The number of bytes(excluding the virtio net header) of the tx
> > > gso packets.
> > > > +
> > > > + \item [tx_gso_packets_split]
> > > > + The number of the tx gso packets that been split.
> > > > +
> > > > + \item [tx_gso_bytes_split]
> > > > + The number of bytes(excluding the virtio net header) of the tx
> > > gso packets that been split.
> > > > +
> > > > + \item [tx_gso_segments]
> > > > + The number of segments split from the gso package.
> > > > +
> > > > + \item [tx_gso_segments_bytes]
> > > > + The number of bytes(excluding the virtio net header) of
> > > segments split from the gso package.
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > Reset Stats}
> > > > +
> > > > +The structure corresponding to the receiveq reset stats is
> > > virtio_net_stats_rx_reset.
> > > > +
> > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> > > reset stats
> > > > +can be obtained.
> > > > +
> > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > Virtqueue Reset}
> > > > +for more about \field{rx_reset}.
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_reset]
> > > > + The number of receiveq resets.
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > Reset Stats}
> > > > +
> > > > +The structure corresponding to the transmitq reset stats is
> > > virtio_net_stats_tx_reset.
> > > > +
> > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> > > reset stats
> > > > +can be obtained.
> > > > +
> > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > Virtqueue Reset}
> > > > +for more about \field{tx_reset}.
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_reset]
> > > > + The number of transmitq resets.
> > > > +\end{description}
> > > > +
> > > > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > +
> > > > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> > > the device
> > > > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > > > +the device MUST abort the entire command.
> > > > +\begin{itemize}
> > > > + \item \field{queue_num} exceeds the queue range.
> > > > + \item \field{type} is not a known value.
> > > > + \item The type of vq does not match \field{type}. E.g. the driver
> > > tries to query
> > > > + RX stats through a TX index.
> > > > + \item The feature corresponding to the specified \field{type} was
> > > not successfully
> > > > + negotiated.
> > > > + \item The size of the buffer allocated by the driver for
> > > \field{command-specific-data-reply}
> > > > + is less than the total size of the stats specialed by
> > > > + \field{virtio_net_ctrl_queue_stats}.
> > > > +\end{itemize}
> > > > +
> > > > +The device MUST write the requested stats structures in
> > > > +\field{command-specific-data-reply} in the order specified by the
> > > structure
> > > > +virtio_net_ctrl_queue_stats.
> > > > +
> > > > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > +
> > > > +When a driver tries to obtain a certain stats, it MUST confirm that the
> > > relevant
> > > > +feature negotiation is successful.
> > > > +
> > > > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> > > the vq
> > > > +specified by \field{queue_num}.
> > > > +
> > > > +The \field{command-specific-data-reply} buffer allocated by the driver
> > > MUST be
> > > > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > > > +
> > > > +When the driver reads the response, it MUST read
> > > > +\field{command-specific-data-reply} one by one based on the
> > > \field{type}.
> > > >
> > > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > > Types / Network Device / Legacy Interface: Framing Requirements}
> > > > --
> > > > 2.31.0
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > >
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-comment] Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
@ 2023-07-13 2:21 ` Jason Wang
0 siblings, 0 replies; 21+ messages in thread
From: Jason Wang @ 2023-07-13 2:21 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
On Wed, Jul 12, 2023 at 5:19 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
>
> On Wed, 12 Jul 2023 16:08:48 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > wrote:
> >
> > > hi, guys
> > >
> > > After a lot of internal discussions, I removed some unimportant counters.
> > > Based
> > > on this v12 patch I am repling to, most of the requirements have been met.
> > >
> > > The patch link
> > > https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
> > >
> > > We still have these counters, let's see if they can be standardized.
> > >
> > > ## limit
> > >
> > > * tx_bps_limit_drops
> > > * tx_pps_limit_drops
> > > * rx_bps_limit_drops
> > > * rx_pps_limit_drops
> > >
> > > In a cloud scenario, multiple users purchase different VMs, and these VMs
> > > share
> > > the capabilities of the same host. In order to ensure that each VM will not
> > > affect others, the network card(virtio-net) capability of each VM is
> > > limited.
> > > These users purchase VMs, this limit has already been determined.
> > >
> >
> > This seems a feature beyond the counters but QOS. I think we virtio spec
> > need to support QOS before we can discuss any QOS related counters.
> >
> >
> > >
> > > So if the network card traffic of a vm exceeds the upper limit, packet
> > > loss will
> > > occur. It is necessary for us to count these packet losses. And the device
> > > should expose to the user.
> > >
> > > ## session
> > >
> > > * tx_session_full_drops The number of packet drops in the sending
> > > direction when
> > > the session is full
> > > * rx_session_full_drops The number of packets lost when the session is
> > > full in the receiving direction
> > >
> > > Our dpu supports tcp connection tracking, but there is an upper limit to
> > > the
> > > number of connections, and if it exceeds, packet loss will also occur.
> > >
> >
> > Similarly, if connect tracking offload is supported, it needs to be
> > implemented in the spec first then we can have related counters.
> >
> >
> > >
> > > ## ACL
> > >
> > > * tx_acl_drops ACL packet loss in the sending direction
> > > * rx_acl_drops The number of ACL packets lost in the receiving direction
> > >
> > > In our cloud service, for network cards, users are allowed to configure
> > > security
> > > rules,such as which IPs can access which ports of this machine.
> > >
> >
> > Same as above, ACL should be supported by the spec first then the counters.
> >
> > In conclusion, the features must be self contained. Otherwise you are doing
> > vDPA actually and those counters need to be accessed in a vendor specific
> > way.
>
> Yes that's the point, as we've discussed here.
>
> http://lore.kernel.org/all/1686550355.2503424-1-xuanzhuo@linux.alibaba.com
>
> There are many similar counters. There may not be many usage scenarios, so I
> didn't list them here.
>
> Our acl, seesion, and limit are not configured by the user at the driver layer,
> and I don't think these should be configured at the driver.
Sounds like something related to OPI. But if the features were not
configured by driver, any reason to let it be noticeable by it?
Exposing things like tx_acl_drops may have security implications,
enabling software to probe the ACL rules?
Thanks
> So at least as
> far as our usage scenarios are concerned, these are some functions that have
> nothing to do with virtio spec.
>
> So what I want most is that the virto spec supports a vendor channel.
>
> Of course, I am ok with Parav's abstraction of "limit".
>
> Some implementations of txq are lossy and some are not creating backpressure/flow control to driver so driver can rate limit it naturally.
> So a tx packet drop counter is needed to cover the lossy implementations which is abstract enough regardless of reason on why device dropped it.
> A more granular counter becomes vendor specific that we can possibly avoid or place under different command.
>
> But acl and session may not be very good to abstract.
>
> Thanks.
>
>
> >
> > Thanks
> >
> >
> > >
> > >
> > > Thanks
> > >
> > >
> > > On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > wrote:
> > > > This patch allows the driver to obtain some statistics from the device.
> > > >
> > > > In the back-end implementation, we can count a lot of such information,
> > > > which can be used for debugging and judging the running status of the
> > > > back-end. We hope to directly display it to the user through ethtool.
> > > >
> > > > To get stats atomically, try to get stats for all queue pairs in one
> > > > command.
> > > >
> > > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > > conformance.tex | 2 +
> > > > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > > > 2 files changed, 405 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/conformance.tex b/conformance.tex
> > > > index 42f8537..c67f877 100644
> > > > --- a/conformance.tex
> > > > +++ b/conformance.tex
> > > > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > / Conformance Targets}
> > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > mode}
> > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Offloads State Configuration / Setting
> > > Offloads State}
> > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > > +\item \ref{drivernormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Device Stats}
> > > > \end{itemize}
> > > >
> > > > \conformance{\subsection}{Block Driver
> > > Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> > > Conformance}
> > > > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > / Conformance Targets}
> > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > mode}
> > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > > > +\item \ref{devicenormative:Device Types / Network Device / Device
> > > Operation / Control Virtqueue / Device Stats}
> > > > \end{itemize}
> > > >
> > > > \conformance{\subsection}{Block Device
> > > Conformance}\label{sec:Conformance / Device Conformance / Block Device
> > > Conformance}
> > > > diff --git a/content.tex b/content.tex
> > > > index c6f116c..81f325d 100644
> > > > --- a/content.tex
> > > > +++ b/content.tex
> > > > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> > > Network Device / Feature bits
> > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > > > channel.
> > > >
> > > > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> > > statistics
> > > > + to the driver through the control channel.
> > > > +
> > > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> > > Unlike UFO
> > > > (fragmenting the packet) the USO splits large UDP packet
> > > > to several segments when each of these smaller packets has UDP header.
> > > > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> > > requirements}\label{sec:Device Types / Network Device
> > > > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> > > VIRTIO_NET_F_HOST_TSO6.
> > > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > \end{description}
> > > > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > > Types / Network Device / Devi
> > > > u8 command;
> > > > u8 command-specific-data[];
> > > > u8 ack;
> > > > + u8 command-specific-data-reply[];
> > > > };
> > > >
> > > > /* ack values */
> > > > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > \end{lstlisting}
> > > >
> > > > The \field{class}, \field{command} and command-specific-data are set by
> > > the
> > > > -driver, and the device sets the \field{ack} byte. There is little it can
> > > > -do except issue a diagnostic if \field{ack} is not
> > > > -VIRTIO_NET_OK.
> > > > +driver, and the device sets the \field{ack} byte and optionally
> > > > +\field{command-specific-data-reply}. There is little the driver can
> > > > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > > > +
> > > > +The command VIRTIO_NET_CTRL_STATS_GET contains
> > > \field{command-specific-data-reply}.
> > > >
> > > > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > > > \label{sec:Device Types / Network Device / Device Operation / Control
> > > Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > > > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > according to the native endian of the guest rather than
> > > > (necessarily when not using the legacy interface) little-endian.
> > > >
> > > > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> > > Device Operation / Control Virtqueue / Device Stats}
> > > > +
> > > > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > > > +get the device stats from the device in
> > > \field{command-specific-data-reply}.
> > > > +
> > > > +To get the stats, the following definitions are used:
> > > > +\begin{lstlisting}
> > > > +#define VIRTIO_NET_CTRL_STATS 6
> > > > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > > > +
> > > > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > > > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > > > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > > > +
> > > > +\end{lstlisting}
> > > > +
> > > > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> > > \field{command-specific-data}
> > > > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > > > +The result is returned by \field{command-specific-data-reply}.
> > > > +The stats ware returned in the order of the type specified in the
> > > > +\field{virtio_net_ctrl_queue_stats}.
> > > > +
> > > > +The following layout structures are used:
> > > > +
> > > > +\field{command-specific-data}
> > > > +\begin{lstlisting}
> > > > +struct virtio_net_ctrl_queue_stats {
> > > > + u16 nstats;
> > > > + struct {
> > > > + u16 queue_num;
> > > > + u16 type;
> > > > + } stats[];
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +\field{command-specific-data-reply}
> > > > +\begin{lstlisting}
> > > > +struct virtio_net_stats_cvq {
> > > > + le64 command_num;
> > > > + le64 ok_num;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_basic {
> > > > + le64 rx_packets;
> > > > + le64 rx_bytes;
> > > > +
> > > > + le64 rx_notification;
> > > > + le64 rx_interrupt;
> > > > +
> > > > + le64 rx_drop;
> > > > + le64 rx_drop_overruns;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_csum {
> > > > + le64 rx_csum_valid;
> > > > + le64 rx_needs_csum;
> > > > + le64 rx_csum_bad;
> > > > + le64 rx_csum_none;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_gso {
> > > > + le64 rx_gso_packets;
> > > > + le64 rx_gso_bytes;
> > > > + le64 rx_gso_packets_coalesced;
> > > > + le64 rx_gso_bytes_coalesced;
> > > > + le64 rx_gso_segments;
> > > > + le64 rx_gso_segments_bytes;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_rx_reset {
> > > > + le64 rx_reset;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_basic {
> > > > + le64 tx_packets;
> > > > + le64 tx_bytes;
> > > > +
> > > > + le64 tx_notification;
> > > > + le64 tx_interrupt;
> > > > +
> > > > + le64 tx_drop;
> > > > + le64 tx_drop_malformed;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_csum {
> > > > + le64 tx_csum_none;
> > > > + le64 tx_needs_csum;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_gso {
> > > > + le64 tx_gso_packets;
> > > > + le64 tx_gso_bytes;
> > > > + le64 tx_gso_packets_split;
> > > > + le64 tx_gso_bytes_split;
> > > > + le64 tx_gso_segments;
> > > > + le64 tx_gso_segments_bytes;
> > > > +};
> > > > +
> > > > +struct virtio_net_stats_tx_reset {
> > > > + le64 tx_reset;
> > > > +};
> > > > +
> > > > +\end{lstlisting}
> > > > +
> > > > +\begin{description}
> > > > + \item [nstats]
> > > > + The number of \field{stats}.
> > > > +
> > > > + \item [queue_num]
> > > > + The number of the virtqueue to obtain the statistics.
> > > > +
> > > > + \item [type]
> > > > + The type of the stats to be obtained.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +Correspondence between the vq type, the stats type, the stats structure
> > > and the
> > > > +required features.
> > > > +\begin{tabular}{ |l|l|l|l| }
> > > > + \hline
> > > > + VQ Type & Stats Type & Stats
> > > Structure & Features \\ \hline
> > > > +
> > > > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> > > virtio_net_stats_cvq & \\ \hline
> > > > +
> > > > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> > > virtio_net_stats_rx_basic & \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> > > virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> > > virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > > > +
> > > VIRTIO_NET_F_GUEST_TSO6 or\newline
> > > > +
> > > VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> > > virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > > > +
> > > > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> > > virtio_net_stats_tx_basic & \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> > > virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> > > virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > > > +
> > > VIRTIO_NET_F_HOST_TSO6 or\newline
> > > > +
> > > VIRTIO_NET_F_HOST_USO or\newline
> > > > +
> > > VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > > > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> > > virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > > > + \hline
> > > > +\end{tabular}
> > > > +
> > > > +
> > > > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> > > Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > > > +
> > > > +The structure corresponding to the controlq stats is
> > > virtio_net_stats_cvq.
> > > > +
> > > > +\begin{description}
> > > > + \item [command_num]
> > > > + The number of commands, including the current command.
> > > > +
> > > > + \item [ok_num]
> > > > + The number of commands (including the current command) where
> > > the ack was VIRTIO_NET_OK.
> > > > +\end{description}
> > > > +
> > > > +
> > > > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > Basic Stats}
> > > > +
> > > > +The structure corresponding to the receiveq basic stats is
> > > virtio_net_stats_rx_basic.
> > > > +
> > > > +Receiveq basic stats doesn't need any features, as long as the device
> > > supports
> > > > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_packets]
> > > > + The number of packets received by device (not the packets
> > > passed to the
> > > > + guest), including the dropped packets by device.
> > > > +
> > > > + \item [rx_bytes]
> > > > + The number of bytes received by device (not the packets passed
> > > to the
> > > > + guest), including the dropped packets by device.
> > > > +
> > > > + \item [rx_notification]
> > > > + The number of driver notifications.
> > > > +
> > > > + \item [rx_interrupt]
> > > > + The number of device interrupts.
> > > > +
> > > > + \item [rx_drop]
> > > > + The number of packets dropped by the receiveq. Contains all
> > > kinds of
> > > > + packet drop.
> > > > +
> > > > + \item [rx_drop_overruns]
> > > > + The number of packets dropped by the receiveq when no more
> > > descriptors
> > > > + were available.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > Basic Stats}
> > > > +
> > > > +The structure corresponding to the transmitq basic stats is
> > > virtio_net_stats_tx_basic.
> > > > +
> > > > +Transmitq basic stats doesn't need any features, as long as the device
> > > supports
> > > > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_packets]
> > > > + The number of packets sent by device (not the packets got from
> > > the
> > > > + guest), excluding the dropped packets by device.
> > > > +
> > > > + \item [tx_bytes]
> > > > + The number of bytes sent by device (not the packets got from the
> > > > + guest), excluding the dropped packets by device.
> > > > +
> > > > + \item [tx_notification]
> > > > + The number of driver notifications.
> > > > +
> > > > + \item [tx_interrupt]
> > > > + The number of device interrupts.
> > > > +
> > > > + \item [tx_drop]
> > > > + The number of packets dropped by the transmitq. Contains all
> > > kinds of
> > > > + packet drop.
> > > > +
> > > > + \item [tx_drop_malformed]
> > > > + The number of packets dropped when the descriptor is in an
> > > error state.
> > > > + For example, the buffer is too short.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > CSUM Stats}
> > > > +
> > > > +The structure corresponding to the receiveq csum stats is
> > > virtio_net_stats_rx_csum.
> > > > +
> > > > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> > > receiveq
> > > > +csum stats can be obtained.
> > > > +
> > > > +The following are the receiveq csum stats:
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_csum_valid]
> > > > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > > > +
> > > > + \item [rx_needs_csum]
> > > > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > > > +
> > > > + \item [rx_csum_bad]
> > > > + The number of packets with abnormal csum.
> > > > +
> > > > + \item [rx_csum_none]
> > > > + The number of packets without hardware csum. The packet here
> > > refers to
> > > > + the non-TCP/UDP packet that the backend cannot recognize.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > CSUM Stats}
> > > > +
> > > > +The structure corresponding to the transmitq csum stats is
> > > virtio_net_stats_tx_csum.
> > > > +
> > > > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> > > transmitq csum
> > > > +stats can be obtained.
> > > > +
> > > > +The following are the transmitq csum stats:
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_csum_none]
> > > > + The number of packets that didn't require hardware csum.
> > > > +
> > > > + \item [tx_needs_csum]
> > > > + The number of packets that required hardware csum.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> > > Stats}
> > > > +
> > > > +The structure corresponding to the receiveq gso stats is
> > > virtio_net_stats_rx_gso.
> > > > +
> > > > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > > > +been negotiated, the receiveq gso stats can be obtained.
> > > > +
> > > > +Rx gso packets refer to packets passed by the device to the driver where
> > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_gso_packets]
> > > > + The number of the rx gso packets.
> > > > +
> > > > + \item [rx_gso_bytes]
> > > > + The number of bytes(excluding the virtio net header) of the rx
> > > gso packets.
> > > > +
> > > > + \item [rx_gso_packets_coalesced]
> > > > + The number of the rx gso packages generated by coalescing.
> > > > +
> > > > + \item [rx_gso_bytes_coalesced]
> > > > + The number of bytes(excluding the virtio net header) of the rx
> > > gso packets generated by coalescing.
> > > > +
> > > > + \item [rx_gso_segments]
> > > > + The number of coalesced segments.
> > > > +
> > > > + \item [rx_gso_segments_bytes]
> > > > + The number of bytes of coalesced segments.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > GSO Stats}
> > > > +
> > > > +The structure corresponding to the transmitq gso stats is
> > > virtio_net_stats_tx_gso.
> > > > +
> > > > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > > > +been negotiated, the transmitq gso stats can be obtained.
> > > > +
> > > > +Tx gso packets refer to packets passed by the driver to the device where
> > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_gso_packets]
> > > > + The number of the tx gso packets.
> > > > +
> > > > + \item [tx_gso_bytes]
> > > > + The number of bytes(excluding the virtio net header) of the tx
> > > gso packets.
> > > > +
> > > > + \item [tx_gso_packets_split]
> > > > + The number of the tx gso packets that been split.
> > > > +
> > > > + \item [tx_gso_bytes_split]
> > > > + The number of bytes(excluding the virtio net header) of the tx
> > > gso packets that been split.
> > > > +
> > > > + \item [tx_gso_segments]
> > > > + The number of segments split from the gso package.
> > > > +
> > > > + \item [tx_gso_segments_bytes]
> > > > + The number of bytes(excluding the virtio net header) of
> > > segments split from the gso package.
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > Reset Stats}
> > > > +
> > > > +The structure corresponding to the receiveq reset stats is
> > > virtio_net_stats_rx_reset.
> > > > +
> > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> > > reset stats
> > > > +can be obtained.
> > > > +
> > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > Virtqueue Reset}
> > > > +for more about \field{rx_reset}.
> > > > +
> > > > +\begin{description}
> > > > + \item [rx_reset]
> > > > + The number of receiveq resets.
> > > > +\end{description}
> > > > +
> > > > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > Reset Stats}
> > > > +
> > > > +The structure corresponding to the transmitq reset stats is
> > > virtio_net_stats_tx_reset.
> > > > +
> > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> > > reset stats
> > > > +can be obtained.
> > > > +
> > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > Virtqueue Reset}
> > > > +for more about \field{tx_reset}.
> > > > +
> > > > +\begin{description}
> > > > + \item [tx_reset]
> > > > + The number of transmitq resets.
> > > > +\end{description}
> > > > +
> > > > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > +
> > > > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> > > the device
> > > > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > > > +the device MUST abort the entire command.
> > > > +\begin{itemize}
> > > > + \item \field{queue_num} exceeds the queue range.
> > > > + \item \field{type} is not a known value.
> > > > + \item The type of vq does not match \field{type}. E.g. the driver
> > > tries to query
> > > > + RX stats through a TX index.
> > > > + \item The feature corresponding to the specified \field{type} was
> > > not successfully
> > > > + negotiated.
> > > > + \item The size of the buffer allocated by the driver for
> > > \field{command-specific-data-reply}
> > > > + is less than the total size of the stats specialed by
> > > > + \field{virtio_net_ctrl_queue_stats}.
> > > > +\end{itemize}
> > > > +
> > > > +The device MUST write the requested stats structures in
> > > > +\field{command-specific-data-reply} in the order specified by the
> > > structure
> > > > +virtio_net_ctrl_queue_stats.
> > > > +
> > > > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > +
> > > > +When a driver tries to obtain a certain stats, it MUST confirm that the
> > > relevant
> > > > +feature negotiation is successful.
> > > > +
> > > > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> > > the vq
> > > > +specified by \field{queue_num}.
> > > > +
> > > > +The \field{command-specific-data-reply} buffer allocated by the driver
> > > MUST be
> > > > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > > > +
> > > > +When the driver reads the response, it MUST read
> > > > +\field{command-specific-data-reply} one by one based on the
> > > \field{type}.
> > > >
> > > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > > Types / Network Device / Legacy Interface: Framing Requirements}
> > > > --
> > > > 2.31.0
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > >
> > >
> > >
> >
>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] Re: [virtio-comment] Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
2023-07-13 2:21 ` [virtio-comment] " Jason Wang
@ 2023-07-13 2:27 ` Xuan Zhuo
-1 siblings, 0 replies; 21+ messages in thread
From: Xuan Zhuo @ 2023-07-13 2:27 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
On Thu, 13 Jul 2023 10:21:23 +0800, Jason Wang <jasowang@redhat.com> wrote:
> On Wed, Jul 12, 2023 at 5:19 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> >
> > On Wed, 12 Jul 2023 16:08:48 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > > On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > wrote:
> > >
> > > > hi, guys
> > > >
> > > > After a lot of internal discussions, I removed some unimportant counters.
> > > > Based
> > > > on this v12 patch I am repling to, most of the requirements have been met.
> > > >
> > > > The patch link
> > > > https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
> > > >
> > > > We still have these counters, let's see if they can be standardized.
> > > >
> > > > ## limit
> > > >
> > > > * tx_bps_limit_drops
> > > > * tx_pps_limit_drops
> > > > * rx_bps_limit_drops
> > > > * rx_pps_limit_drops
> > > >
> > > > In a cloud scenario, multiple users purchase different VMs, and these VMs
> > > > share
> > > > the capabilities of the same host. In order to ensure that each VM will not
> > > > affect others, the network card(virtio-net) capability of each VM is
> > > > limited.
> > > > These users purchase VMs, this limit has already been determined.
> > > >
> > >
> > > This seems a feature beyond the counters but QOS. I think we virtio spec
> > > need to support QOS before we can discuss any QOS related counters.
> > >
> > >
> > > >
> > > > So if the network card traffic of a vm exceeds the upper limit, packet
> > > > loss will
> > > > occur. It is necessary for us to count these packet losses. And the device
> > > > should expose to the user.
> > > >
> > > > ## session
> > > >
> > > > * tx_session_full_drops The number of packet drops in the sending
> > > > direction when
> > > > the session is full
> > > > * rx_session_full_drops The number of packets lost when the session is
> > > > full in the receiving direction
> > > >
> > > > Our dpu supports tcp connection tracking, but there is an upper limit to
> > > > the
> > > > number of connections, and if it exceeds, packet loss will also occur.
> > > >
> > >
> > > Similarly, if connect tracking offload is supported, it needs to be
> > > implemented in the spec first then we can have related counters.
> > >
> > >
> > > >
> > > > ## ACL
> > > >
> > > > * tx_acl_drops ACL packet loss in the sending direction
> > > > * rx_acl_drops The number of ACL packets lost in the receiving direction
> > > >
> > > > In our cloud service, for network cards, users are allowed to configure
> > > > security
> > > > rules,such as which IPs can access which ports of this machine.
> > > >
> > >
> > > Same as above, ACL should be supported by the spec first then the counters.
> > >
> > > In conclusion, the features must be self contained. Otherwise you are doing
> > > vDPA actually and those counters need to be accessed in a vendor specific
> > > way.
> >
> > Yes that's the point, as we've discussed here.
> >
> > http://lore.kernel.org/all/1686550355.2503424-1-xuanzhuo@linux.alibaba.com
> >
> > There are many similar counters. There may not be many usage scenarios, so I
> > didn't list them here.
> >
> > Our acl, seesion, and limit are not configured by the user at the driver layer,
> > and I don't think these should be configured at the driver.
>
> Sounds like something related to OPI. But if the features were not
> configured by driver, any reason to let it be noticeable by it?
I also think that we should not define these counters in the spec.
>
> Exposing things like tx_acl_drops may have security implications,
> enabling software to probe the ACL rules?
>
It is true that this may make the user guess the acl rules. But this is not
important, because the rules themselves are defined by the user, we just want
the user to know what is the reason for the packet loss. Getting this
information from the guest os based on the driver is user friendly.
In-depth thinking, the conflict here comes from the way cloud manufacturers use
virtio. The cloud vendor controls the device, while the user is on the driver
side. And our definition of spec is more like a traditional physical network
card, all operations are initiated by the driver.
For example, ACL rules, users prefer to create a set of ACL rules and apply them
to all network cards when creating 100 network cards. Instead of entering each
OS, configure these rules for each device from the driver.
And these operations are all done on OPI, so we have some things outside the
spec standard. I agree with the rules of our spec. So I want to introduce some
mechanism to solve these problems without breaking the current requirements.
Thanks.
> Thanks
>
> > So at least as
> > far as our usage scenarios are concerned, these are some functions that have
> > nothing to do with virtio spec.
> >
> > So what I want most is that the virto spec supports a vendor channel.
> >
> > Of course, I am ok with Parav's abstraction of "limit".
> >
> > Some implementations of txq are lossy and some are not creating backpressure/flow control to driver so driver can rate limit it naturally.
> > So a tx packet drop counter is needed to cover the lossy implementations which is abstract enough regardless of reason on why device dropped it.
> > A more granular counter becomes vendor specific that we can possibly avoid or place under different command.
> >
> > But acl and session may not be very good to abstract.
> >
> > Thanks.
> >
> >
> > >
> > > Thanks
> > >
> > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > > On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > wrote:
> > > > > This patch allows the driver to obtain some statistics from the device.
> > > > >
> > > > > In the back-end implementation, we can count a lot of such information,
> > > > > which can be used for debugging and judging the running status of the
> > > > > back-end. We hope to directly display it to the user through ethtool.
> > > > >
> > > > > To get stats atomically, try to get stats for all queue pairs in one
> > > > > command.
> > > > >
> > > > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > ---
> > > > > conformance.tex | 2 +
> > > > > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > > > > 2 files changed, 405 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/conformance.tex b/conformance.tex
> > > > > index 42f8537..c67f877 100644
> > > > > --- a/conformance.tex
> > > > > +++ b/conformance.tex
> > > > > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > > / Conformance Targets}
> > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > > mode}
> > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Offloads State Configuration / Setting
> > > > Offloads State}
> > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > > > +\item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Device Stats}
> > > > > \end{itemize}
> > > > >
> > > > > \conformance{\subsection}{Block Driver
> > > > Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> > > > Conformance}
> > > > > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > > / Conformance Targets}
> > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > > mode}
> > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > > > > +\item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Device Stats}
> > > > > \end{itemize}
> > > > >
> > > > > \conformance{\subsection}{Block Device
> > > > Conformance}\label{sec:Conformance / Device Conformance / Block Device
> > > > Conformance}
> > > > > diff --git a/content.tex b/content.tex
> > > > > index c6f116c..81f325d 100644
> > > > > --- a/content.tex
> > > > > +++ b/content.tex
> > > > > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> > > > Network Device / Feature bits
> > > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > > > > channel.
> > > > >
> > > > > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> > > > statistics
> > > > > + to the driver through the control channel.
> > > > > +
> > > > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> > > > Unlike UFO
> > > > > (fragmenting the packet) the USO splits large UDP packet
> > > > > to several segments when each of these smaller packets has UDP header.
> > > > > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> > > > requirements}\label{sec:Device Types / Network Device
> > > > > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> > > > VIRTIO_NET_F_HOST_TSO6.
> > > > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \end{description}
> > > > > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > > > Types / Network Device / Devi
> > > > > u8 command;
> > > > > u8 command-specific-data[];
> > > > > u8 ack;
> > > > > + u8 command-specific-data-reply[];
> > > > > };
> > > > >
> > > > > /* ack values */
> > > > > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> > > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > > \end{lstlisting}
> > > > >
> > > > > The \field{class}, \field{command} and command-specific-data are set by
> > > > the
> > > > > -driver, and the device sets the \field{ack} byte. There is little it can
> > > > > -do except issue a diagnostic if \field{ack} is not
> > > > > -VIRTIO_NET_OK.
> > > > > +driver, and the device sets the \field{ack} byte and optionally
> > > > > +\field{command-specific-data-reply}. There is little the driver can
> > > > > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > > > > +
> > > > > +The command VIRTIO_NET_CTRL_STATS_GET contains
> > > > \field{command-specific-data-reply}.
> > > > >
> > > > > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > > > > \label{sec:Device Types / Network Device / Device Operation / Control
> > > > Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > > > > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> > > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > > according to the native endian of the guest rather than
> > > > > (necessarily when not using the legacy interface) little-endian.
> > > > >
> > > > > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> > > > Device Operation / Control Virtqueue / Device Stats}
> > > > > +
> > > > > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > > > > +get the device stats from the device in
> > > > \field{command-specific-data-reply}.
> > > > > +
> > > > > +To get the stats, the following definitions are used:
> > > > > +\begin{lstlisting}
> > > > > +#define VIRTIO_NET_CTRL_STATS 6
> > > > > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > > > > +
> > > > > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > > > > +
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> > > > \field{command-specific-data}
> > > > > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > > > > +The result is returned by \field{command-specific-data-reply}.
> > > > > +The stats ware returned in the order of the type specified in the
> > > > > +\field{virtio_net_ctrl_queue_stats}.
> > > > > +
> > > > > +The following layout structures are used:
> > > > > +
> > > > > +\field{command-specific-data}
> > > > > +\begin{lstlisting}
> > > > > +struct virtio_net_ctrl_queue_stats {
> > > > > + u16 nstats;
> > > > > + struct {
> > > > > + u16 queue_num;
> > > > > + u16 type;
> > > > > + } stats[];
> > > > > +};
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +\field{command-specific-data-reply}
> > > > > +\begin{lstlisting}
> > > > > +struct virtio_net_stats_cvq {
> > > > > + le64 command_num;
> > > > > + le64 ok_num;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_basic {
> > > > > + le64 rx_packets;
> > > > > + le64 rx_bytes;
> > > > > +
> > > > > + le64 rx_notification;
> > > > > + le64 rx_interrupt;
> > > > > +
> > > > > + le64 rx_drop;
> > > > > + le64 rx_drop_overruns;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_csum {
> > > > > + le64 rx_csum_valid;
> > > > > + le64 rx_needs_csum;
> > > > > + le64 rx_csum_bad;
> > > > > + le64 rx_csum_none;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_gso {
> > > > > + le64 rx_gso_packets;
> > > > > + le64 rx_gso_bytes;
> > > > > + le64 rx_gso_packets_coalesced;
> > > > > + le64 rx_gso_bytes_coalesced;
> > > > > + le64 rx_gso_segments;
> > > > > + le64 rx_gso_segments_bytes;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_reset {
> > > > > + le64 rx_reset;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_basic {
> > > > > + le64 tx_packets;
> > > > > + le64 tx_bytes;
> > > > > +
> > > > > + le64 tx_notification;
> > > > > + le64 tx_interrupt;
> > > > > +
> > > > > + le64 tx_drop;
> > > > > + le64 tx_drop_malformed;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_csum {
> > > > > + le64 tx_csum_none;
> > > > > + le64 tx_needs_csum;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_gso {
> > > > > + le64 tx_gso_packets;
> > > > > + le64 tx_gso_bytes;
> > > > > + le64 tx_gso_packets_split;
> > > > > + le64 tx_gso_bytes_split;
> > > > > + le64 tx_gso_segments;
> > > > > + le64 tx_gso_segments_bytes;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_reset {
> > > > > + le64 tx_reset;
> > > > > +};
> > > > > +
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [nstats]
> > > > > + The number of \field{stats}.
> > > > > +
> > > > > + \item [queue_num]
> > > > > + The number of the virtqueue to obtain the statistics.
> > > > > +
> > > > > + \item [type]
> > > > > + The type of the stats to be obtained.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +Correspondence between the vq type, the stats type, the stats structure
> > > > and the
> > > > > +required features.
> > > > > +\begin{tabular}{ |l|l|l|l| }
> > > > > + \hline
> > > > > + VQ Type & Stats Type & Stats
> > > > Structure & Features \\ \hline
> > > > > +
> > > > > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> > > > virtio_net_stats_cvq & \\ \hline
> > > > > +
> > > > > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> > > > virtio_net_stats_rx_basic & \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> > > > virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> > > > virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > > > > +
> > > > VIRTIO_NET_F_GUEST_TSO6 or\newline
> > > > > +
> > > > VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> > > > virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > > > > +
> > > > > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> > > > virtio_net_stats_tx_basic & \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> > > > virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> > > > virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > > > > +
> > > > VIRTIO_NET_F_HOST_TSO6 or\newline
> > > > > +
> > > > VIRTIO_NET_F_HOST_USO or\newline
> > > > > +
> > > > VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> > > > virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > > > > + \hline
> > > > > +\end{tabular}
> > > > > +
> > > > > +
> > > > > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> > > > Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > > > > +
> > > > > +The structure corresponding to the controlq stats is
> > > > virtio_net_stats_cvq.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [command_num]
> > > > > + The number of commands, including the current command.
> > > > > +
> > > > > + \item [ok_num]
> > > > > + The number of commands (including the current command) where
> > > > the ack was VIRTIO_NET_OK.
> > > > > +\end{description}
> > > > > +
> > > > > +
> > > > > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > > Basic Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq basic stats is
> > > > virtio_net_stats_rx_basic.
> > > > > +
> > > > > +Receiveq basic stats doesn't need any features, as long as the device
> > > > supports
> > > > > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_packets]
> > > > > + The number of packets received by device (not the packets
> > > > passed to the
> > > > > + guest), including the dropped packets by device.
> > > > > +
> > > > > + \item [rx_bytes]
> > > > > + The number of bytes received by device (not the packets passed
> > > > to the
> > > > > + guest), including the dropped packets by device.
> > > > > +
> > > > > + \item [rx_notification]
> > > > > + The number of driver notifications.
> > > > > +
> > > > > + \item [rx_interrupt]
> > > > > + The number of device interrupts.
> > > > > +
> > > > > + \item [rx_drop]
> > > > > + The number of packets dropped by the receiveq. Contains all
> > > > kinds of
> > > > > + packet drop.
> > > > > +
> > > > > + \item [rx_drop_overruns]
> > > > > + The number of packets dropped by the receiveq when no more
> > > > descriptors
> > > > > + were available.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > Basic Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq basic stats is
> > > > virtio_net_stats_tx_basic.
> > > > > +
> > > > > +Transmitq basic stats doesn't need any features, as long as the device
> > > > supports
> > > > > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_packets]
> > > > > + The number of packets sent by device (not the packets got from
> > > > the
> > > > > + guest), excluding the dropped packets by device.
> > > > > +
> > > > > + \item [tx_bytes]
> > > > > + The number of bytes sent by device (not the packets got from the
> > > > > + guest), excluding the dropped packets by device.
> > > > > +
> > > > > + \item [tx_notification]
> > > > > + The number of driver notifications.
> > > > > +
> > > > > + \item [tx_interrupt]
> > > > > + The number of device interrupts.
> > > > > +
> > > > > + \item [tx_drop]
> > > > > + The number of packets dropped by the transmitq. Contains all
> > > > kinds of
> > > > > + packet drop.
> > > > > +
> > > > > + \item [tx_drop_malformed]
> > > > > + The number of packets dropped when the descriptor is in an
> > > > error state.
> > > > > + For example, the buffer is too short.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > > CSUM Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq csum stats is
> > > > virtio_net_stats_rx_csum.
> > > > > +
> > > > > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> > > > receiveq
> > > > > +csum stats can be obtained.
> > > > > +
> > > > > +The following are the receiveq csum stats:
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_csum_valid]
> > > > > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > > > > +
> > > > > + \item [rx_needs_csum]
> > > > > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > > > > +
> > > > > + \item [rx_csum_bad]
> > > > > + The number of packets with abnormal csum.
> > > > > +
> > > > > + \item [rx_csum_none]
> > > > > + The number of packets without hardware csum. The packet here
> > > > refers to
> > > > > + the non-TCP/UDP packet that the backend cannot recognize.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > CSUM Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq csum stats is
> > > > virtio_net_stats_tx_csum.
> > > > > +
> > > > > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> > > > transmitq csum
> > > > > +stats can be obtained.
> > > > > +
> > > > > +The following are the transmitq csum stats:
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_csum_none]
> > > > > + The number of packets that didn't require hardware csum.
> > > > > +
> > > > > + \item [tx_needs_csum]
> > > > > + The number of packets that required hardware csum.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> > > > Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq gso stats is
> > > > virtio_net_stats_rx_gso.
> > > > > +
> > > > > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > > > > +been negotiated, the receiveq gso stats can be obtained.
> > > > > +
> > > > > +Rx gso packets refer to packets passed by the device to the driver where
> > > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_gso_packets]
> > > > > + The number of the rx gso packets.
> > > > > +
> > > > > + \item [rx_gso_bytes]
> > > > > + The number of bytes(excluding the virtio net header) of the rx
> > > > gso packets.
> > > > > +
> > > > > + \item [rx_gso_packets_coalesced]
> > > > > + The number of the rx gso packages generated by coalescing.
> > > > > +
> > > > > + \item [rx_gso_bytes_coalesced]
> > > > > + The number of bytes(excluding the virtio net header) of the rx
> > > > gso packets generated by coalescing.
> > > > > +
> > > > > + \item [rx_gso_segments]
> > > > > + The number of coalesced segments.
> > > > > +
> > > > > + \item [rx_gso_segments_bytes]
> > > > > + The number of bytes of coalesced segments.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > GSO Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq gso stats is
> > > > virtio_net_stats_tx_gso.
> > > > > +
> > > > > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > > > > +been negotiated, the transmitq gso stats can be obtained.
> > > > > +
> > > > > +Tx gso packets refer to packets passed by the driver to the device where
> > > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_gso_packets]
> > > > > + The number of the tx gso packets.
> > > > > +
> > > > > + \item [tx_gso_bytes]
> > > > > + The number of bytes(excluding the virtio net header) of the tx
> > > > gso packets.
> > > > > +
> > > > > + \item [tx_gso_packets_split]
> > > > > + The number of the tx gso packets that been split.
> > > > > +
> > > > > + \item [tx_gso_bytes_split]
> > > > > + The number of bytes(excluding the virtio net header) of the tx
> > > > gso packets that been split.
> > > > > +
> > > > > + \item [tx_gso_segments]
> > > > > + The number of segments split from the gso package.
> > > > > +
> > > > > + \item [tx_gso_segments_bytes]
> > > > > + The number of bytes(excluding the virtio net header) of
> > > > segments split from the gso package.
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > > Reset Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq reset stats is
> > > > virtio_net_stats_rx_reset.
> > > > > +
> > > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> > > > reset stats
> > > > > +can be obtained.
> > > > > +
> > > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > > Virtqueue Reset}
> > > > > +for more about \field{rx_reset}.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_reset]
> > > > > + The number of receiveq resets.
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > Reset Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq reset stats is
> > > > virtio_net_stats_tx_reset.
> > > > > +
> > > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> > > > reset stats
> > > > > +can be obtained.
> > > > > +
> > > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > > Virtqueue Reset}
> > > > > +for more about \field{tx_reset}.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_reset]
> > > > > + The number of transmitq resets.
> > > > > +\end{description}
> > > > > +
> > > > > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > > +
> > > > > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> > > > the device
> > > > > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > > > > +the device MUST abort the entire command.
> > > > > +\begin{itemize}
> > > > > + \item \field{queue_num} exceeds the queue range.
> > > > > + \item \field{type} is not a known value.
> > > > > + \item The type of vq does not match \field{type}. E.g. the driver
> > > > tries to query
> > > > > + RX stats through a TX index.
> > > > > + \item The feature corresponding to the specified \field{type} was
> > > > not successfully
> > > > > + negotiated.
> > > > > + \item The size of the buffer allocated by the driver for
> > > > \field{command-specific-data-reply}
> > > > > + is less than the total size of the stats specialed by
> > > > > + \field{virtio_net_ctrl_queue_stats}.
> > > > > +\end{itemize}
> > > > > +
> > > > > +The device MUST write the requested stats structures in
> > > > > +\field{command-specific-data-reply} in the order specified by the
> > > > structure
> > > > > +virtio_net_ctrl_queue_stats.
> > > > > +
> > > > > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > > +
> > > > > +When a driver tries to obtain a certain stats, it MUST confirm that the
> > > > relevant
> > > > > +feature negotiation is successful.
> > > > > +
> > > > > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> > > > the vq
> > > > > +specified by \field{queue_num}.
> > > > > +
> > > > > +The \field{command-specific-data-reply} buffer allocated by the driver
> > > > MUST be
> > > > > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > > > > +
> > > > > +When the driver reads the response, it MUST read
> > > > > +\field{command-specific-data-reply} one by one based on the
> > > > \field{type}.
> > > > >
> > > > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > > > Types / Network Device / Legacy Interface: Framing Requirements}
> > > > > --
> > > > > 2.31.0
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > > >
> > > >
> > > >
> > >
> >
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [virtio-comment] Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
@ 2023-07-13 2:27 ` Xuan Zhuo
0 siblings, 0 replies; 21+ messages in thread
From: Xuan Zhuo @ 2023-07-13 2:27 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, virtio-dev, Parav Pandit, virtio-comment
On Thu, 13 Jul 2023 10:21:23 +0800, Jason Wang <jasowang@redhat.com> wrote:
> On Wed, Jul 12, 2023 at 5:19 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> >
> > On Wed, 12 Jul 2023 16:08:48 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > > On Mon, Jul 10, 2023 at 3:32 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > wrote:
> > >
> > > > hi, guys
> > > >
> > > > After a lot of internal discussions, I removed some unimportant counters.
> > > > Based
> > > > on this v12 patch I am repling to, most of the requirements have been met.
> > > >
> > > > The patch link
> > > > https://lore.kernel.org/all/20220315032402.6088-1-xuanzhuo@linux.alibaba.com/
> > > >
> > > > We still have these counters, let's see if they can be standardized.
> > > >
> > > > ## limit
> > > >
> > > > * tx_bps_limit_drops
> > > > * tx_pps_limit_drops
> > > > * rx_bps_limit_drops
> > > > * rx_pps_limit_drops
> > > >
> > > > In a cloud scenario, multiple users purchase different VMs, and these VMs
> > > > share
> > > > the capabilities of the same host. In order to ensure that each VM will not
> > > > affect others, the network card(virtio-net) capability of each VM is
> > > > limited.
> > > > These users purchase VMs, this limit has already been determined.
> > > >
> > >
> > > This seems a feature beyond the counters but QOS. I think we virtio spec
> > > need to support QOS before we can discuss any QOS related counters.
> > >
> > >
> > > >
> > > > So if the network card traffic of a vm exceeds the upper limit, packet
> > > > loss will
> > > > occur. It is necessary for us to count these packet losses. And the device
> > > > should expose to the user.
> > > >
> > > > ## session
> > > >
> > > > * tx_session_full_drops The number of packet drops in the sending
> > > > direction when
> > > > the session is full
> > > > * rx_session_full_drops The number of packets lost when the session is
> > > > full in the receiving direction
> > > >
> > > > Our dpu supports tcp connection tracking, but there is an upper limit to
> > > > the
> > > > number of connections, and if it exceeds, packet loss will also occur.
> > > >
> > >
> > > Similarly, if connect tracking offload is supported, it needs to be
> > > implemented in the spec first then we can have related counters.
> > >
> > >
> > > >
> > > > ## ACL
> > > >
> > > > * tx_acl_drops ACL packet loss in the sending direction
> > > > * rx_acl_drops The number of ACL packets lost in the receiving direction
> > > >
> > > > In our cloud service, for network cards, users are allowed to configure
> > > > security
> > > > rules,such as which IPs can access which ports of this machine.
> > > >
> > >
> > > Same as above, ACL should be supported by the spec first then the counters.
> > >
> > > In conclusion, the features must be self contained. Otherwise you are doing
> > > vDPA actually and those counters need to be accessed in a vendor specific
> > > way.
> >
> > Yes that's the point, as we've discussed here.
> >
> > http://lore.kernel.org/all/1686550355.2503424-1-xuanzhuo@linux.alibaba.com
> >
> > There are many similar counters. There may not be many usage scenarios, so I
> > didn't list them here.
> >
> > Our acl, seesion, and limit are not configured by the user at the driver layer,
> > and I don't think these should be configured at the driver.
>
> Sounds like something related to OPI. But if the features were not
> configured by driver, any reason to let it be noticeable by it?
I also think that we should not define these counters in the spec.
>
> Exposing things like tx_acl_drops may have security implications,
> enabling software to probe the ACL rules?
>
It is true that this may make the user guess the acl rules. But this is not
important, because the rules themselves are defined by the user, we just want
the user to know what is the reason for the packet loss. Getting this
information from the guest os based on the driver is user friendly.
In-depth thinking, the conflict here comes from the way cloud manufacturers use
virtio. The cloud vendor controls the device, while the user is on the driver
side. And our definition of spec is more like a traditional physical network
card, all operations are initiated by the driver.
For example, ACL rules, users prefer to create a set of ACL rules and apply them
to all network cards when creating 100 network cards. Instead of entering each
OS, configure these rules for each device from the driver.
And these operations are all done on OPI, so we have some things outside the
spec standard. I agree with the rules of our spec. So I want to introduce some
mechanism to solve these problems without breaking the current requirements.
Thanks.
> Thanks
>
> > So at least as
> > far as our usage scenarios are concerned, these are some functions that have
> > nothing to do with virtio spec.
> >
> > So what I want most is that the virto spec supports a vendor channel.
> >
> > Of course, I am ok with Parav's abstraction of "limit".
> >
> > Some implementations of txq are lossy and some are not creating backpressure/flow control to driver so driver can rate limit it naturally.
> > So a tx packet drop counter is needed to cover the lossy implementations which is abstract enough regardless of reason on why device dropped it.
> > A more granular counter becomes vendor specific that we can possibly avoid or place under different command.
> >
> > But acl and session may not be very good to abstract.
> >
> > Thanks.
> >
> >
> > >
> > > Thanks
> > >
> > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > > On Tue, 15 Mar 2022 11:24:02 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > wrote:
> > > > > This patch allows the driver to obtain some statistics from the device.
> > > > >
> > > > > In the back-end implementation, we can count a lot of such information,
> > > > > which can be used for debugging and judging the running status of the
> > > > > back-end. We hope to directly display it to the user through ethtool.
> > > > >
> > > > > To get stats atomically, try to get stats for all queue pairs in one
> > > > > command.
> > > > >
> > > > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > ---
> > > > > conformance.tex | 2 +
> > > > > content.tex | 406 +++++++++++++++++++++++++++++++++++++++++++++++-
> > > > > 2 files changed, 405 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/conformance.tex b/conformance.tex
> > > > > index 42f8537..c67f877 100644
> > > > > --- a/conformance.tex
> > > > > +++ b/conformance.tex
> > > > > @@ -142,6 +142,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > > / Conformance Targets}
> > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > > mode}
> > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Offloads State Configuration / Setting
> > > > Offloads State}
> > > > > \item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Receive-side scaling (RSS) }
> > > > > +\item \ref{drivernormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Device Stats}
> > > > > \end{itemize}
> > > > >
> > > > > \conformance{\subsection}{Block Driver
> > > > Conformance}\label{sec:Conformance / Driver Conformance / Block Driver
> > > > Conformance}
> > > > > @@ -401,6 +402,7 @@ \section{Conformance Targets}\label{sec:Conformance
> > > > / Conformance Targets}
> > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Gratuitous Packet Sending}
> > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Automatic receive steering in multiqueue
> > > > mode}
> > > > > \item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing}
> > > > > +\item \ref{devicenormative:Device Types / Network Device / Device
> > > > Operation / Control Virtqueue / Device Stats}
> > > > > \end{itemize}
> > > > >
> > > > > \conformance{\subsection}{Block Device
> > > > Conformance}\label{sec:Conformance / Device Conformance / Block Device
> > > > Conformance}
> > > > > diff --git a/content.tex b/content.tex
> > > > > index c6f116c..81f325d 100644
> > > > > --- a/content.tex
> > > > > +++ b/content.tex
> > > > > @@ -3092,6 +3092,9 @@ \subsection{Feature bits}\label{sec:Device Types /
> > > > Network Device / Feature bits
> > > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
> > > > > channel.
> > > > >
> > > > > +\item[VIRTIO_NET_F_CTRL_STATS(55)] Device can provide device-level
> > > > statistics
> > > > > + to the driver through the control channel.
> > > > > +
> > > > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets.
> > > > Unlike UFO
> > > > > (fragmenting the packet) the USO splits large UDP packet
> > > > > to several segments when each of these smaller packets has UDP header.
> > > > > @@ -3137,6 +3140,7 @@ \subsubsection{Feature bit
> > > > requirements}\label{sec:Device Types / Network Device
> > > > > \item[VIRTIO_NET_F_GUEST_ANNOUNCE] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \item[VIRTIO_NET_F_MQ] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > +\item[VIRTIO_NET_F_CTRL_STATS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or
> > > > VIRTIO_NET_F_HOST_TSO6.
> > > > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > > > \end{description}
> > > > > @@ -4015,6 +4019,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> > > > Types / Network Device / Devi
> > > > > u8 command;
> > > > > u8 command-specific-data[];
> > > > > u8 ack;
> > > > > + u8 command-specific-data-reply[];
> > > > > };
> > > > >
> > > > > /* ack values */
> > > > > @@ -4023,9 +4028,11 @@ \subsubsection{Control
> > > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > > \end{lstlisting}
> > > > >
> > > > > The \field{class}, \field{command} and command-specific-data are set by
> > > > the
> > > > > -driver, and the device sets the \field{ack} byte. There is little it can
> > > > > -do except issue a diagnostic if \field{ack} is not
> > > > > -VIRTIO_NET_OK.
> > > > > +driver, and the device sets the \field{ack} byte and optionally
> > > > > +\field{command-specific-data-reply}. There is little the driver can
> > > > > +do except issue a diagnostic if \field{ack} is not VIRTIO_NET_OK.
> > > > > +
> > > > > +The command VIRTIO_NET_CTRL_STATS_GET contains
> > > > \field{command-specific-data-reply}.
> > > > >
> > > > > \paragraph{Packet Receive Filtering}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > > > > \label{sec:Device Types / Network Device / Device Operation / Control
> > > > Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> > > > > @@ -4471,6 +4478,399 @@ \subsubsection{Control
> > > > Virtqueue}\label{sec:Device Types / Network Device / Devi
> > > > > according to the native endian of the guest rather than
> > > > > (necessarily when not using the legacy interface) little-endian.
> > > > >
> > > > > +\paragraph{Device Stats}\label{sec:Device Types / Network Device /
> > > > Device Operation / Control Virtqueue / Device Stats}
> > > > > +
> > > > > +If the VIRTIO_NET_F_CTRL_STATS feature is negotiated, the driver can
> > > > > +get the device stats from the device in
> > > > \field{command-specific-data-reply}.
> > > > > +
> > > > > +To get the stats, the following definitions are used:
> > > > > +\begin{lstlisting}
> > > > > +#define VIRTIO_NET_CTRL_STATS 6
> > > > > +#define VIRTIO_NET_CTRL_STATS_GET 0
> > > > > +
> > > > > +#define VIRTIO_NET_STATS_TYPE_CVQ 0
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_BASIC 1
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_CSUM 2
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_GSO 3
> > > > > +#define VIRTIO_NET_STATS_TYPE_RX_RESET 4
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_BASIC 5
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_CSUM 6
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_GSO 7
> > > > > +#define VIRTIO_NET_STATS_TYPE_TX_RESET 8
> > > > > +
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +Use the command VIRTIO_NET_CTRL_STATS_GET and
> > > > \field{command-specific-data}
> > > > > +containing struct virtio_net_ctrl_queue_stats to get the device stats.
> > > > > +The result is returned by \field{command-specific-data-reply}.
> > > > > +The stats ware returned in the order of the type specified in the
> > > > > +\field{virtio_net_ctrl_queue_stats}.
> > > > > +
> > > > > +The following layout structures are used:
> > > > > +
> > > > > +\field{command-specific-data}
> > > > > +\begin{lstlisting}
> > > > > +struct virtio_net_ctrl_queue_stats {
> > > > > + u16 nstats;
> > > > > + struct {
> > > > > + u16 queue_num;
> > > > > + u16 type;
> > > > > + } stats[];
> > > > > +};
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +\field{command-specific-data-reply}
> > > > > +\begin{lstlisting}
> > > > > +struct virtio_net_stats_cvq {
> > > > > + le64 command_num;
> > > > > + le64 ok_num;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_basic {
> > > > > + le64 rx_packets;
> > > > > + le64 rx_bytes;
> > > > > +
> > > > > + le64 rx_notification;
> > > > > + le64 rx_interrupt;
> > > > > +
> > > > > + le64 rx_drop;
> > > > > + le64 rx_drop_overruns;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_csum {
> > > > > + le64 rx_csum_valid;
> > > > > + le64 rx_needs_csum;
> > > > > + le64 rx_csum_bad;
> > > > > + le64 rx_csum_none;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_gso {
> > > > > + le64 rx_gso_packets;
> > > > > + le64 rx_gso_bytes;
> > > > > + le64 rx_gso_packets_coalesced;
> > > > > + le64 rx_gso_bytes_coalesced;
> > > > > + le64 rx_gso_segments;
> > > > > + le64 rx_gso_segments_bytes;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_rx_reset {
> > > > > + le64 rx_reset;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_basic {
> > > > > + le64 tx_packets;
> > > > > + le64 tx_bytes;
> > > > > +
> > > > > + le64 tx_notification;
> > > > > + le64 tx_interrupt;
> > > > > +
> > > > > + le64 tx_drop;
> > > > > + le64 tx_drop_malformed;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_csum {
> > > > > + le64 tx_csum_none;
> > > > > + le64 tx_needs_csum;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_gso {
> > > > > + le64 tx_gso_packets;
> > > > > + le64 tx_gso_bytes;
> > > > > + le64 tx_gso_packets_split;
> > > > > + le64 tx_gso_bytes_split;
> > > > > + le64 tx_gso_segments;
> > > > > + le64 tx_gso_segments_bytes;
> > > > > +};
> > > > > +
> > > > > +struct virtio_net_stats_tx_reset {
> > > > > + le64 tx_reset;
> > > > > +};
> > > > > +
> > > > > +\end{lstlisting}
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [nstats]
> > > > > + The number of \field{stats}.
> > > > > +
> > > > > + \item [queue_num]
> > > > > + The number of the virtqueue to obtain the statistics.
> > > > > +
> > > > > + \item [type]
> > > > > + The type of the stats to be obtained.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +Correspondence between the vq type, the stats type, the stats structure
> > > > and the
> > > > > +required features.
> > > > > +\begin{tabular}{ |l|l|l|l| }
> > > > > + \hline
> > > > > + VQ Type & Stats Type & Stats
> > > > Structure & Features \\ \hline
> > > > > +
> > > > > + controlq & VIRTIO_NET_STATS_TYPE_CVQ &
> > > > virtio_net_stats_cvq & \\ \hline
> > > > > +
> > > > > + \multirow{4}*{receiveq} & VIRTIO_NET_STATS_TYPE_RX_BASIC &
> > > > virtio_net_stats_rx_basic & \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_RX_CSUM &
> > > > virtio_net_stats_rx_csum & VIRTIO_NET_F_GUEST_CSUM \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_RX_GSO &
> > > > virtio_net_stats_rx_gso & VIRTIO_NET_F_GUEST_TSO4 or\newline
> > > > > +
> > > > VIRTIO_NET_F_GUEST_TSO6 or\newline
> > > > > +
> > > > VIRTIO_NET_F_GUEST_UFO \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_RX_RESET &
> > > > virtio_net_stats_rx_reset & VIRTIO_F_RING_RESET \\ \hline
> > > > > +
> > > > > + \multirow{4}*{transmitq} & VIRTIO_NET_STATS_TYPE_TX_BASIC &
> > > > virtio_net_stats_tx_basic & \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_TX_CSUM &
> > > > virtio_net_stats_tx_csum & VIRTIO_NET_F_CSUM \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_TX_GSO &
> > > > virtio_net_stats_tx_gso & VIRTIO_NET_F_HOST_TSO4 or\newline
> > > > > +
> > > > VIRTIO_NET_F_HOST_TSO6 or\newline
> > > > > +
> > > > VIRTIO_NET_F_HOST_USO or\newline
> > > > > +
> > > > VIRTIO_NET_F_HOST_UFO \\ \cline{2-4}
> > > > > + & VIRTIO_NET_STATS_TYPE_TX_RESET &
> > > > virtio_net_stats_tx_reset & VIRTIO_F_RING_RESET \\
> > > > > + \hline
> > > > > +\end{tabular}
> > > > > +
> > > > > +
> > > > > +\subparagraph{Controlq Stats}\label{sec:Device Types / Network Device /
> > > > Device Operation / Control Virtqueue / Device Stats / Controlq Stats}
> > > > > +
> > > > > +The structure corresponding to the controlq stats is
> > > > virtio_net_stats_cvq.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [command_num]
> > > > > + The number of commands, including the current command.
> > > > > +
> > > > > + \item [ok_num]
> > > > > + The number of commands (including the current command) where
> > > > the ack was VIRTIO_NET_OK.
> > > > > +\end{description}
> > > > > +
> > > > > +
> > > > > +\subparagraph{Receiveq Basic Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > > Basic Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq basic stats is
> > > > virtio_net_stats_rx_basic.
> > > > > +
> > > > > +Receiveq basic stats doesn't need any features, as long as the device
> > > > supports
> > > > > +VIRTIO_NET_F_CTRL_STATS. The following are the receiveq basic stats.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_packets]
> > > > > + The number of packets received by device (not the packets
> > > > passed to the
> > > > > + guest), including the dropped packets by device.
> > > > > +
> > > > > + \item [rx_bytes]
> > > > > + The number of bytes received by device (not the packets passed
> > > > to the
> > > > > + guest), including the dropped packets by device.
> > > > > +
> > > > > + \item [rx_notification]
> > > > > + The number of driver notifications.
> > > > > +
> > > > > + \item [rx_interrupt]
> > > > > + The number of device interrupts.
> > > > > +
> > > > > + \item [rx_drop]
> > > > > + The number of packets dropped by the receiveq. Contains all
> > > > kinds of
> > > > > + packet drop.
> > > > > +
> > > > > + \item [rx_drop_overruns]
> > > > > + The number of packets dropped by the receiveq when no more
> > > > descriptors
> > > > > + were available.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq Basic Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > Basic Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq basic stats is
> > > > virtio_net_stats_tx_basic.
> > > > > +
> > > > > +Transmitq basic stats doesn't need any features, as long as the device
> > > > supports
> > > > > +VIRTIO_NET_F_CTRL_STATS. The following are the transmitq basic stats.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_packets]
> > > > > + The number of packets sent by device (not the packets got from
> > > > the
> > > > > + guest), excluding the dropped packets by device.
> > > > > +
> > > > > + \item [tx_bytes]
> > > > > + The number of bytes sent by device (not the packets got from the
> > > > > + guest), excluding the dropped packets by device.
> > > > > +
> > > > > + \item [tx_notification]
> > > > > + The number of driver notifications.
> > > > > +
> > > > > + \item [tx_interrupt]
> > > > > + The number of device interrupts.
> > > > > +
> > > > > + \item [tx_drop]
> > > > > + The number of packets dropped by the transmitq. Contains all
> > > > kinds of
> > > > > + packet drop.
> > > > > +
> > > > > + \item [tx_drop_malformed]
> > > > > + The number of packets dropped when the descriptor is in an
> > > > error state.
> > > > > + For example, the buffer is too short.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Receiveq CSUM Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > > CSUM Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq csum stats is
> > > > virtio_net_stats_rx_csum.
> > > > > +
> > > > > +Only after the VIRTIO_NET_F_GUEST_CSUM negotiation is successful, the
> > > > receiveq
> > > > > +csum stats can be obtained.
> > > > > +
> > > > > +The following are the receiveq csum stats:
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_csum_valid]
> > > > > + The number of packets with VIRTIO_NET_HDR_F_DATA_VALID.
> > > > > +
> > > > > + \item [rx_needs_csum]
> > > > > + The number of packets with VIRTIO_NET_HDR_F_NEEDS_CSUM.
> > > > > +
> > > > > + \item [rx_csum_bad]
> > > > > + The number of packets with abnormal csum.
> > > > > +
> > > > > + \item [rx_csum_none]
> > > > > + The number of packets without hardware csum. The packet here
> > > > refers to
> > > > > + the non-TCP/UDP packet that the backend cannot recognize.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq CSUM Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > CSUM Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq csum stats is
> > > > virtio_net_stats_tx_csum.
> > > > > +
> > > > > +Only after the VIRTIO_NET_F_CSUM negotiation is successful, the
> > > > transmitq csum
> > > > > +stats can be obtained.
> > > > > +
> > > > > +The following are the transmitq csum stats:
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_csum_none]
> > > > > + The number of packets that didn't require hardware csum.
> > > > > +
> > > > > + \item [tx_needs_csum]
> > > > > + The number of packets that required hardware csum.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Receiveq GSO Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq GSO
> > > > Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq gso stats is
> > > > virtio_net_stats_rx_gso.
> > > > > +
> > > > > +If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, or UFO options have
> > > > > +been negotiated, the receiveq gso stats can be obtained.
> > > > > +
> > > > > +Rx gso packets refer to packets passed by the device to the driver where
> > > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_gso_packets]
> > > > > + The number of the rx gso packets.
> > > > > +
> > > > > + \item [rx_gso_bytes]
> > > > > + The number of bytes(excluding the virtio net header) of the rx
> > > > gso packets.
> > > > > +
> > > > > + \item [rx_gso_packets_coalesced]
> > > > > + The number of the rx gso packages generated by coalescing.
> > > > > +
> > > > > + \item [rx_gso_bytes_coalesced]
> > > > > + The number of bytes(excluding the virtio net header) of the rx
> > > > gso packets generated by coalescing.
> > > > > +
> > > > > + \item [rx_gso_segments]
> > > > > + The number of coalesced segments.
> > > > > +
> > > > > + \item [rx_gso_segments_bytes]
> > > > > + The number of bytes of coalesced segments.
> > > > > +
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq GSO Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > GSO Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq gso stats is
> > > > virtio_net_stats_tx_gso.
> > > > > +
> > > > > +If one of the VIRTIO_NET_F_HOST_TSO4, TSO6, USO or UFO options have
> > > > > +been negotiated, the transmitq gso stats can be obtained.
> > > > > +
> > > > > +Tx gso packets refer to packets passed by the driver to the device where
> > > > > +\field{gso_type} is not VIRTIO_NET_HDR_GSO_NONE.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_gso_packets]
> > > > > + The number of the tx gso packets.
> > > > > +
> > > > > + \item [tx_gso_bytes]
> > > > > + The number of bytes(excluding the virtio net header) of the tx
> > > > gso packets.
> > > > > +
> > > > > + \item [tx_gso_packets_split]
> > > > > + The number of the tx gso packets that been split.
> > > > > +
> > > > > + \item [tx_gso_bytes_split]
> > > > > + The number of bytes(excluding the virtio net header) of the tx
> > > > gso packets that been split.
> > > > > +
> > > > > + \item [tx_gso_segments]
> > > > > + The number of segments split from the gso package.
> > > > > +
> > > > > + \item [tx_gso_segments_bytes]
> > > > > + The number of bytes(excluding the virtio net header) of
> > > > segments split from the gso package.
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Receiveq Reset Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Receiveq
> > > > Reset Stats}
> > > > > +
> > > > > +The structure corresponding to the receiveq reset stats is
> > > > virtio_net_stats_rx_reset.
> > > > > +
> > > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the receiveq
> > > > reset stats
> > > > > +can be obtained.
> > > > > +
> > > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > > Virtqueue Reset}
> > > > > +for more about \field{rx_reset}.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [rx_reset]
> > > > > + The number of receiveq resets.
> > > > > +\end{description}
> > > > > +
> > > > > +\subparagraph{Transmitq Reset Stats}\label{sec:Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats / Transmitq
> > > > Reset Stats}
> > > > > +
> > > > > +The structure corresponding to the transmitq reset stats is
> > > > virtio_net_stats_tx_reset.
> > > > > +
> > > > > +Only when VIRTIO_F_RING_RESET is successfully negotiated, the transmitq
> > > > reset stats
> > > > > +can be obtained.
> > > > > +
> > > > > +See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> > > > Virtqueue Reset}
> > > > > +for more about \field{tx_reset}.
> > > > > +
> > > > > +\begin{description}
> > > > > + \item [tx_reset]
> > > > > + The number of transmitq resets.
> > > > > +\end{description}
> > > > > +
> > > > > +\devicenormative{\subparagraph}{Device Stats}{Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > > +
> > > > > +If virtio_net_ctrl_queue_stats is incorrect (such as the following),
> > > > the device
> > > > > +MUST set \field{ack} to VIRTIO_NET_ERR. Even if there is only one error,
> > > > > +the device MUST abort the entire command.
> > > > > +\begin{itemize}
> > > > > + \item \field{queue_num} exceeds the queue range.
> > > > > + \item \field{type} is not a known value.
> > > > > + \item The type of vq does not match \field{type}. E.g. the driver
> > > > tries to query
> > > > > + RX stats through a TX index.
> > > > > + \item The feature corresponding to the specified \field{type} was
> > > > not successfully
> > > > > + negotiated.
> > > > > + \item The size of the buffer allocated by the driver for
> > > > \field{command-specific-data-reply}
> > > > > + is less than the total size of the stats specialed by
> > > > > + \field{virtio_net_ctrl_queue_stats}.
> > > > > +\end{itemize}
> > > > > +
> > > > > +The device MUST write the requested stats structures in
> > > > > +\field{command-specific-data-reply} in the order specified by the
> > > > structure
> > > > > +virtio_net_ctrl_queue_stats.
> > > > > +
> > > > > +\drivernormative{\subparagraph}{Device Stats}{Device Types / Network
> > > > Device / Device Operation / Control Virtqueue / Device Stats}
> > > > > +
> > > > > +When a driver tries to obtain a certain stats, it MUST confirm that the
> > > > relevant
> > > > > +feature negotiation is successful.
> > > > > +
> > > > > +\field{type} in struct virtio_net_ctrl_queue_stats MUST correspond to
> > > > the vq
> > > > > +specified by \field{queue_num}.
> > > > > +
> > > > > +The \field{command-specific-data-reply} buffer allocated by the driver
> > > > MUST be
> > > > > +able to hold all the stats specified by virtio_net_ctrl_queue_stats.
> > > > > +
> > > > > +When the driver reads the response, it MUST read
> > > > > +\field{command-specific-data-reply} one by one based on the
> > > > \field{type}.
> > > > >
> > > > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > > > Types / Network Device / Legacy Interface: Framing Requirements}
> > > > > --
> > > > > 2.31.0
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > > >
> > > >
> > > >
> > >
> >
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
2023-07-12 12:33 ` Michael S. Tsirkin
@ 2023-07-21 12:24 ` Cornelia Huck
2023-07-21 12:41 ` [virtio-dev] " Michael S. Tsirkin
0 siblings, 1 reply; 21+ messages in thread
From: Cornelia Huck @ 2023-07-21 12:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Xuan Zhuo, virtio-dev, jasowang, Parav Pandit
On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote:
>> On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> > Yes we were supposed to freeze for 1.3. This change can be merged on a
>> > main branch after 1.3 forks and is under review.
>>
>> Nod, that's what I would prefer to do. Being merged on virtio-next
>> should be enough for including device/driver implementations.
>
> Except I'd prefer a v1.3 branch instead of a next branch - adding things
> on the branch should be harder, not easier.
Just to clarify: What I had planned for 1.3 (and what we already did for
1.2) is to fork a -next branch, finish 1.3 on the master branch, and
then merge -next back into master after we'd be done with 1.3.
I'm not sure what you mean by "adding things on the branch should be
harder, not easier" -- I think it is already a bit harder because it is
a branch :)
We can of course do a v1.3 branch instead and continue developing on
master, but shouldn't we then create branches (glorified tags) for the
older releases as well?
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] Re: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
2023-07-21 12:24 ` [virtio-dev] 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats) Cornelia Huck
@ 2023-07-21 12:41 ` Michael S. Tsirkin
2023-07-21 13:05 ` [virtio-dev] Re: 1.3 and branching Cornelia Huck
2023-07-21 14:13 ` [virtio-dev] RE: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats) Parav Pandit
0 siblings, 2 replies; 21+ messages in thread
From: Michael S. Tsirkin @ 2023-07-21 12:41 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Xuan Zhuo, virtio-dev, jasowang, Parav Pandit
On Fri, Jul 21, 2023 at 02:24:57PM +0200, Cornelia Huck wrote:
> On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote:
> >> On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> > Yes we were supposed to freeze for 1.3. This change can be merged on a
> >> > main branch after 1.3 forks and is under review.
> >>
> >> Nod, that's what I would prefer to do. Being merged on virtio-next
> >> should be enough for including device/driver implementations.
> >
> > Except I'd prefer a v1.3 branch instead of a next branch - adding things
> > on the branch should be harder, not easier.
>
> Just to clarify: What I had planned for 1.3 (and what we already did for
> 1.2) is to fork a -next branch, finish 1.3 on the master branch, and
> then merge -next back into master after we'd be done with 1.3.
>
> I'm not sure what you mean by "adding things on the branch should be
> harder, not easier" -- I think it is already a bit harder because it is
> a branch :)
>
> We can of course do a v1.3 branch instead and continue developing on
> master, but shouldn't we then create branches (glorified tags) for the
> older releases as well?
Yea, makes sense.
I think we are all set WRT what we planned to be in 1.3 - right?
Next step is preparing the changelog and packaging it
all as WD, then voting to approve it as a CSD/CSPRD and start
public review.
Have time this week? if not I will get to it next week.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] Re: 1.3 and branching
2023-07-21 12:41 ` [virtio-dev] " Michael S. Tsirkin
@ 2023-07-21 13:05 ` Cornelia Huck
2023-07-21 14:13 ` [virtio-dev] RE: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats) Parav Pandit
1 sibling, 0 replies; 21+ messages in thread
From: Cornelia Huck @ 2023-07-21 13:05 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Xuan Zhuo, virtio-dev, jasowang, Parav Pandit
On Fri, Jul 21 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Jul 21, 2023 at 02:24:57PM +0200, Cornelia Huck wrote:
>> On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>
>> > On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote:
>> >> On Wed, Jul 12 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >> > Yes we were supposed to freeze for 1.3. This change can be merged on a
>> >> > main branch after 1.3 forks and is under review.
>> >>
>> >> Nod, that's what I would prefer to do. Being merged on virtio-next
>> >> should be enough for including device/driver implementations.
>> >
>> > Except I'd prefer a v1.3 branch instead of a next branch - adding things
>> > on the branch should be harder, not easier.
>>
>> Just to clarify: What I had planned for 1.3 (and what we already did for
>> 1.2) is to fork a -next branch, finish 1.3 on the master branch, and
>> then merge -next back into master after we'd be done with 1.3.
>>
>> I'm not sure what you mean by "adding things on the branch should be
>> harder, not easier" -- I think it is already a bit harder because it is
>> a branch :)
>>
>> We can of course do a v1.3 branch instead and continue developing on
>> master, but shouldn't we then create branches (glorified tags) for the
>> older releases as well?
>
> Yea, makes sense.
> I think we are all set WRT what we planned to be in 1.3 - right?
I'll send out a "last call" JFTR, but I think we're good.
> Next step is preparing the changelog and packaging it
> all as WD, then voting to approve it as a CSD/CSPRD and start
> public review.
>
> Have time this week? if not I will get to it next week.
Certainly not this week, but one of us can get started with the
changelog next week. Fortunately, it should be shorter than the one for
1.2 :)
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* [virtio-dev] RE: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
2023-07-21 12:41 ` [virtio-dev] " Michael S. Tsirkin
2023-07-21 13:05 ` [virtio-dev] Re: 1.3 and branching Cornelia Huck
@ 2023-07-21 14:13 ` Parav Pandit
1 sibling, 0 replies; 21+ messages in thread
From: Parav Pandit @ 2023-07-21 14:13 UTC (permalink / raw)
To: Michael S. Tsirkin, Cornelia Huck; +Cc: Xuan Zhuo, virtio-dev, jasowang
> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Friday, July 21, 2023 8:42 AM
> Yea, makes sense.
> I think we are all set WRT what we planned to be in 1.3 - right?
> Next step is preparing the changelog and packaging it all as WD, then voting to
> approve it as a CSD/CSPRD and start public review.
>
> Have time this week? if not I will get to it next week.
Let me know what to do for change log prep and I can prepare it today.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2023-07-21 14:13 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-15 3:24 [virtio-dev] [PATCH v12] virtio-net: support device stats Xuan Zhuo
2022-03-22 7:57 ` [virtio-dev] " Jason Wang
2023-07-10 7:28 ` [virtio-dev] " Xuan Zhuo
2023-07-10 7:28 ` [virtio-comment] " Xuan Zhuo
2023-07-12 8:08 ` Jason Wang
2023-07-12 8:08 ` [virtio-comment] " Jason Wang
2023-07-12 9:11 ` Xuan Zhuo
2023-07-12 9:11 ` [virtio-comment] " Xuan Zhuo
2023-07-13 2:21 ` Jason Wang
2023-07-13 2:21 ` [virtio-comment] " Jason Wang
2023-07-13 2:27 ` [virtio-dev] " Xuan Zhuo
2023-07-13 2:27 ` Xuan Zhuo
2023-07-12 11:34 ` [virtio-dev] " Michael S. Tsirkin
2023-07-12 11:44 ` Xuan Zhuo
2023-07-12 11:54 ` Michael S. Tsirkin
2023-07-12 12:24 ` Cornelia Huck
2023-07-12 12:33 ` Michael S. Tsirkin
2023-07-21 12:24 ` [virtio-dev] 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats) Cornelia Huck
2023-07-21 12:41 ` [virtio-dev] " Michael S. Tsirkin
2023-07-21 13:05 ` [virtio-dev] Re: 1.3 and branching Cornelia Huck
2023-07-21 14:13 ` [virtio-dev] RE: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats) Parav Pandit
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.