[virtio-dev] RE: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
> From: Michael S. Tsirkin > 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-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
On Fri, Jul 21, 2023 at 02:24:57PM +0200, Cornelia Huck wrote: > On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: > > > On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote: > >> On Wed, Jul 12 2023, "Michael S. Tsirkin" 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-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: > On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote: >> On Wed, Jul 12 2023, "Michael S. Tsirkin" 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-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote: > On Wed, Jul 12 2023, "Michael S. Tsirkin" 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" > >> 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 > >> > > Suggested-by: Michael S. Tsirkin > >> > > >> > 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-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats
On Wed, Jul 12 2023, "Michael S. Tsirkin" 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" >> 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 >> > > Suggested-by: Michael S. Tsirkin >> > >> > 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-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v12] virtio-net: support device stats
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"
> 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
> > > Suggested-by: Michael S. Tsirkin
> >
> > 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;
[virtio-dev] Re: [PATCH v12] virtio-net: support device stats
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
> Suggested-by: Michael S. Tsirkin
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}
>
[virtio-dev] Re: [PATCH v12] virtio-net: support device stats
在 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
Suggested-by: Michael S. Tsirkin
---
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
