virtio-comment.lists.oasis-open.org archive mirror
 help / color / mirror / Atom feed
* [virtio-comment] [PATCH v13] virtio-net: support the virtqueue coalescing moderation
@ 2023-03-22 12:51 Heng Qi
  2023-03-22 15:20 ` [virtio-comment] " Cornelia Huck
  0 siblings, 1 reply; 13+ messages in thread
From: Heng Qi @ 2023-03-22 12:51 UTC (permalink / raw)
  To: virtio-dev, virtio-comment
  Cc: Cornelia Huck, Michael S . Tsirkin, Parav Pandit, Jason Wang,
	Alvaro Karsz, David Edmondson, Xuan Zhuo

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>
Reviewed-by: Parav Pandit <parav@nvidia.com>
---
v12->v13:
       1. Added normative statement that driver must not send invalid \field{vqn}. @Cornelia Huck
       2. Some minor modifications. @Cornelia Huck

v11->v12:
       1. Use virtqueue having vqn N instead of virtqueueN. @Parav Pandit
       2. Some minor modifications. @Parav Pandit, @Michael S . Tsirkin
       3. Add Parav's Reviewed-by tag (Thanks!).

v10->v11:
       1. Describe read and write attributes for the structure. @Parav Pandit
       2. Some minor modifications. @Parav Pandit

v9->v10:
       1. Remove the "global values". @Parav Pandit
       2. Avoid multiple interpretations of command behavior. @Alvaro Karsz

v8->v9:
       1. Declare the commands that can be sent for each feature. @Alvaro Karsz
       2. Add information about "global values" in the command's explanation. @Alvaro Karsz

v7->v8:
       1. Use "best-effort" in Alvaro's patch instead of "the device may set the parameter to a value close to 2". @Michael S . Tsirkin, @David Edmondson

v6->v7:
       1. Clarify the relationship of VIRTIO_NET_CTRL_NOTF_COAL_TX/RX_SET and VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET. @Alvaro Karsz, @Michael S. Tsirkin
       2. Remove the formula for vqn range. @Parav Pandit
       3. Some expressions are clearer. @Parav Pandit, @Michael S. Tsirkin

v5->v6:
       1. Explain that the device may set a different value than the one passed in by the driver. @David Edmondson

v4->v5:
       1. Add the correspondence between virtio_net_ctrl_coal and virtio_net_ctrl_coal_vq and control commands. @Michael S. Tsirkin
       2. Add read and write attributes for each field. @Michael S. Tsirkin
       3. A clearer description of how to set coalescing parameters for vq reset. @Michael S. Tsirkin
       4. Fix some syntax errors. @Michael S. Tsirkin, @David Edmondson

v3->v4:
       1. Include virtio_net_ctrl_coal in the virtio_net_ctrl_coal_vq structure. @Alvaro Karsz
       2. Add consideration of vq reset. @Michael S. Tsirkin, @Parav Pandit, @Alvaro Karsz
       3. Avoid too many examples by giving a comprehensive example. @Michael S. Tsirkin
       4. Fix typos and streamline clarifications. @Michael S. Tsirkin, @Parav Pandit, @Alvaro Karsz

v2->v3:
       1. Add the netdim link. @Parav Pandit
       2. VIRTIO_NET_F_VQ_NOTF_COAL no longer depends on VIRTIO_NET_F_NOTF_COAL. @Michael S. Tsirkin, @Alvaro Karsz
       3. _VQ_GET is explained more. @Michael S. Tsirkin
       4. Add more examples to avoid misunderstandings. @Michael S. Tsirkin
       5. Clarify some statements. @Michael S. Tsirkin, @Parav Pandit, @Alvaro Karsz
       6. Adjust the virtio_net_ctrl_coal_vq structure. @Michael S. Tsirkin
       7. Fix some typos. @Michael S. Tsirkin

v1->v2:
       1. Rename VIRTIO_NET_F_PERQUEUE_NOTF_COAL to VIRTIO_NET_F_VQ_NOTF_COAL. @Michael S. Tsirkin
       2. Use the \field{vqn} instead of the qid. @Michael S. Tsirkin
       3. Unify tx and rx control structures into one structure virtio_net_ctrl_coal_vq. @Michael S. Tsirkin
       4. Add a new control command VIRTIO_NET_CTRL_NOTF_COAL_VQ. @Michael S. Tsirkin, @Parav Pandit, @Alvaro Karsz
       5. The special value 0xFFF is removed because VIRTIO_NET_CTRL_NOTF_COAL can be used. @Alvaro Karsz
       6. Clarify some special scenarios. @Michael S. Tsirkin, @Parav Pandit, @Alvaro Karsz

 device-types/net/description.tex | 82 ++++++++++++++++++++++++++++----
 1 file changed, 72 insertions(+), 10 deletions(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index e71e33b..24a3f81 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}
@@ -1506,12 +1509,12 @@ \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.
+send commands VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and VIRTIO_NET_CTRL_NOTF_COAL_RX_SET
+for notification coalescing.
 
-\begin{note}
-The behavior of the device in response to these commands is best-effort:
-the device may generate notifications more or less frequently than specified.
-\end{note}
+If the VIRTIO_NET_F_VQ_NOTF_COAL feature is negotiated, the driver can
+send commands VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET and VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET
+for virtqueue notification coalescing.
 
 \begin{lstlisting}
 struct virtio_net_ctrl_coal {
@@ -1519,25 +1522,63 @@ \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}
 
 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 the device.
+
+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, the structure virtio_net_ctrl_coal is write-only for the driver.
+\item For the command VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET, the structure virtio_net_ctrl_coal_vq is write-only for the driver.
+\item For the command VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET, \field{vqn} and \field{reserved} are write-only
+      for the driver, and the structure virtio_net_ctrl_coal is read-only for the driver.
+\end{itemize}
+
+The class VIRTIO_NET_CTRL_NOTF_COAL has the following 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 two 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 virtqueues having vqn 0 and vqn 2. Virtqueues having vqn 1 and vqn 3 retain their previous parameters.
+\item Command2: VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET with \field{vqn} = 0 sets coalescing parameters for virtqueue 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 vqn 0 set by command2.
+\item Command4: VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET with \field{vqn} = 1 sets coalescing parameters for virtqueue having vqn 1. Virtqueue having vqn 3 retains its previous parameters.
+\item Command5: VIRTIO_NET_CTRL_NOTF_COAL_TX_SET sets coalescing parameters for virtqueues having vqn 1 and vqn 3, and overrides the parameters set by command4.
+\item Command6: VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET with \field{vqn} = 1, the device responds with coalescing parameters of vqn 1 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}.
@@ -1585,11 +1626,32 @@ \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.
+The driver MUST NOT set \field{vqn} to any value other than an enabled transmit or receive virtqueue number.
+
+The driver MUST have negotiated the VIRTIO_NET_F_NOTF_COAL feature when issuing commands VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and VIRTIO_NET_CTRL_NOTF_COAL_RX_SET.
+
+The driver MUST have negotiated the VIRTIO_NET_F_VQ_NOTF_COAL feature when issuing commands VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET and VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET.
+
+The driver MUST ignore the values of coalescing parameters received from the VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET command if the 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.
+The device MUST ignore \field{reserved}.
+
+The 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.
+
+The 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.
+
+The 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 designated virtqueue is disabled.
+
+Upon disabling and re-enabling a transmit virtqueue, the device MUST set the coalescing parameters of the virtqueue
+to those configured through the VIRTIO_NET_CTRL_NOTF_COAL_TX_SET command, or, if the driver did not set any TX coalescing parameters, to 0.
+
+Upon disabling and re-enabling a receive virtqueue, the device MUST set the coalescing parameters of the virtqueue
+to those configured through the VIRTIO_NET_CTRL_NOTF_COAL_RX_SET command, or, if the driver did not set any RX coalescing parameters, to 0.
+
+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.
 
 A device SHOULD NOT send used buffer notifications to the driver if the notifications are suppressed, even if the notification conditions are met.
 
-- 
2.19.1.6.gb485710b


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [virtio-comment] Re: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 12:51 [virtio-comment] [PATCH v13] virtio-net: support the virtqueue coalescing moderation Heng Qi
@ 2023-03-22 15:20 ` Cornelia Huck
  2023-03-22 16:23   ` [virtio-comment] " Parav Pandit
  0 siblings, 1 reply; 13+ messages in thread
From: Cornelia Huck @ 2023-03-22 15:20 UTC (permalink / raw)
  To: Heng Qi, virtio-dev, virtio-comment
  Cc: Michael S . Tsirkin, Parav Pandit, Jason Wang, Alvaro Karsz,
	David Edmondson, Xuan Zhuo

On Wed, Mar 22 2023, Heng Qi <hengqi@linux.alibaba.com> wrote:

> +The driver MUST NOT set \field{vqn} to any value other than an enabled transmit or receive virtqueue number.

"than the virtqueue number of an enabled transmit or receive virtqueue"

might be better -- what do others think?

Otherwise, LGTM.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 15:20 ` [virtio-comment] " Cornelia Huck
@ 2023-03-22 16:23   ` Parav Pandit
  2023-03-22 16:36     ` Cornelia Huck
  0 siblings, 1 reply; 13+ messages in thread
