Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Heng Qi <hengqi@linux.alibaba.com>
To: Parav Pandit <parav@nvidia.com>,
	virtio-dev@lists.oasis-open.org,
	virtio-comment@lists.oasis-open.org
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
	Alvaro Karsz <alvaro.karsz@solid-run.com>,
	David Edmondson <david.edmondson@oracle.com>,
	Jason Wang <jasowang@redhat.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: [virtio-dev] Re: [PATCH v11] virtio-net: support the virtqueue coalescing moderation
Date: Fri, 10 Mar 2023 13:18:40 +0800	[thread overview]
Message-ID: <a32a3410-28cf-aa93-3633-976acb99a239@linux.alibaba.com> (raw)
In-Reply-To: <8734c0de-b041-a4ba-9f48-44dc4ceeb513@nvidia.com>


在 2023/3/10 上午2:53, Parav Pandit 写道:
>
>
> On 3/9/2023 8:05 AM, Heng Qi wrote:
>> Currently, coalescing parameters are grouped for all transmit and 
>> receive
>> virtqueues. This patch supports setting or getting the parameters for a
>> specified virtqueue, and a typical application of this function is 
>> netdim[1].
>>
>> When the traffic between virtqueues is unbalanced, for example, one 
>> virtqueue
>> is busy and another virtqueue is idle, then it will be very useful to
>> control coalescing parameters at the virtqueue granularity.
>>
>> [1] https://docs.kernel.org/networking/net_dim.html
>>
>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> [..]
>>   device-types/net/description.tex | 86 ++++++++++++++++++++++++++++----
>>   1 file changed, 75 insertions(+), 11 deletions(-)
>>
>> diff --git a/device-types/net/description.tex 
>> b/device-types/net/description.tex
>> index e71e33b..c896485 100644
>> --- a/device-types/net/description.tex
>> +++ b/device-types/net/description.tex
>> @@ -83,6 +83,8 @@ \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_VQ_NOTF_COAL(52)] Device supports virtqueue 
>> notification coalescing.
>> +
>>   \item[VIRTIO_NET_F_NOTF_COAL(53)] Device supports notifications 
>> coalescing.
>>     \item[VIRTIO_NET_F_GUEST_USO4 (54)] Driver can receive USOv4 
>> packets.
>> @@ -139,6 +141,7 @@ \subsubsection{Feature bit 
>> requirements}\label{sec:Device Types / Network Device
>>   \item[VIRTIO_NET_F_NOTF_COAL] 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.
>> +\item[VIRTIO_NET_F_VQ_NOTF_COAL] Requires VIRTIO_NET_F_CTRL_VQ.
>>   \end{description}
>>     \subsubsection{Legacy Interface: Feature bits}\label{sec:Device 
>> Types / Network Device / Feature bits / Legacy Interface: Feature bits}
>> @@ -1505,13 +1508,13 @@ \subsubsection{Control 
>> Virtqueue}\label{sec:Device Types / Network Device / Devi
>>     \paragraph{Notifications Coalescing}\label{sec:Device Types / 
>> Network Device / Device Operation / Control Virtqueue / Notifications 
>> Coalescing}
>>   -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, a driver can send
> Above text had "the driver".
> Better to not change it.

Ok.

>
> dynamically changing got dropped, better to keep it.

The motivation for this modification comes from Alvaro. We only need to 
say here that
feature A can send B, instead of repeatedly mentioning "action: 
dynamically changing the coalescing parameters."
and "object: for all tx/rx virtqueues or for the virtqueue with vqn" 
every time a command is mentioned.

>
>> +commands VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and 
>> VIRTIO_NET_CTRL_NOTF_COAL_RX_SET
>> +for notification coalescing.
>
>
> [..]
>
>> +\begin{itemize}
>> +\item For commands VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and 
>> VIRTIO_NET_CTRL_NOTF_COAL_RX_SET, the structure virtio_net_ctrl_coal 
>> is write-only for a driver.
>> +\item For the command VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET, the 
>> structure virtio_net_ctrl_coal_vq is 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, the structure virtio_net_ctrl_coal is 
>> read-only for the driver.
> for a driver and the structure ..
> drop extra ",".

I'll remove it.

>
>> +\end{itemize}
>> +
>> +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: use the structure 
>> virtio_net_ctrl_coal to set the \field{max_usecs} and 
>> \field{max_packets} parameters for all transmit virtqueues.
>> +\item VIRTIO_NET_CTRL_NOTF_COAL_RX_SET: use the structure 
>> virtio_net_ctrl_coal to set the \field{max_usecs} and 
>> \field{max_packets} parameters for all receive virtqueues.
>> +\item VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET: use the structure 
>> virtio_net_ctrl_coal_vq to set the \field{max_usecs} and 
>> \field{max_packets} parameters
>> +                                        for an enabled 
>> transmit/receive virtqueue whose number is \field{vqn}.
>> +\item VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET: use the structure 
>> virtio_net_ctrl_coal_vq to get the \field{max_usecs} and 
>> \field{max_packets} parameters
>> +                                        for an enabled 
>> transmit/receive virtqueue whose number is \field{vqn}.
>>   \end{enumerate}
>>   +The device may generate notifications more or less frequently than 
>> specified by set commands of the VIRTIO_NET_CTRL_NOTF_COAL class.
>> +
>> +If coalescing parameters are being set, the device applies the last 
>> coalescing parameters set for a
>> +virtqueue, regardless of the command used to set the parameters. Use 
>> the following command sequence
>> +with 2 pairs of virtqueues as an example:
>> +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.
> above "and" is confusing. It implies set on vq0,vq2 and vq1, vq3.
> Same for below Command2 as well.
> It also introduces new terms as virtqueue0 and virtqueueN.
> It is better to avoid.

Indeed, I agree.

>
> Rewriting it as below avoids creating new terms and avoids confusion 
> around "and".
>
> Command1: VIRTIO_NET_CTRL_NOTF_COAL_RX_SET sets coalescing parameters 
> for virtqueues having vqn 0 and vqn 2. Virtqueues having vqn 1 and 3 
> retain their previous parameters.
>

I think it works, thanks for the example.

>> +\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.
> Command2: VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET with \field{vqn} sets 
> coalescing parameters for the virtuqueue having vqn 0. Virtqueue 
> having vqn 2 retains the parameters 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.
> parameters of vqn 0 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.for vqn 1. Virtqueue having vqn 3 retains its 
>> previous parameters.
>> +\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}
>> +
>> +Upon disabling and re-enabling the transmit virtqueue, the device 
>> will set the coalescing parameters of the virtqueue
>> +to those configured through the VIRTIO_NET_CTRL_NOTF_COAL_TX_SET 
>> command, or to 0 if the command did not set any TX coalescing 
>> parameters.
>> +
> s/if the command/if the driver/
>
>> +Upon disabling and re-enabling the receive virtqueue, the device 
>> will set the coalescing parameters of the virtqueue
>> +to those configured through the VIRTIO_NET_CTRL_NOTF_COAL_RX_SET 
>> command, or to 0 if the command did not set any RX coalescing 
>> parameters.
>> +
> s/if the command/if the driver/
>> \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}.
>> @@ -1585,14 +1632,31 @@ \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.
>> +A driver MUST negotiate the VIRTIO_NET_F_NOTF_COAL feature before 
>> issuing commands VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and 
>> VIRIO_NET_CTRL_NOTF_COAL_RX_SET.
>> +
>> +A driver MUST negotiate the VIRTIO_NET_F_VQ_NOTF_COAL feature before 
>> issuing commands VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET and 
>> VIRIO_NET_CTRL_NOTF_COAL_VQ_GET.
>> +
>> +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 MUST ignore \field{reserved}.
>> +
>> +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.
>> +
>> +After disabling and re-enabling a transmit/receive virtqueue, the 
>> device MUST set coalescing parameters of the virtqueue
>> +to those configured using the 
>> VIRTIO_NET_CTRL_NOTF_COAL_TX_SET/VIRTIO_NET_CTRL_NOTF_COAL_RX_SET 
>> command, or, if the command
> s/if the command/if the driver/
>> +did not configure TX/RX coalescing parameters, to 0.
>
> Also the sentence structure should be:
> set params to value A configured using method1, else to params B if 
> not configured.
>
> Instead currently it is,
> set params to value A using method1, else not configured to param B.
>
> So to keep if-else pattern:
>
> the device MUST set coalescing parameters of the virtqueue to those 
> configured using the 
> VIRTIO_NET_CTRL_NOTF_COAL_TX_SET/VIRTIO_NET_CTRL_NOTF_COAL_RX_SET 
> command, or to 0 if the driver did not configure TX/RX coalescing 
> parameters.

