OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]