From: Parav Pandit @ 2023-03-22 16:23 UTC (permalink / raw)
  To: Cornelia Huck, Heng Qi, virtio-dev, virtio-comment
  Cc: Michael S . Tsirkin, Jason Wang, Alvaro Karsz, David Edmondson,
	Xuan Zhuo



> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Wednesday, March 22, 2023 11:21 AM
> 
> On Wed, Mar 22 2023, Heng Qi <hengqi@linux.alibaba.com> wrote:
> 
> > +The driver MUST NOT set \field{vqn} to any value other than an enabled
> transmit or receive virtqueue number.
> 
Why do you suggest a negative statement here?
How is it better than,
The driver MUST set ...

The device will anyway have to check and apply the parameter to the right virtqueue.
And if the vq is not enabled or vq is not tx or rx vq, it needs to fail the command.

> "than the virtqueue number of an enabled transmit or receive virtqueue"
> 
> might be better -- what do others think?
> 
> Otherwise, LGTM.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:23   ` [virtio-comment] " Parav Pandit
@ 2023-03-22 16:36     ` Cornelia Huck
  2023-03-22 16:40       ` Parav Pandit
  0 siblings, 1 reply; 13+ messages in thread
From: Cornelia Huck @ 2023-03-22 16:36 UTC (permalink / raw)
  To: Parav Pandit, Heng Qi, virtio-dev, virtio-comment
  Cc: Michael S . Tsirkin, Jason Wang, Alvaro Karsz, David Edmondson,
	Xuan Zhuo

On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Wednesday, March 22, 2023 11:21 AM
>> 
>> On Wed, Mar 22 2023, Heng Qi <hengqi@linux.alibaba.com> wrote:
>> 
>> > +The driver MUST NOT set \field{vqn} to any value other than an enabled
>> transmit or receive virtqueue number.
>> 
> Why do you suggest a negative statement here?
> How is it better than,
> The driver MUST set ...

So make it

"The driver MUST set \field{vqn} to the virtqueue number of an enabled
transmit or receive virtqueue." ?

Although I find this slightly less compelling than "do not set vqn to
anything else".

>
> The device will anyway have to check and apply the parameter to the right virtqueue.
> And if the vq is not enabled or vq is not tx or rx vq, it needs to fail the command.

Well, I think we want to avoid having to add a normative statement for
the device, so we need to be strict with what the driver is allowed to
do.

>
>> "than the virtqueue number of an enabled transmit or receive virtqueue"
>> 
>> might be better -- what do others think?
>> 
>> Otherwise, LGTM.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:36     ` Cornelia Huck
@ 2023-03-22 16:40       ` Parav Pandit
  2023-03-22 16:44         ` Cornelia Huck
  0 siblings, 1 reply; 13+ messages in thread
