On 4/4/2023 1:44 PM, Michael S. Tsirkin wrote:
On Tue, Apr 04, 2023 at 04:32:07PM +0000, Parav Pandit wrote:
From: Halil Pasic <[email protected]>
Sent: Tuesday, April 4, 2023 12:29 PM
On Thu, 23 Mar 2023 23:24:22 +0800
Heng Qi <[email protected]> wrote:
+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.
Just to be on the safe side: VIRTIO_F_NOTIF_CONFIG_DATA has been
negotiated, and queue_select != queue_notify_data, is vqn supposed to contain
queue_notify_data or the number/index that is used for queue_select (I'm
talking about the PCI transport case)?
Vqn has zero relation to notification config data feature and featue bit.
It is the real vqn enabled via queue_select.
Once the vqn is renamed to vq_notify_id, we won't have this confusion anymore.
vqn here is the index. queue_select is also the index.
Yes to both. No plan to rename them.
Inside notifications-le.c we have:
le32 {
vqn : 16;
next_off : 15;
next_wrap : 1;
};
vqn here is queue_notify_data.
vqn in above unnamed structure is contain
a. either vq index if CONFIG_DATA is not negotiated
or
b. it contains queue_notifiy_data if CONFIG_DATA is negotiated
Therefore, instead of naming it as vqn, renaming it to vq_notify_id
crisply describe what it is for.
And not some vqn n stands for notification, but "d" of data is dropped
somehow.
A notification identifier contains depending on negotiated feature bit.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]