From: Jason Wang <jasowang@redhat.com>
To: Heng Qi <hengqi@linux.alibaba.com>
Cc: Parav Pandit <parav@nvidia.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Xuan Zhuo <xuanzhuo@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>
Subject: Re: [virtio-comment] RE: [virtio-dev] RE: [virtio-comment] RE: [virtio-dev] RE: [virtio-comment] [PATCH v2] virtio-net: support setting coalescing params for multiple vqs
Date: Thu, 25 Jan 2024 11:51:51 +0800 [thread overview]
Message-ID: <CACGkMEt51UjK_xMjODcqjEzwDFGMcBDE+sf-omdJ=OA+De=rbQ@mail.gmail.com> (raw)
In-Reply-To: <52cef8e6-f878-4927-ab77-f3b71d3df85d@linux.alibaba.com>
On Thu, Jan 25, 2024 at 11:05 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2024/1/24 下午9:18, Parav Pandit 写道:
> >> From: Heng Qi <hengqi@linux.alibaba.com>
> >> Sent: Wednesday, January 24, 2024 6:31 PM
> >>
> >>
> >> 在 2024/1/22 下午1:03, Parav Pandit 写道:
> >>>> From: Heng Qi <hengqi@linux.alibaba.com>
> >>>> Sent: Monday, January 22, 2024 8:27 AM
> >>>>
> >>>> 在 2024/1/20 下午5:59, Parav Pandit 写道:
> >>>>>> From: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>> Sent: Wednesday, January 17, 2024 10:22 AM
> >>>>>>
> >>>>>> 在 2024/1/15 下午9:21, Parav Pandit 写道:
> >>>>>>>> From: virtio-comment@lists.oasis-open.org
> >>>>>>>> <virtio-comment@lists.oasis- open.org> On Behalf Of Heng Qi
> >>>>>>>> Sent: Monday, January 15, 2024 6:36 PM
> >>>>>>>>
> >>>>>>>> Currently, when each time the driver attempts to update the
> >>>>>>>> coalescing parameters for a vq, it needs to kick the device and
> >>>>>>>> wait for the ctrlq response to return.
> >>>>>>> It does not need to wait. This is some driver limitation that does
> >>>>>>> not use
> >>>>>> the queue as "queue".
> >>>>>>> Such driver limitation should be removed in the driver. It does
> >>>>>>> not qualify
> >>>>>> as limitation.
> >>>>>>
> >>>>>> Yes, we don't have to wait.
> >>>>>>
> >>>>>> But in general, for user commands, it is necessary to obtain the
> >>>>>> final results synchronously.
> >>>>> Yes. Use initiated command can enqueue the request to cvq. Go to
> >>>>> sleep
> >>>> for several micro to milliseconds.
> >>>>>> The user command cannot return before the final result is obtained.
> >>>>>> And wait is not the problem this patch solves.
> >>>>>>
> >>>>> By not holding the rtnl lock, rest of the context that needs to
> >>>>> enqueue the
> >>>> request can progress such as that of netdim.
> >>>>
> >>>> Would like to see the using of rtnl lock changed.
> >>>>
> >>> Inside the virtnet_rx_dim_work() there should be rtnl lock call.
> >>> A virtio_device level lock to be used for cvq. :)
> >>>
> >>>> In addition, I have made batching and asynchronousization of the
> >>>> netdim command, you can refer to this patch:
> >>>> https://lore.kernel.org/all/1705410693-118895-4-git-send-email-
> >>>> hengqi@linux.alibaba.com/
> >>>>
> >>> In the listed above driver patch the motivation "to optimize the CPU
> >>> overhead of the DIM worker caused by the guest being busy waiting for
> >>> the command response result."
> >>>
> >>> Is not right.
> >>> Because guest is still busy waiting.
> >> There is no busy wait for guests, see get_cvq_work().
> >>
> > Ok. not always busy waiting, sometimes it does.
>
> Busy waiting will only occur when the user command or dim command cannot
> find the available buffer for cvq.
>
> The user command is still in polling mode for now, I have not tried to
> optimize this. Now it's about improving dim performance.
>
> > virtnet_cvq_response() should not have flag..
>
> The flag is mainly used to identify whether it is a user command. If so,
> the previous polling mode will still be maintained.
>
> >
> > Who ever gets the OS global rtnl lock is calling virtnet_cvq_response() and checking and releasing.
> > Shouldn’t be done this way with try lock etc.
> > Rtnl lock is not supposed to protect low level driver some ctrlvq response flag.
>
> To summarize, we now want to make some improvements to cvq:
> 1. Reasonable timeout in busy waiting mode or interrupt-based etc.
Let's use interrupt to avoid tricky code.
> 2. Batch processing (the core problem is how to get results from user
> commands synchronously)
> 3. Remove rtnl_lock’s protection for ctrlq.
Virtio-comment is not the right place to discuss these. Let's move it to netdev.
Thanks
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/
next prev parent reply other threads:[~2024-01-25 3:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 13:06 [virtio-comment] [PATCH v2] virtio-net: support setting coalescing params for multiple vqs Heng Qi
2024-01-15 13:21 ` Parav Pandit
2024-01-17 4:52 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-01-20 9:59 ` [virtio-comment] " Parav Pandit
2024-01-22 2:57 ` Heng Qi
2024-01-22 5:03 ` Parav Pandit
2024-01-22 7:36 ` Michael S. Tsirkin
2024-01-23 5:55 ` Parav Pandit
2024-01-23 7:15 ` Michael S. Tsirkin
2024-01-23 7:28 ` Parav Pandit
2024-01-24 2:43 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-01-24 13:01 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-01-24 13:18 ` [virtio-comment] " Parav Pandit
2024-01-25 3:05 ` Heng Qi
2024-01-25 3:51 ` Jason Wang [this message]
2024-01-15 22:58 ` [virtio-comment] " Michael S. Tsirkin
2024-01-17 8:53 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-01-24 10:50 ` [virtio-comment] " Michael S. Tsirkin
2024-01-24 10:52 ` Michael S. Tsirkin
2024-01-25 2:33 ` 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='CACGkMEt51UjK_xMjODcqjEzwDFGMcBDE+sf-omdJ=OA+De=rbQ@mail.gmail.com' \
--to=jasowang@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=mst@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).