Re: [PATCH v11] virtio-net: support device stats

On Wed, Mar 9, 2022 at 5:08 PM Michael S. Tsirkin <mst@redhat.com> wrote:

On Wed, Mar 09, 2022 at 04:25:26PM +0800, Xuan Zhuo wrote:
> On Mon, 7 Mar 2022 15:58:03 +0800, Jason Wang <jasowang@redhat.com> wrote:
> >
> > å 2022/3/2 äå4:52, 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>
> > > ---
> > > v11:
> > > 1. Use michael's advice to introduce virtio_net_ctrl_queue_stats to get vq stats
> > >Â Â Âbased on vq num and type
> > > 2. split stats structure
> > >
> > > v10:
> > > 1. use description/item for the item of the queue pair
> > > 2. use one command to get the stats of all queue pairs
> > >
> > > v8:
> > > 1. Modified based on comments by Cornelia Huck
> > >
> > > v7:
> > > 1. add rx_reset, tx_reset
> > > 2. add device normative and dirver normative
> > > 3. add comments for *_packets, *_bytres
> > >
> > > v6:
> > > 1. correct the names and descriptions of some stats items
> > >
> > > v5:
> > > 1. add VIRTIO_NET_CTRL_STATS_GET_CTRL_VQ
> > > 2. more item for virtio_net_ctrl_reply_stats_queue_pair
> > >
> > > v4:
> > > 1. remove dev_stats_num, {rx|tx}_stats_num
> > > 2. Use two commands to get the stats of queue pair and dev respectively
> > >
> > > v3 changes:
> > > 1. add dev_version
> > > 2. use queue_pair_index replace rx_num, tx_num
> > > 3. Explain the processing when the device and driver support different numbers
> > > of stats
> > >
> > >Â Âconformance.tex |Â Â2 +
> > >Â Âcontent.texÂ Â Â| 391 +++++++++++++++++++++++++++++++++++++++++++++++-
> > >Â Â2 files changed, 390 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..5746f49 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,384 @@ \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}
> > > +
> > > +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;
> > > +Â Â Âu16 length;
> > > + } 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;
> > > +};
> > > +
> > > +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;
> > > +};
> > > +
> > > +struct virtio_net_stats_tx_reset {
> > > +Â Â le64 tx_reset;
> > > +};
> > > +
> > > +\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}.
> >
> >
> > It's better to move this sentence after the description above. And we
> > need explain the result a little bit more, e.g the stats ware returned
> > in the order of the type specified in the virtio_net_ctrl_queue_stats.
> >
> >
> > > +
> > > +\begin{description}
> > > +Â Â \item [nstats]
> > > +Â Â Â Â The number of \field{stats}.
> > > +
> > > +Â Â \item [queue_num]
> > > +Â Â Â Â The queue num of the vq to be obtained. The vq can be receiveq,
> > > +Â Â Â Â transmitq or controlq.
> >
> >
> > This could be simplified as "The number of the virtqueue to obtain the
> > statistics"
> >
> >
> > > +
> > > +Â Â \item [type]
> > > +Â Â Â Â The type of the stats to be obtained.
> > > +
> > > +Â Â \item [length]
> > > +Â Â Â Â Limits the size of the memory space occupied by the returned stats.
> >
> >
> > What's the value of having this? Or how can driver know which value
> > should it use?
> >
> >
> > > +
> > > +\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
> >
> >
> > I think CVQ should require CVQ feature to be negotiated.
> >
> >
> > > +
> > > +Â Â \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, TSO6, or UFO \\ \cline{2-4}
> >
> >
> > It's better to aovid abbrev for features like TSO6.
> >
> >
> > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â& 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, TSO6, USO or 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 received from the
> >
> >
> > s/received/sent/?
> >
> >
> > > +Â Â Â Â guest), excluding the dropped packets by device.
> > > +
> > > +Â Â \item [tx_bytes]
> > > +Â Â Â Â The number of bytes sent by device (not the packets received 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.
> > > +
> > > +The statistics of the following receiveq gso stats are based on the rx gso
> > > +packet. The device may receive multiple small packets, and finally combine them
> > > +into one rx gso packet and pass it to the driver. It is also possible to receive
> > > +a gso packet and pass it directly to the driver. We should count the information
> > > +of the rx gso packet that is finally passed to the driver (such as number and
> > > +bytes). Instead of the information of the small packet.
> >
> >
> > If we don't want to explain why we use a single counter for those two
> > cases, we probably can drop the above paragraph and simply say the
> > rx_gso_packets is the number of gso packet produced by the device.
> >
> > Btw, we had VIRTIO_NET_GUEST_RSC{4|6}, is it better to use different
> > counters?
>
>
> RSC information doesn't seem to be very comprehensive in the spec.

CC Yuri.
Yuri do you feel we need to clarify things in the spec?
If yes please create a github issue. Thanks!

I agree, it looks to me RSC may make sense for harware virtio devices so it's probably not a feature just for WHQL.

Thanks

> I'm not sure,
> is the gso_type of the RSC package also VIRTIO_NET_HDR_GSO_TCPV4 or VIRTIO_NET_HDR_GSO_TCPV6?
>
> If yes, I plan to modify gso's stats to the following form to record gso's
> stats. In this case include the RSC package.
>
> \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 merging.
>
>Â Â Â\item [rx_gso_bytes_coalesced]
>Â Â Â Â ÂThe number of bytes(excluding the virtio net header) of the rx gso packets generated by merging.
>
>Â Â Â\item [rx_gso_segments]
>Â Â Â Â ÂThe number of coalesced segments.
>
>Â Â Â\item [rx_gso_segments_bytes]
>Â Â Â Â ÂThe number of bytes of coalesced segments.
>
> \end{description}
>
> \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}
>
> Thanks.
>
> >
> >
> > > +
> > > +\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.
> > > +\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 receiveq 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.
> > > +
> > > +The statistics of the following transmitq gso stats are based on the tx gso
> > > +packet. The device may receive a tx gso packet from the driver, and then may split
> > > +it into multiple small packets or send the tx gso packet directly. But the device
> > > +counts the information of the gso packet received from the driver (such as the
> > > +number and bytes). Instead of the packet information after splitting.
> >
> >
> > Similar to rx gso, is it better to use two counters?
> >
> >
> > > +
> > > +\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.
> > > +\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 queue 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 queue 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.
> > > +\begin{itemize}
> > > +Â Â \item \field{queue_num} exceeds the queue range.
> > > +Â Â \item \field{type} is not a known value.
> >
> >
> > What happens if driver tries to query RX stats through a TX index?
> >
> >
> > > +Â Â \item The type of vq does not match \field{type}.
> > > +Â Â \item The feature corresponding to the specified \field{type} was not successfully
> > > +Â Â Â Â negotiated.
> > > +Â Â \item The size of \field{command-specific-data-reply} is less than the sum
> > > +Â Â Â Â of \field{length}.
> >
> >
> > I'm not sure I get here, I guess this proposal allows the driver to
> > query an array of stats. So I guess it means the size of required stats
> > instead of the size of \field{command-specific-data-reply}.
> >
> >
> > > +\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.
> >
> >
> > Do we need per stat error code here? Or device can simply fail a batch
> > of query if one of those fails?
> >
> >
> > > +
> > > +The size of each stats MUST be less than or equal to the corresponding
> > > +\field{length}, but the space it occupies MUST be equal to the corresponding
> > > +\field{length}.
> >
> >
> > I wonder how the length trick can work here. Is this used for extension?
> > If yes, how can driver know a suitable length? What happens if device
> > support more 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}.
> > > +
> > > +\field{length} in struct virtio_net_ctrl_queue_stats MUST be greater than or
> > > +equal to the size of the structure corresponding to \field{type}. It MUST be a
> > > +multiple of 8.
> >
> >
> > Why do we need the padding here?
> >
> >
> > > +
> > > +The size of \field{command-specific-data-reply} allocated by the driver MUST be
> > > +greater than or equal to the sum of \field{legnth} in struct
> >
> >
> > typo.
> >
> >
> > > +virtio_net_ctrl_queue_stats.
> >
> >
> > Any value that we can allocate more than the sum of the length?
> >
> > Thanks
> >
> >
> > > +
> > > +When the driver reads the response, it MUST read
> > > +\field{command-specific-data-reply} one by one based on the set \field{length}
> > > +and \field{type}.
> > >
> > >Â Â\subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > >Â ÂTypes / Network Device / Legacy Interface: Framing Requirements}
> > > --
> > > 2.31.0
> > >
> >

virtio-dev message