From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: xuanzhuo@linux.alibaba.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, eperezma@redhat.com,
edumazet@google.com, maxime.coquelin@redhat.com, kuba@kernel.org,
pabeni@redhat.com, david.marchand@redhat.com,
davem@davemloft.net
Subject: Re: [PATCH net-next V2 2/2] virtio-net: sleep instead of busy waiting for cvq command
Date: Tue, 16 May 2023 16:54:38 -0400 [thread overview]
Message-ID: <20230516165043-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230413064027.13267-3-jasowang@redhat.com>
On Thu, Apr 13, 2023 at 02:40:27PM +0800, Jason Wang wrote:
> We used to busy waiting on the cvq command this tends to be
> problematic since there no way for to schedule another process which
> may serve for the control virtqueue. This might be the case when the
> control virtqueue is emulated by software. This patch switches to use
> completion to allow the CPU to sleep instead of busy waiting for the
> cvq command.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Changes since V1:
> - use completion for simplicity
> - don't try to harden the CVQ command which requires more thought
> Changes since RFC:
> - break the device when timeout
> - get buffer manually since the virtio core check more_used() instead
> ---
> drivers/net/virtio_net.c | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 2e56bbf86894..d3eb8fd6c9dc 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -19,6 +19,7 @@
> #include <linux/average.h>
> #include <linux/filter.h>
> #include <linux/kernel.h>
> +#include <linux/completion.h>
> #include <net/route.h>
> #include <net/xdp.h>
> #include <net/net_failover.h>
> @@ -295,6 +296,8 @@ struct virtnet_info {
>
> /* failover when STANDBY feature enabled */
> struct failover *failover;
> +
> + struct completion completion;
> };
>
> struct padded_vnet_hdr {
> @@ -1709,6 +1712,13 @@ static bool try_fill_recv(struct virtnet_info *vi, struct receive_queue *rq,
> return !oom;
> }
>
> +static void virtnet_cvq_done(struct virtqueue *cvq)
> +{
> + struct virtnet_info *vi = cvq->vdev->priv;
> +
> + complete(&vi->completion);
> +}
> +
> static void skb_recv_done(struct virtqueue *rvq)
> {
> struct virtnet_info *vi = rvq->vdev->priv;
> @@ -2169,12 +2179,8 @@ static bool virtnet_send_command(struct virtnet_info *vi, u8 class, u8 cmd,
> if (unlikely(!virtqueue_kick(vi->cvq)))
> return vi->ctrl->status == VIRTIO_NET_OK;
>
> - /* Spin for a response, the kick causes an ioport write, trapping
> - * into the hypervisor, so the request should be handled immediately.
> - */
> - while (!virtqueue_get_buf(vi->cvq, &tmp) &&
> - !virtqueue_is_broken(vi->cvq))
> - cpu_relax();
> + wait_for_completion(&vi->completion);
> + virtqueue_get_buf(vi->cvq, &tmp);
>
> return vi->ctrl->status == VIRTIO_NET_OK;
This seems to break surprise removal and other
situations where vq gets broken since callbacks
aren't usually invoked then.
> }
> @@ -3672,7 +3678,7 @@ static int virtnet_find_vqs(struct virtnet_info *vi)
>
> /* Parameters for control virtqueue, if any */
> if (vi->has_cvq) {
> - callbacks[total_vqs - 1] = NULL;
> + callbacks[total_vqs - 1] = virtnet_cvq_done;
> names[total_vqs - 1] = "control";
> }
>
There is a cost to this, in that we are burning an extra MSI vector
for the slow path cvq. if device has 3 vectors, suddenly we can't
allocate vectors for rx and tx, big problem.
So I'm afraid we need to pass a new flag that will share
the config changed interrupt and cvq.
> @@ -4122,6 +4128,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (vi->has_rss || vi->has_rss_hash_report)
> virtnet_init_default_rss(vi);
>
> + init_completion(&vi->completion);
> enable_rx_mode_work(vi);
>
> /* serialize netdev register + virtio_device_ready() with ndo_open() */
> --
> 2.25.1
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, maxime.coquelin@redhat.com,
alvaro.karsz@solid-run.com, eperezma@redhat.com,
xuanzhuo@linux.alibaba.com, david.marchand@redhat.com
Subject: Re: [PATCH net-next V2 2/2] virtio-net: sleep instead of busy waiting for cvq command
Date: Tue, 16 May 2023 16:54:38 -0400 [thread overview]
Message-ID: <20230516165043-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230413064027.13267-3-jasowang@redhat.com>
On Thu, Apr 13, 2023 at 02:40:27PM +0800, Jason Wang wrote:
> We used to busy waiting on the cvq command this tends to be
> problematic since there no way for to schedule another process which
> may serve for the control virtqueue. This might be the case when the
> control virtqueue is emulated by software. This patch switches to use
> completion to allow the CPU to sleep instead of busy waiting for the
> cvq command.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Changes since V1:
> - use completion for simplicity
> - don't try to harden the CVQ command which requires more thought
> Changes since RFC:
> - break the device when timeout
> - get buffer manually since the virtio core check more_used() instead
> ---
> drivers/net/virtio_net.c | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 2e56bbf86894..d3eb8fd6c9dc 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -19,6 +19,7 @@
> #include <linux/average.h>
> #include <linux/filter.h>
> #include <linux/kernel.h>
> +#include <linux/completion.h>
> #include <net/route.h>
> #include <net/xdp.h>
> #include <net/net_failover.h>
> @@ -295,6 +296,8 @@ struct virtnet_info {
>
> /* failover when STANDBY feature enabled */
> struct failover *failover;
> +
> + struct completion completion;
> };
>
> struct padded_vnet_hdr {
> @@ -1709,6 +1712,13 @@ static bool try_fill_recv(struct virtnet_info *vi, struct receive_queue *rq,
> return !oom;
> }
>
> +static void virtnet_cvq_done(struct virtqueue *cvq)
> +{
> + struct virtnet_info *vi = cvq->vdev->priv;
> +
> + complete(&vi->completion);
> +}
> +
> static void skb_recv_done(struct virtqueue *rvq)
> {
> struct virtnet_info *vi = rvq->vdev->priv;
> @@ -2169,12 +2179,8 @@ static bool virtnet_send_command(struct virtnet_info *vi, u8 class, u8 cmd,
> if (unlikely(!virtqueue_kick(vi->cvq)))
> return vi->ctrl->status == VIRTIO_NET_OK;
>
> - /* Spin for a response, the kick causes an ioport write, trapping
> - * into the hypervisor, so the request should be handled immediately.
> - */
> - while (!virtqueue_get_buf(vi->cvq, &tmp) &&
> - !virtqueue_is_broken(vi->cvq))
> - cpu_relax();
> + wait_for_completion(&vi->completion);
> + virtqueue_get_buf(vi->cvq, &tmp);
>
> return vi->ctrl->status == VIRTIO_NET_OK;
This seems to break surprise removal and other
situations where vq gets broken since callbacks
aren't usually invoked then.
> }
> @@ -3672,7 +3678,7 @@ static int virtnet_find_vqs(struct virtnet_info *vi)
>
> /* Parameters for control virtqueue, if any */
> if (vi->has_cvq) {
> - callbacks[total_vqs - 1] = NULL;
> + callbacks[total_vqs - 1] = virtnet_cvq_done;
> names[total_vqs - 1] = "control";
> }
>
There is a cost to this, in that we are burning an extra MSI vector
for the slow path cvq. if device has 3 vectors, suddenly we can't
allocate vectors for rx and tx, big problem.
So I'm afraid we need to pass a new flag that will share
the config changed interrupt and cvq.
> @@ -4122,6 +4128,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (vi->has_rss || vi->has_rss_hash_report)
> virtnet_init_default_rss(vi);
>
> + init_completion(&vi->completion);
> enable_rx_mode_work(vi);
>
> /* serialize netdev register + virtio_device_ready() with ndo_open() */
> --
> 2.25.1
next prev parent reply other threads:[~2023-05-16 20:54 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 6:40 [PATCH net-next V2 0/2] virtio-net: don't busy poll for cvq command Jason Wang
2023-04-13 6:40 ` Jason Wang
2023-04-13 6:40 ` [PATCH net-next V2 1/2] virtio-net: convert rx mode setting to use workqueue Jason Wang
2023-04-13 6:40 ` Jason Wang
2023-04-13 16:25 ` Michael S. Tsirkin
2023-04-13 16:25 ` Michael S. Tsirkin
2023-04-14 5:04 ` Jason Wang
2023-04-14 5:04 ` Jason Wang
2023-04-14 7:21 ` Michael S. Tsirkin
2023-04-14 7:21 ` Michael S. Tsirkin
2023-04-17 3:40 ` Jason Wang
2023-04-17 3:40 ` Jason Wang
2023-05-05 3:46 ` Jason Wang
2023-05-05 3:46 ` Jason Wang
2023-05-10 5:32 ` Michael S. Tsirkin
2023-05-10 5:32 ` Michael S. Tsirkin
2023-05-15 1:05 ` Jason Wang
2023-05-15 1:05 ` Jason Wang
2023-05-15 4:45 ` Michael S. Tsirkin
2023-05-15 4:45 ` Michael S. Tsirkin
2023-05-15 5:13 ` Jason Wang
2023-05-15 5:13 ` Jason Wang
2023-05-15 10:17 ` Michael S. Tsirkin
2023-05-15 10:17 ` Michael S. Tsirkin
2023-05-16 2:44 ` Jason Wang
2023-05-16 2:44 ` Jason Wang
2023-05-16 4:12 ` Michael S. Tsirkin
2023-05-16 4:12 ` Michael S. Tsirkin
2023-05-16 4:17 ` Jason Wang
2023-05-16 4:17 ` Jason Wang
2023-05-16 5:56 ` Michael S. Tsirkin
2023-05-16 5:56 ` Michael S. Tsirkin
2023-05-16 19:36 ` Jakub Kicinski
2023-04-13 6:40 ` [PATCH net-next V2 2/2] virtio-net: sleep instead of busy waiting for cvq command Jason Wang
2023-04-13 6:40 ` Jason Wang
2023-04-13 7:27 ` Xuan Zhuo
2023-04-13 7:27 ` Xuan Zhuo
2023-04-14 5:09 ` Jason Wang
2023-04-14 5:09 ` Jason Wang
2023-04-14 5:10 ` Jason Wang
2023-04-14 5:10 ` Jason Wang
2023-05-16 20:54 ` Michael S. Tsirkin [this message]
2023-05-16 20:54 ` Michael S. Tsirkin
2023-05-17 0:50 ` Jason Wang
2023-05-17 0:50 ` Jason Wang
2023-04-13 13:02 ` [PATCH net-next V2 0/2] virtio-net: don't busy poll " Maxime Coquelin
2023-04-13 13:02 ` Maxime Coquelin
2023-04-13 13:05 ` Maxime Coquelin
2023-04-13 13:05 ` Maxime Coquelin
2023-04-13 14:04 ` Jakub Kicinski
2023-04-14 4:53 ` Jason Wang
2023-04-14 4:53 ` Jason Wang
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=20230516165043-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=david.marchand@redhat.com \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.coquelin@redhat.com \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux-foundation.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.