Ok. Then I think we can move the description of the non-normative part 
here, and keep only one description to avoid repetition. As Michael 
suggested, we keep the 'if then' syntax for readability.

>
> Just like how you wrote it in the non normative places. :)
>
> I still think that disable,re-enable doesnt need to be documented twice.
>
> Keeping it in the conformance section is good enough, specially when 
> the text is exact same.

Sure.

>
>>     A device SHOULD NOT send used buffer notifications to the driver 
>> if the notifications are suppressed, even if the notification 
>> conditions are met.
>>   +The behavior of the device in response to set commands of the 
>> VIRTIO_NET_CTRL_NOTF_COAL class is best-effort:
>> +the device MAY generate notifications more or less frequently than 
>> specified.
>> +
>>   Upon reset, a device MUST initialize all coalescing parameters to 0.
>>     \subsubsection{Legacy Interface: Framing 
>> Requirements}\label{sec:Device
>
> Other than above small wordings change, it looks good to me.
> Reviewed-by: Parav Pandit <parav@nvidia.com>

Thank you very much! :)



---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


      parent reply	other threads:[~2023-03-10  5:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 13:05 [virtio-dev] [PATCH v11] virtio-net: support the virtqueue coalescing moderation Heng Qi
2023-03-09 18:53 ` [virtio-dev] " Parav Pandit
2023-03-09 19:18   ` Michael S. Tsirkin
2023-03-09 20:08     ` [virtio-dev] " Parav Pandit
2023-03-10  5:18   ` Heng Qi [this message]

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=a32a3410-28cf-aa93-3633-976acb99a239@linux.alibaba.com \
    --to=hengqi@linux.alibaba.com \
    --cc=alvaro.karsz@solid-run.com \
    --cc=david.edmondson@oracle.com \
    --cc=jasowang@redhat.com \
    --cc=mst@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