From: Parav Pandit @ 2023-03-22 16:40 UTC (permalink / raw)
  To: Cornelia Huck, Heng Qi, virtio-dev, virtio-comment
  Cc: Michael S . Tsirkin, Jason Wang, Alvaro Karsz, David Edmondson,
	Xuan Zhuo



> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Wednesday, March 22, 2023 12:37 PM
> 
> On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> >> From: Cornelia Huck <cohuck@redhat.com>
> >> Sent: Wednesday, March 22, 2023 11:21 AM
> >>
> >> On Wed, Mar 22 2023, Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>
> >> > +The driver MUST NOT set \field{vqn} to any value other than an
> >> > +enabled
> >> transmit or receive virtqueue number.
> >>
> > Why do you suggest a negative statement here?
> > How is it better than,
> > The driver MUST set ...
> 
> So make it
> 
> "The driver MUST set \field{vqn} to the virtqueue number of an enabled
> transmit or receive virtqueue." ?
> 
Looks good.

> > The device will anyway have to check and apply the parameter to the right
> virtqueue.
> > And if the vq is not enabled or vq is not tx or rx vq, it needs to fail the
> command.
> 
> Well, I think we want to avoid having to add a normative statement for the
> device, so we need to be strict with what the driver is allowed to do.
Drivers are untrusted entities.
device normative statement is needed, it will do the checks anyway where it is applying the config.

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:40       ` Parav Pandit
@ 2023-03-22 16:44         ` Cornelia Huck
  2023-03-22 16:46           ` Parav Pandit
  2023-03-22 16:46           ` Michael S. Tsirkin
  0 siblings, 2 replies; 13+ messages in thread
