From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alvaro Karsz <alvaro.karsz@solid-run.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
virtio-dev@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org,
Parav Pandit <parav@nvidia.com>,
David Edmondson <david.edmondson@oracle.com>,
Jason Wang <jasowang@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [virtio-dev] Re: [PATCH v9] virtio-net: support the virtqueue coalescing moderation
Date: Mon, 27 Feb 2023 15:19:10 -0500 [thread overview]
Message-ID: <20230227151420-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJs=3_DND7WdoXc19XzOKDDKYNXFKdKRMr6j93p9z7=5EyGHGQ@mail.gmail.com>
On Mon, Feb 27, 2023 at 08:45:43PM +0200, Alvaro Karsz wrote:
> > >> -If the VIRTIO_NET_F_NOTF_COAL feature is negotiated, the driver can
> > >> -send control commands for dynamically changing the coalescing parameters.
> > >> +If the VIRTIO_NET_F_NOTF_COAL feature is negotiated, the driver can send the VIRTIO_NET_CTRL_NOTF_COAL_TX_SET
> > >> +and VIRTIO_NET_CTRL_NOTF_COAL_RX_SET commands to dynamically change the coalescing parameters for all transmit
> > >> +and receive virtqueues, respectively.
> > >> +
> > >> +If the VIRTIO_NET_F_VQ_NOTF_COAL feature is negotiated:
> > >> +\begin{itemize}
> > >> +\item a driver can send a VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET command to set coalescing parameters of a given
> > >> + enabled transmit/receive virtqueue.
> > >> +\item a driver can send a VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET command to a device, and the device responds with
> > >> + coalescing parameters of a given enabled transmit/receive virtqueue.
> > >> +\end{itemize}
> > >>
> > > The VQ_NOTF_COAL commands are enclosed in an itemize and the NOTF_COAL
> > > commands aren't.
> > > I think that we should be consistent here.
> >
> > The VQ commands are enclosed in an itemize because it has both GET and
> > SET operations.
> >
> > I don't think VIRTIO_NET_CTRL_NOTF_COAL_RX_SET and
> > VIRTIO_NET_CTRL_NOTF_COAL_TX_SET
> > have to do this, because they are both settings, just in different
> > directions, and we have described them like this elsewhere.
> >
> > >
> > > I'm not sure that describing the commands in here is necessary, maybe
> > > just mentioning which commands can be used with which feature bit is
> >
> > Isn't that what this sentence does?
> >
>
> Yes, but it also describes what the command does
> "to dynamically change the coalescing parameters for all transmit and
> receive virtqueues"
>
> Seems a bit repetitive to me.
>
> > > enough (this is what I meant in v8, sorry if I wasn't clear).
> > >
> > > I'm not saying that describing the commands in here is not good, but
> > > notice that the commands are described in 3 different places.
> >
> > Three places describe different effects.
> >
> > #1 describes which commands are available for which feature.
> > #2 describes which command can use which structure.
> > #3 describes which parameters can be set for each command, and whether
> > they can affect "global values".
> > It is placed in the "Operation" section because it explains how the
> > device should behave.
> >
>
> You're right, but some parts seems repetitive to me:
> #1: "commands to dynamically change the coalescing parameters for all
> transmit and receive virtqueues"
>
> #2: "commands use the virtio_net_ctrl_coal structure to set
> \field{max_usecs} and \field{max_packets} for all transmit/receive
> virtqueues."
>
> #3: " set the \field{max_usecs} and \field{max_packets} parameters for
> all transmit virtqueues, and values of..."
>
> Feels like every time we re-explain the commands with more detail.
> So, for example we read #2 and understand what the command does (set
> usecs and packets), then we read #3 and understand that it does some
> more stuff.
>
> IMO we need to explain it once, with all the details.
This is how we've written it historically. The idea is that
reader can get everything on the first pass: 1st high level
picture then detailed description then the formalities.
Other specs do it differently so one has to re-read them
many times to understand. I don't like this personally and
I much prefer the virtio way.
> > Maybe #1 and #2 descriptions can be combined and described together.
> >
> > > This is #1.
> > >
> > >> \begin{note}
> > >> The behavior of the device in response to these commands is best-effort:
> > >> @@ -1519,25 +1531,76 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > >> le32 max_usecs;
> > >> };
> > >>
> > >> +struct virtio_net_ctrl_coal_vq {
> > >> + le16 vqn;
> > >> + le16 reserved;
> > >> + struct virtio_net_ctrl_coal coal;
> > >> +};
> > >> +
> > >> #define VIRTIO_NET_CTRL_NOTF_COAL 6
> > >> #define VIRTIO_NET_CTRL_NOTF_COAL_TX_SET 0
> > >> #define VIRTIO_NET_CTRL_NOTF_COAL_RX_SET 1
> > >> + #define VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET 2
> > >> + #define VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET 3
> > >> \end{lstlisting}
> > >>
> > >> +The VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and VIRTIO_NET_CTRL_NOTF_COAL_RX_SET commands use the
> > >> +virtio_net_ctrl_coal structure to set \field{max_usecs} and \field{max_packets} for all
> > >> +transmit/receive virtqueues.
> > >> +
> > >> +The VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET command uses the virtio_net_ctrl_coal_vq structure
> > >> +to set \field{max_usecs} and \field{max_packets} for the supplied virtqueue number \field{vqn}.
> > >> +
> > >> +The VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET command gets the values of \field{max_usecs} and
> > >> +\field{max_packets} of the specified virtqueue from the device by setting \field{vqn}
> > >> +in the virtio_net_ctrl_coal_vq structure.
> > >> +
> > > This is #2.
> > >
> > >> +# Read/Write attributes for coalescing parameters
> > >> +\begin{itemize}
> > >> +\item For commands VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and VIRTIO_NET_CTRL_NOTF_COAL_RX_SET, \field{max_usecs}
> > >> + and \field{max_packets} are write-only for a driver.
> > >> +\item For the command VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET, \field{vqn}, \field{reserved}, \field{max_usecs}
> > >> + and \field{max_packets} are write-only for a driver.
> > >> +\item For the command VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET, \field{vqn} and \field{reserved} are write-only
> > >> + for a driver, and, \field{max_usecs} and \field{max_packets} are read-only for the driver.
> > >> +\end{itemize}
> > >> +
> > >> Coalescing parameters:
> > >> \begin{itemize}
> > >> +\item \field{vqn}: The virtqueue number of an enabled transmit or receive virtqueue.
> > >> \item \field{max_usecs} for RX: Maximum number of microseconds to delay a RX notification.
> > >> \item \field{max_usecs} for TX: Maximum number of microseconds to delay a TX notification.
> > >> \item \field{max_packets} for RX: Maximum number of packets to receive before a RX notification.
> > >> \item \field{max_packets} for TX: Maximum number of packets to send before a TX notification.
> > >> \end{itemize}
> > >>
> > >> -The class VIRTIO_NET_CTRL_NOTF_COAL has 2 commands:
> > >> +\field{reserved} is reserved and it is ignored by a device.
> > >> +
> > >> +The class VIRTIO_NET_CTRL_NOTF_COAL has 4 commands:
> > >> \begin{enumerate}
> > >> -\item VIRTIO_NET_CTRL_NOTF_COAL_TX_SET: set the \field{max_usecs} and \field{max_packets} parameters for all transmit virtqueues.
> > >> -\item VIRTIO_NET_CTRL_NOTF_COAL_RX_SET: set the \field{max_usecs} and \field{max_packets} parameters for all receive virtqueues.
> > >> +\item VIRTIO_NET_CTRL_NOTF_COAL_TX_SET: set the \field{max_usecs} and \field{max_packets} parameters for all transmit virtqueues, and values of
> > >> + coalescing parameters are recorded as TX global values by a device.
> > >> +\item VIRTIO_NET_CTRL_NOTF_COAL_RX_SET: set the \field{max_usecs} and \field{max_packets} parameters for all receive virtqueues, and values of
> > >> + coalescing parameters are recorded as RX global values by a device.
> > >> +\item VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET: set the \field{max_usecs} and \field{max_packets} parameters for an enabled transmit/receive
> > >> + virtqueue whose number is \field{vqn}, and do not change the TX/RX global values.
> > >> +\item VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET: the device returns the \field{max_usecs} and \field{max_packets} parameters for an enabled
> > >> + transmit/receive virtqueue whose number is \field{vqn}.
> > >> \end{enumerate}
> > > This is #3.
> > >
> > >> +If coalescing parameters are being set, the device applies the last coalescing parameters received for a
> > >> +virtqueue, regardless of the command used to set the parameters. For example with 2 pairs of virtqueues:
> > >> +# Command sequence
> > >> +Each of the following commands sets \field{max_usecs} and \field{max_packets} parameters for virtqueues.
> > >> +\begin{itemize}
> > >> +\item Command1: VIRTIO_NET_CTRL_NOTF_COAL_RX_SET sets coalescing parameters for virtqueue0 and virtqueue2, and, virtqueue1 and virtqueue3 retain their previous parameter values.
> > >> +\item Command2: VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET with \field{vqn} = 0 sets coalescing parameters for virtqueue0, and virtqueue2 retains the values from command1.
> > >> +\item Command3: VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET with \field{vqn} = 0, the device responds with coalescing parameters of virtqueue0 set by command2.
> > >> +\item Command4: VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET with \field{vqn} = 1 sets coalescing parameters for virtqueue1, and virtqueue3 retains its previous values.
> > >> +\item Command5: VIRTIO_NET_CTRL_NOTF_COAL_TX_SET sets coalescing parameters for virtqueue1 and virtqueue3, and overrides the values set by command4.
> > >> +\item Command6: VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET with \field{vqn} = 1, the device responds with coalescing parameters of virtqueue1 set by command5.
> > >> +\end{itemize}
> > >> +
> > >> \subparagraph{Operation}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Notifications Coalescing / Operation}
> > >>
> > >> The device sends a used buffer notification once the notification conditions are met and if the notifications are not suppressed as explained in \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}.
> > >> @@ -1549,6 +1612,11 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > >>
> > >> When the device has \field{max_usecs} = 0 or \field{max_packets} = 0, the notification conditions are met after every packet received/sent.
> > >>
> > >> +When the device receives the VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and VIRTIO_NET_CTRL_NOTF_COAL_RX_SET commands,
> > >> +it saves the values of coalescing parameters as global values, and the VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET command
> > >> +does not change the global values. If the device is reset, the global values will be set to 0.
> > >> +When a virtqueue is enabled after virtqueue reset, its coalescing parameters are set to global values.
> > >> +
> > > Maybe this explanation should be put closer to the commands
> > > descriptions, where the global coalescing parameters are mentioned for
> > > the first time.
> > > Something like:
> > > ....
> > > \item VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET: the device returns the
> > > \field{max_usecs} and \field{max_packets} parameters for an enabled
> > > transmit/receive virtqueue whose number
> > > is \field{vqn}.
> > >
> > > The device maintains global coalescing parameters for TX and RX....
> >
> > This is the "Operation" chapter, and the description of the operation is
> > more likely to be placed here, isn't it?
> >
>
> I see your point, but a reader will see the "global notifications
> coalescing parameter" concept, and won't know what it is until next
> paragraph.
> Maybe we can have a new list with the notification coalescing concepts
> (like the notification coalescing parameters)? Just throwing an idea
> here.
Actually, "global notification coalescing parameters" is confusing:
are these global notifications? global coalescings? global parameters?
The problem is the global qualifier. And it's not even global -
there are two sets for rx and for tx and does not apply to cvq at all.
How about "RX/TX coalescing parameters"?
> >
> > >
> > > And maybe we should use "global coalescing parameters" instead of
> > > "global values" (in devicenormative as well).
> > >
> > >> \subparagraph{RX Example}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Notifications Coalescing / RX Example}
> > >>
> > >> If, for example:
> > >> @@ -1585,15 +1653,26 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > >>
> > >> \drivernormative{\subparagraph}{Notifications Coalescing}{Device Types / Network Device / Device Operation / Control Virtqueue / Notifications Coalescing}
> > >>
> > >> -If the VIRTIO_NET_F_NOTF_COAL feature has not been negotiated, the driver MUST NOT issue VIRTIO_NET_CTRL_NOTF_COAL commands.
> > >> +If neither the VIRTIO_NET_F_NOTF_COAL nor the VIRTIO_NET_F_VQ_NOTF_COAL feature
> > >> +has been negotiated, the driver MUST NOT issue VIRTIO_NET_CTRL_NOTF_COAL commands.
> > > Maybe this part can be splitted to:
> > > if the F1 feature has not been negotiated, the driver must not issue
> > > commands C1,C2.
> > > if the F2 feature has not been negotiated, the driver must not issue
> > > commands C3,C4.
> >
> > Ok.
> >
> > Thanks.
> >
> > >> +
> > >> +A driver MUST ignore the values of coalescing parameters received from the VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET command if a device responds with VIRTIO_NET_ERR.
> > >>
> > >> \devicenormative{\subparagraph}{Notifications Coalescing}{Device Types / Network Device / Device Operation / Control Virtqueue / Notifications Coalescing}
> > >>
> > >> -A device SHOULD respond to the VIRTIO_NET_CTRL_NOTF_COAL commands with VIRTIO_NET_ERR if it was not able to change the parameters.
> > >> +A device SHOULD respond to VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and VIRTIO_NET_CTRL_NOTF_COAL_RX_SET commands with VIRTIO_NET_ERR if it was not able to change the parameters.
> > >> +
> > >> +A device MUST respond to the VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET command with VIRTIO_NET_ERR if it was not able to change the parameters.
> > >> +
> > >> +A device MUST respond to VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET and VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET commands with VIRTIO_NET_ERR if the given virtqueue is disabled.
> > >> +
> > >> +A device MUST ignore \field{reserved}.
> > >>
> > >> A device SHOULD NOT send used buffer notifications to the driver if the notifications are suppressed, even if the notification conditions are met.
> > >>
> > >> -Upon reset, a device MUST initialize all coalescing parameters to 0.
> > >> +After disabling and re-enabling a virtqueue, the device MUST revert coalescing parameters of the virtqueue to the global values.
> > >> +
> > >> +Upon reset, a device MUST initialize all coalescing parameters to 0 and MUST set the global values to 0.
> > >>
> > >> \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > >> Types / Network Device / Legacy Interface: Framing Requirements}
> > >> --
> > > Let's wait for more comments before the next version, I guess some may
> > > not agree with my comments.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-02-27 20:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-26 9:37 [virtio-comment] [PATCH v9] virtio-net: support the virtqueue coalescing moderation Heng Qi
2023-02-26 9:37 ` [virtio-dev] " Heng Qi
2023-02-26 19:33 ` [virtio-comment] " Alvaro Karsz
2023-02-26 19:33 ` [virtio-dev] " Alvaro Karsz
2023-02-27 13:02 ` Heng Qi
2023-02-27 16:25 ` [virtio-comment] " Heng Qi
2023-02-27 16:25 ` Heng Qi
2023-02-27 16:27 ` [virtio-comment] " Parav Pandit
2023-02-27 16:27 ` [virtio-dev] " Parav Pandit
2023-02-27 18:45 ` Alvaro Karsz
2023-02-27 20:19 ` Michael S. Tsirkin [this message]
2023-02-27 20:41 ` [virtio-comment] " Alvaro Karsz
2023-02-27 20:41 ` Alvaro Karsz
2023-02-28 2:41 ` [virtio-comment] " Heng Qi
2023-02-28 2:41 ` Heng Qi
2023-02-28 7:49 ` [virtio-comment] " Michael S. Tsirkin
2023-02-28 7:49 ` Michael S. Tsirkin
2023-02-28 8:10 ` [virtio-comment] " Heng Qi
2023-02-28 8:10 ` [virtio-dev] " Heng Qi
2023-02-28 1:40 ` [virtio-comment] " Parav Pandit
2023-02-28 1:40 ` [virtio-dev] " Parav Pandit
2023-02-28 2:19 ` [virtio-comment] " Heng Qi
2023-02-28 2:19 ` [virtio-dev] " Heng Qi
2023-02-28 7:47 ` [virtio-comment] " Michael S. Tsirkin
2023-02-28 7:47 ` [virtio-dev] " Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230227151420-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alvaro.karsz@solid-run.com \
--cc=david.edmondson@oracle.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox