[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v12] virtio-net: support device stats
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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]