From: Cornelia Huck @ 2023-03-22 16:44 UTC (permalink / raw)
  To: Parav Pandit, Heng Qi, virtio-dev, virtio-comment
  Cc: Michael S . Tsirkin, Jason Wang, Alvaro Karsz, David Edmondson,
	Xuan Zhuo

On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Wednesday, March 22, 2023 12:37 PM
>> 
>> On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:
>> 
>> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> Sent: Wednesday, March 22, 2023 11:21 AM
>> >>
>> >> On Wed, Mar 22 2023, Heng Qi <hengqi@linux.alibaba.com> wrote:
>> >>
>> >> > +The driver MUST NOT set \field{vqn} to any value other than an
>> >> > +enabled
>> >> transmit or receive virtqueue number.
>> >>
>> > Why do you suggest a negative statement here?
>> > How is it better than,
>> > The driver MUST set ...
>> 
>> So make it
>> 
>> "The driver MUST set \field{vqn} to the virtqueue number of an enabled
>> transmit or receive virtqueue." ?
>> 
> Looks good.
>
>> > The device will anyway have to check and apply the parameter to the right
>> virtqueue.
>> > And if the vq is not enabled or vq is not tx or rx vq, it needs to fail the
>> command.
>> 
>> Well, I think we want to avoid having to add a normative statement for the
>> device, so we need to be strict with what the driver is allowed to do.
> Drivers are untrusted entities.
> device normative statement is needed, it will do the checks anyway where it is applying the config.

But isn't that implementation specific? I.e. if the driver sends junk,
the device needs to be able to deal with it in any case.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:44         ` Cornelia Huck
@ 2023-03-22 16:46           ` Parav Pandit
  2023-03-22 16:50             ` Michael S. Tsirkin
  2023-03-22 16:46           ` Michael S. Tsirkin
  1 sibling, 1 reply; 13+ messages in thread
From: Parav Pandit @ 2023-03-22 16:46 UTC (permalink / raw)
  To: Cornelia Huck, Heng Qi, virtio-dev, virtio-comment
  Cc: Michael S . Tsirkin, Jason Wang, Alvaro Karsz, David Edmondson,
	Xuan Zhuo


> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Wednesday, March 22, 2023 12:44 PM
> 
> >> Well, I think we want to avoid having to add a normative statement
> >> for the device, so we need to be strict with what the driver is allowed to do.
> > Drivers are untrusted entities.
> > device normative statement is needed, it will do the checks anyway where it
> is applying the config.
> 
> But isn't that implementation specific? I.e. if the driver sends junk, the device
> needs to be able to deal with it in any case.
Not sure which part is implementation specific.
The device will deal with it and return an error code when supplied qid is invalid (of cvq or of disabled vq).

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:44         ` Cornelia Huck
  2023-03-22 16:46           ` Parav Pandit
