On Fri, Feb 17, 2023 at 06:06:03PM +0800, Heng Qi wrote:
> On Fri, Feb 17, 2023 at 11:40:15AM +0200, Alvaro Karsz wrote:
> > > > Maybe we can use struct virtio_net_ctrl_coal inside struct
> > > > virtio_net_ctrl_coal_vq instead of repeating max_usecs and
> > > > max_packets?
> > > > I'm not sure if it would be confusing, what do you think?
> > > >
> > >
> > > Hi Alvaro.
> > >
> > > I guess you mean one of the following two forms:
> > >
> > > #1
> > > struct virtio_net_ctrl_coal {
> > > le32 max_packets;
> > > le32 max_usecs;
> > > };
> > >
> > > struct virtio_net_ctrl_coal_vq {
> > > le16 vqn;
> > > le16 reserved;
> > > struct virtio_net_ctrl_coal coal;
> > > } coal_vq;
> > >
> > > #2
> > > struct virtio_net_ctrl_coal {
> > > le32 max_packets;
> > > le32 max_usecs;
> > > le16 vqn; // if _F_VQ_NOTF_COAL is negotiated
> > > le16 reserved; // if _F_VQ_NOTF_COAL is negotiated
> > > };
> > >
> > > If it's #1, I think the format is a bit ugly, it's not semantic to use
> > > coal_vq to send global commands when _F_VQ_NOTF_COAL is not negotiated,
> > > and the presence of vqn and reserved is awkward.
> > > If it's #2, I think this is a bit like the v1 version, using
> > > virtio_net_ctrl_coal as a virtual queue to send commands does not seem to
> > > be semantic, but it is indeed more unified in function.
> > >
> > > I think we should hear from Michael and Parav.
> > >
> >
> > I meant #1.
> > We can see virtio_net_ctrl_coal as a struct holding coalescing
> > parameters, regardless of the commands.
> > Yes, let's wait for more comments on that.
> >
> > > > > +Virtqueue coalescing parameters:
> > > > > +\begin{itemize}
> > > > > +\item \field{vqn}: The virtqueue number of the enabled transmit or
> > > > > receive virtqueue, excluding the control virtqueue.
> > > > > +\item \field{max_packets}: The maximum number of packets
> > > > > sent/received by the specified virtqueue before a TX/RX notification.
> > > > > +\item \field{max_usecs}: The maximum number of TX/RX usecs that the
> > > > > specified virtqueue delays a TX/RX notification.
> > > > > +\end{itemize}
> > > > > +
> > > > > +\field{reserved} is reserved and it is ignored by the device.
> > > > > +
> > > >
> > > > max_packets is the same with VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET and with
> > > > VIRTIO_NET_CTRL_NOTF_COAL_[T/R]X_SET.
> > > > ("Maximum number of packets to receive/send before a RX/TX
> > > > notification").
> > > > The fact that this is applied to all VQs or to a specific one is
> > > > derived from the command.
> > > > Same for max_usecs.
> > > > Maybe we can join the coalescing parameters somehow instead of
> > > > repeating the explanations?
> > > >
> >
> > Any thoughts on this part?
>
> Good idea, and if so, is there a good way to expose vqn to the interpretation
> of max_packets ?
not sure what you are asking here.
>
> #1
> \item \field{vqn}: The virtqueue number of the enabled transmit or receive
> virtqueue.
an enabled - 1st time you mention a virtqueue.
> \item \field{max_packets}: The maximum number of packets sent/received by the
> specified virtqueue before a TX/RX notification.
>
> #2
> \item \field{max_packets}: Maximum number of packets to receive/send before a
> RX/TX notification.
>
> Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
