All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	Alvaro Karsz <alvaro.karsz@solid-run.com>,
	Jason Wang <jasowang@redhat.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: [virtio-dev] Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation
Date: Sun, 12 Feb 2023 15:43:45 -0500	[thread overview]
Message-ID: <20230212154046-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB548155EF2CB09C6C88B75C44DCDE9@PH0PR12MB5481.namprd12.prod.outlook.com>

On Fri, Feb 10, 2023 at 07:36:03PM +0000, Parav Pandit wrote:
> 
> 
> > From: Heng Qi <hengqi@linux.alibaba.com>
> > Sent: Friday, February 10, 2023 2:02 AM
> > 
> > Currently, the coalescing profile is directly applied to all queues.
> 
> Say it,
> Currently coalescing parameters are grouped for all transmit and receive virtqueues.
> 
> > This patch supports setting or getting the parameters for a specified queue, and
> > a typical application of this function is NetDIM.
> Many of us know the net dim.
> But if you prefer to mention it here, better to have the link for it.
> 
> Please add pointer to it.
> [1] https://docs.kernel.org/networking/net_dim.html
> 
> > 
> > When the traffic between queues is unbalanced, for example, one queue is
> > busy and another queue is idle, then it will be very useful to control coalescing
> > parameters at the queue granularity.
> > 
> > 
> > +If additionally VIRTIO_NET_F_VQ_NOTF_COAL is negotiated, the driver can
> > +send control commands to set or get the coalescing parameters of a
> Control command singular?

why? driver can send any number of commands e.g. to different vqs.

> > +specified virtqueue (excluding the control virtqueue).
> > +
> > +\begin{lstlisting}
> > +struct virtio_net_ctrl_coal_vq {
> > +    le32 max_packets;
> > +    le32 usecs;
> > +    le16 vqn;
> > +};
> > +
> Change that Michael suggest restructuring and under same class looks good to me.
> 
> > +#define VIRTIO_NET_CTRL_NOTF_COAL_VQ 7
> > + #define VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET 0  #define
> > +VIRTIO_NET_CTRL_NOTF_COAL_VQ_GET 1 \end{lstlisting}
> > +
> > +Virtqueue coalescing parameters:
> > +\begin{itemize}
> > +\item \field{max_packets}: The maximum number of packets sent/received by
> > the
> > +    specified virtqueue before a TX/RX notification.
> > +\item \field{usecs}: The maximum number of TX/RX usecs that the specified
> > +    virtqueue delays a TX/RX notification.
> > +\item \field{vqn}: The virtqueue number of the specified virtqueue.
> > +\end{itemize}
> > +
> The virtqueue number of the enabled transmit or receive virtuqueue.
> This will simplify below description.
> 
> > +The range of \filed{vqn} is between 0 and 0xFFFF inclusive, $ \lfloor
> > +vqn / 2 \rfloor $ is the index of the corresponding receiveq, and
> > +$\lfloor (vqn / 2) + 1 \rfloor $ is the corresponding tranmitq.
> > +
> 
> Please add short description something like,
> 
> When the driver prefers to use per virtqueue notifications coalescing, and if queue group (transmit or receive) level notification coalescing is enabled, driver SHOULD first disable device level notification coalescing.
> Or it should be,
> 
> Virtqueue level notifications coalescing, and device level notifications can be enabled together.
> When both of them are enabled, per virtqueue notifications coalescing take priority over queue group level.

Note that neither of these reflects what I proposed.
I proposed explaining that VIRTIO_NET_CTRL_NOTF_COAL_TX_SET and
VIRTIO_NET_CTRL_NOTF_COAL_RX_SET have the same effect as
repeatedly calling VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET for all TX/RX vqs.

> With rests of the comments from Michael and Alvaro in progress, looks good.


---------------------------------------------------------------------
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-02-12 20:43 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10  7:01 [virtio-comment] [PATCH v2] virtio-net: support the virtqueue coalescing moderation Heng Qi
2023-02-10  8:38 ` [virtio-comment] " Michael S. Tsirkin
2023-02-10  9:30   ` [virtio-dev] " Alvaro Karsz
2023-02-10  9:39     ` [virtio-comment] " Michael S. Tsirkin
2023-02-10  9:53   ` Heng Qi
2023-02-10 10:29     ` [virtio-dev] " Michael S. Tsirkin
2023-02-10 11:19       ` [virtio-comment] " Heng Qi
2023-02-12 20:47         ` Michael S. Tsirkin
2023-02-13  2:36           ` Heng Qi
2023-02-13  8:17             ` Michael S. Tsirkin
2023-02-10  9:22 ` [virtio-comment] " Alvaro Karsz
2023-02-10  9:38   ` Michael S. Tsirkin
2023-02-10 10:00     ` Heng Qi
2023-02-10 10:16       ` [virtio-dev] " Alvaro Karsz
2023-02-10 11:24         ` Heng Qi
2023-02-10 10:31       ` Michael S. Tsirkin
2023-02-10 11:29         ` Heng Qi
2023-02-10  9:57   ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-10 19:36 ` [virtio-comment] " Parav Pandit
2023-02-11  2:01   ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-11  8:45   ` [virtio-comment] " Alvaro Karsz
2023-02-11  9:42     ` Alvaro Karsz
2023-02-11 10:00     ` Heng Qi
2023-02-11 10:18       ` Alvaro Karsz
2023-02-11 13:57         ` Parav Pandit
2023-02-11 15:46           ` Alvaro Karsz
2023-02-11 15:57             ` [virtio-dev] " Parav Pandit
2023-02-11 16:13               ` Alvaro Karsz
2023-02-11 16:22                 ` Parav Pandit
2023-02-13  3:13                 ` Heng Qi
2023-02-12 20:23         ` [virtio-dev] " Michael S. Tsirkin
2023-02-12 20:53           ` Alvaro Karsz
2023-02-12 21:08             ` [virtio-dev] " Michael S. Tsirkin
2023-02-11 13:47     ` [virtio-comment] " Parav Pandit
2023-02-12  9:35       ` [virtio-comment] " Michael S. Tsirkin
2023-02-13  3:17         ` Heng Qi
2023-02-13  2:52       ` Heng Qi
2023-02-12 20:43   ` Michael S. Tsirkin [this message]
2023-02-13  3:21     ` Heng Qi

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=20230212154046-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alvaro.karsz@solid-run.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.