@ 2023-03-22 16:46           ` Michael S. Tsirkin
  2023-03-22 16:49             ` Parav Pandit
  1 sibling, 1 reply; 13+ messages in thread
From: Michael S. Tsirkin @ 2023-03-22 16:46 UTC (permalink / raw)
  To: Cornelia Huck
  Cc: Parav Pandit, Heng Qi, virtio-dev, virtio-comment, Jason Wang,
	Alvaro Karsz, David Edmondson, Xuan Zhuo

On Wed, Mar 22, 2023 at 05:44:27PM +0100, Cornelia Huck wrote:
> On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> >> From: Cornelia Huck <cohuck@redhat.com>
> >> Sent: Wednesday, March 22, 2023 12:37 PM
> >> 
> >> On Wed, Mar 22 2023, Parav Pandit <parav@nvidia.com> wrote:
> >> 
> >> >> From: Cornelia Huck <cohuck@redhat.com>
> >> >> Sent: Wednesday, March 22, 2023 11:21 AM
> >> >>
> >> >> On Wed, Mar 22 2023, Heng Qi <hengqi@linux.alibaba.com> wrote:
> >> >>
> >> >> > +The driver MUST NOT set \field{vqn} to any value other than an
> >> >> > +enabled
> >> >> transmit or receive virtqueue number.
> >> >>
> >> > Why do you suggest a negative statement here?
> >> > How is it better than,
> >> > The driver MUST set ...
> >> 
> >> So make it
> >> 
> >> "The driver MUST set \field{vqn} to the virtqueue number of an enabled
> >> transmit or receive virtqueue." ?
> >> 
> > Looks good.
> >
> >> > The device will anyway have to check and apply the parameter to the right
> >> virtqueue.
> >> > And if the vq is not enabled or vq is not tx or rx vq, it needs to fail the
> >> command.
> >> 
> >> Well, I think we want to avoid having to add a normative statement for the
> >> device, so we need to be strict with what the driver is allowed to do.
> > Drivers are untrusted entities.
> > device normative statement is needed, it will do the checks anyway where it is applying the config.
> 
> But isn't that implementation specific? I.e. if the driver sends junk,
> the device needs to be able to deal with it in any case.

I agree with Cornelia here. Yes if devices do not want to trust drivers
then they will validate input but what exactly happens then is
currently up to device.
If we want to try and specify devices in all cases of out of spec
input that's a big project, certainly doable but I would rather
not connect it to this, rather boutique, feature.


-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:46           ` Michael S. Tsirkin
@ 2023-03-22 16:49             ` Parav Pandit
  2023-03-22 16:53               ` Michael S. Tsirkin
  0 siblings, 1 reply; 13+ messages in thread
From: Parav Pandit @ 2023-03-22 16:49 UTC (permalink / raw)
  To: Michael S. Tsirkin, Cornelia Huck
  Cc: Heng Qi, virtio-dev, virtio-comment, Jason Wang, Alvaro Karsz,
	David Edmondson, Xuan Zhuo


> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, March 22, 2023 12:47 PM
> 
> I agree with Cornelia here. Yes if devices do not want to trust drivers then they
> will validate input but what exactly happens then is currently up to device.
> If we want to try and specify devices in all cases of out of spec input that's a big
> project, certainly doable but I would rather not connect it to this, rather
> boutique, feature.
Both of your and Cornelia's comment is abstract to me.
We cannot change past.
For the new command of interest here, hen driver supplied incorrect values, the device will return error.
How to implement is upto the device to figure out.

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:46           ` Parav Pandit
@ 2023-03-22 16:50             ` Michael S. Tsirkin
  0 siblings, 0 replies; 13+ messages in thread
From: Michael S. Tsirkin @ 2023-03-22 16:50 UTC (permalink / raw)
  To: Parav Pandit
  Cc: Cornelia Huck, Heng Qi, virtio-dev, virtio-comment, Jason Wang,
	Alvaro Karsz, David Edmondson, Xuan Zhuo

On Wed, Mar 22, 2023 at 04:46:36PM +0000, Parav Pandit wrote:
> 
> > From: Cornelia Huck <cohuck@redhat.com>
> > Sent: Wednesday, March 22, 2023 12:44 PM
> > 
> > >> Well, I think we want to avoid having to add a normative statement
> > >> for the device, so we need to be strict with what the driver is allowed to do.
> > > Drivers are untrusted entities.
> > > device normative statement is needed, it will do the checks anyway where it
> > is applying the config.
> > 
> > But isn't that implementation specific? I.e. if the driver sends junk, the device
> > needs to be able to deal with it in any case.
> Not sure which part is implementation specific.
> The device will deal with it and return an error code when supplied qid is invalid (of cvq or of disabled vq).

spec currently defines, generally, how devices behave if driver matches
spec. We do not generally specify what happens if driver is out of spec.
For example it's ok for device to just get wedged until reset.
It's doable to change this but if yes we should do it over the board.
And the benefit, IMHO, is limited.
And doing it just for the coalescing commands would be super weird.


-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:49             ` Parav Pandit
@ 2023-03-22 16:53               ` Michael S. Tsirkin
  2023-03-22 17:02                 ` Parav Pandit
  0 siblings, 1 reply; 13+ messages in thread
From: Michael S. Tsirkin @ 2023-03-22 16:53 UTC (permalink / raw)
  To: Parav Pandit
  Cc: Cornelia Huck, Heng Qi, virtio-dev, virtio-comment, Jason Wang,
	Alvaro Karsz, David Edmondson, Xuan Zhuo

On Wed, Mar 22, 2023 at 04:49:58PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, March 22, 2023 12:47 PM
> > 
> > I agree with Cornelia here. Yes if devices do not want to trust drivers then they
> > will validate input but what exactly happens then is currently up to device.
> > If we want to try and specify devices in all cases of out of spec input that's a big
> > project, certainly doable but I would rather not connect it to this, rather
> > boutique, feature.
> Both of your and Cornelia's comment is abstract to me.
> We cannot change past.

But we can make sure things are consistent. Currently we don't describe
device behaviour if driver is out of spec and I see 0 reasons to start
doing it with coalescing commands specifically.

> For the new command of interest here, hen driver supplied incorrect values, the device will return error.

It might be easier for device to just set NEEDS_RESET and stop
responding. For a hypervisor implementation that's often better than returning error
since device state is then preserved making things easier to debug.

> How to implement is upto the device to figure out.


what to do is also up to the device.

-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 16:53               ` Michael S. Tsirkin
@ 2023-03-22 17:02                 ` Parav Pandit
  2023-03-23  2:26                   ` [virtio-comment] Re: [virtio-dev] " Heng Qi
  0 siblings, 1 reply; 13+ messages in thread
From: Parav Pandit @ 2023-03-22 17:02 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Cornelia Huck, Heng Qi, virtio-dev, virtio-comment, Jason Wang,
	Alvaro Karsz, David Edmondson, Xuan Zhuo


> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, March 22, 2023 12:53 PM
> 
> On Wed, Mar 22, 2023 at 04:49:58PM +0000, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Wednesday, March 22, 2023 12:47 PM
> > >
> > > I agree with Cornelia here. Yes if devices do not want to trust
> > > drivers then they will validate input but what exactly happens then is
> currently up to device.
> > > If we want to try and specify devices in all cases of out of spec
> > > input that's a big project, certainly doable but I would rather not
> > > connect it to this, rather boutique, feature.
> > Both of your and Cornelia's comment is abstract to me.
> > We cannot change past.
> 
> But we can make sure things are consistent. Currently we don't describe device
> behaviour if driver is out of spec and I see 0 reasons to start doing it with
> coalescing commands specifically.
> 
> > For the new command of interest here, hen driver supplied incorrect values,
> the device will return error.
> 
> It might be easier for device to just set NEEDS_RESET and stop responding. 
This approach of treating all errors as a fatal category is completely the opposite of making the device and driver resilient to (recoverable) errors.
We shouldn't go this route.
Different discussion...

> For
> a hypervisor implementation that's often better than returning error since
> device state is then preserved making things easier to debug.
> 
> > How to implement is upto the device to figure out.
> 
> 
> what to do is also up to the device.
Previously error code as not returned hence new command cannot return the error code is going backward.

Returning the failure code is a way to indicate that the driver had a recoverable error.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [virtio-comment] Re: [virtio-dev] RE: [virtio-comment] RE: [PATCH v13] virtio-net: support the virtqueue coalescing moderation
  2023-03-22 17:02                 ` Parav Pandit
@ 2023-03-23  2:26                   ` Heng Qi
  0 siblings, 0 replies; 13+ messages in thread
From: Heng Qi @ 2023-03-23  2:26 UTC (permalink / raw)
  To: Parav Pandit, Michael S. Tsirkin
  Cc: Cornelia Huck, virtio-dev, virtio-comment, Jason Wang,
	Alvaro Karsz, David Edmondson, Xuan Zhuo



在 2023/3/23 上午1:02, Parav Pandit 写道:
>> From: Michael S. Tsirkin <mst@redhat.com>
>> Sent: Wednesday, March 22, 2023 12:53 PM
>>
>> On Wed, Mar 22, 2023 at 04:49:58PM +0000, Parav Pandit wrote:
>>>> From: Michael S. Tsirkin <mst@redhat.com>
>>>> Sent: Wednesday, March 22, 2023 12:47 PM
>>>>
>>>> I agree with Cornelia here. Yes if devices do not want to trust
>>>> drivers then they will validate input but what exactly happens then is
>> currently up to device.
>>>> If we want to try and specify devices in all cases of out of spec
>>>> input that's a big project, certainly doable but I would rather not
>>>> connect it to this, rather boutique, feature.
>>> Both of your and Cornelia's comment is abstract to me.
>>> We cannot change past.
>> But we can make sure things are consistent. Currently we don't describe device
>> behaviour if driver is out of spec and I see 0 reasons to start doing it with
>> coalescing commands specifically.
>>
>>> For the new command of interest here, hen driver supplied incorrect values,
>> the device will return error.
>>
>> It might be easier for device to just set NEEDS_RESET and stop responding.
> This approach of treating all errors as a fatal category is completely the opposite of making the device and driver resilient to (recoverable) errors.
> We shouldn't go this route.
> Different discussion...
>
>> For
>> a hypervisor implementation that's often better than returning error since
>> device state is then preserved making things easier to debug.
>>
>>> How to implement is upto the device to figure out.
>>
>> what to do is also up to the device.
> Previously error code as not returned hence new command cannot return the error code is going backward.
>
> Returning the failure code is a way to indicate that the driver had a recoverable error.

I agree with you. Part of the specification [1] covered something we're 
talking about, e.g. if an untrusted driver sends a disabled vq, the 
device returns an error:

[1] +The 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 
designated virtqueue is disabled.

Maybe we should modify [1] to:

"The 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 
designated \field{vqn} is not the virtqueue number of an enabled 
transmit or receive virtqueue."


Thanks!


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


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2023-03-23  2:27 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-22 12:51 [virtio-comment] [PATCH v13] virtio-net: support the virtqueue coalescing moderation Heng Qi
2023-03-22 15:20 ` [virtio-comment] " Cornelia Huck
2023-03-22 16:23   ` [virtio-comment] " Parav Pandit
2023-03-22 16:36     ` Cornelia Huck
2023-03-22 16:40       ` Parav Pandit
2023-03-22 16:44         ` Cornelia Huck
2023-03-22 16:46           ` Parav Pandit
2023-03-22 16:50             ` Michael S. Tsirkin
2023-03-22 16:46           ` Michael S. Tsirkin
2023-03-22 16:49             ` Parav Pandit
2023-03-22 16:53               ` Michael S. Tsirkin
2023-03-22 17:02                 ` Parav Pandit
2023-03-23  2:26                   ` [virtio-comment] Re: [virtio-dev] " Heng Qi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).