All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Dragos Tatulea <dtatulea@nvidia.com>
Cc: "eperezma@redhat.com" <eperezma@redhat.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"xuanzhuo@linux.alibaba.com" <xuanzhuo@linux.alibaba.com>,
	"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
	Tariq Toukan <tariqt@nvidia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Cosmin Ratiu <cratiu@nvidia.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"si-wei.liu@oracle.com" <si-wei.liu@oracle.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	"leon@kernel.org" <leon@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH vhost 20/23] vdpa/mlx5: Pre-create hardware VQs at vdpa .dev_add time
Date: Mon, 8 Jul 2024 07:11:44 -0400	[thread overview]
Message-ID: <20240708071005-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <c6dc541919a0cc78521364dbf4db32293cf1071e.camel@nvidia.com>

On Mon, Jul 08, 2024 at 11:01:39AM +0000, Dragos Tatulea wrote:
> On Wed, 2024-07-03 at 18:01 +0200, Eugenio Perez Martin wrote:
> > On Wed, Jun 26, 2024 at 11:27 AM Dragos Tatulea <dtatulea@nvidia.com> wrote:
> > > 
> > > On Wed, 2024-06-19 at 17:54 +0200, Eugenio Perez Martin wrote:
> > > > On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea <dtatulea@nvidia.com> wrote:
> > > > > 
> > > > > Currently, hardware VQs are created right when the vdpa device gets into
> > > > > DRIVER_OK state. That is easier because most of the VQ state is known by
> > > > > then.
> > > > > 
> > > > > This patch switches to creating all VQs and their associated resources
> > > > > at device creation time. The motivation is to reduce the vdpa device
> > > > > live migration downtime by moving the expensive operation of creating
> > > > > all the hardware VQs and their associated resources out of downtime on
> > > > > the destination VM.
> > > > > 
> > > > > The VQs are now created in a blank state. The VQ configuration will
> > > > > happen later, on DRIVER_OK. Then the configuration will be applied when
> > > > > the VQs are moved to the Ready state.
> > > > > 
> > > > > When .set_vq_ready() is called on a VQ before DRIVER_OK, special care is
> > > > > needed: now that the VQ is already created a resume_vq() will be
> > > > > triggered too early when no mr has been configured yet. Skip calling
> > > > > resume_vq() in this case, let it be handled during DRIVER_OK.
> > > > > 
> > > > > For virtio-vdpa, the device configuration is done earlier during
> > > > > .vdpa_dev_add() by vdpa_register_device(). Avoid calling
> > > > > setup_vq_resources() a second time in that case.
> > > > > 
> > > > 
> > > > I guess this happens if virtio_vdpa is already loaded, but I cannot
> > > > see how this is different here. Apart from the IOTLB, what else does
> > > > it change from the mlx5_vdpa POV?
> > > > 
> > > I don't understand your question, could you rephrase or provide more context
> > > please?
> > > 
> > 
> > My main point is that the vdpa parent driver should not be able to
> > tell the difference between vhost_vdpa and virtio_vdpa. The only
> > difference I can think of is because of the vhost IOTLB handling.
> > 
> > Do you also observe this behavior if you add the device with "vdpa
> > add" without the virtio_vdpa module loaded, and then modprobe
> > virtio_vdpa?
> > 
> Aah, now I understand what you mean. Indeed in my tests I was loading the
> virtio_vdpa module before adding the device. When doing it the other way around
> the device doesn't get configured during probe.
>  
> 
> > At least the comment should be something in the line of "If we have
> > all the information to initialize the device, pre-warm it here" or
> > similar.
> Makes sense. I will send a v3 with the commit + comment message update.


Is commit update the only change then?

> > 
> > > Thanks,
> > > Dragos
> > > 
> > > > > Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> > > > > Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
> > > > > ---
> > > > >  drivers/vdpa/mlx5/net/mlx5_vnet.c | 37 ++++++++++++++++++++++++++++++++-----
> > > > >  1 file changed, 32 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > index 249b5afbe34a..b2836fd3d1dd 100644
> > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > @@ -2444,7 +2444,7 @@ static void mlx5_vdpa_set_vq_ready(struct vdpa_device *vdev, u16 idx, bool ready
> > > > >         mvq = &ndev->vqs[idx];
> > > > >         if (!ready) {
> > > > >                 suspend_vq(ndev, mvq);
> > > > > -       } else {
> > > > > +       } else if (mvdev->status & VIRTIO_CONFIG_S_DRIVER_OK) {
> > > > >                 if (resume_vq(ndev, mvq))
> > > > >                         ready = false;
> > > > >         }
> > > > > @@ -3078,10 +3078,18 @@ static void mlx5_vdpa_set_status(struct vdpa_device *vdev, u8 status)
> > > > >                                 goto err_setup;
> > > > >                         }
> > > > >                         register_link_notifier(ndev);
> > > > > -                       err = setup_vq_resources(ndev, true);
> > > > > -                       if (err) {
> > > > > -                               mlx5_vdpa_warn(mvdev, "failed to setup driver\n");
> > > > > -                               goto err_driver;
> > > > > +                       if (ndev->setup) {
> > > > > +                               err = resume_vqs(ndev);
> > > > > +                               if (err) {
> > > > > +                                       mlx5_vdpa_warn(mvdev, "failed to resume VQs\n");
> > > > > +                                       goto err_driver;
> > > > > +                               }
> > > > > +                       } else {
> > > > > +                               err = setup_vq_resources(ndev, true);
> > > > > +                               if (err) {
> > > > > +                                       mlx5_vdpa_warn(mvdev, "failed to setup driver\n");
> > > > > +                                       goto err_driver;
> > > > > +                               }
> > > > >                         }
> > > > >                 } else {
> > > > >                         mlx5_vdpa_warn(mvdev, "did not expect DRIVER_OK to be cleared\n");
> > > > > @@ -3142,6 +3150,7 @@ static int mlx5_vdpa_compat_reset(struct vdpa_device *vdev, u32 flags)
> > > > >                 if (mlx5_vdpa_create_dma_mr(mvdev))
> > > > >                         mlx5_vdpa_warn(mvdev, "create MR failed\n");
> > > > >         }
> > > > > +       setup_vq_resources(ndev, false);
> > > > >         up_write(&ndev->reslock);
> > > > > 
> > > > >         return 0;
> > > > > @@ -3836,8 +3845,21 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name,
> > > > >                 goto err_reg;
> > > > > 
> > > > >         mgtdev->ndev = ndev;
> > > > > +
> > > > > +       /* For virtio-vdpa, the device was set up during device register. */
> > > > > +       if (ndev->setup)
> > > > > +               return 0;
> > > > > +
> > > > > +       down_write(&ndev->reslock);
> > > > > +       err = setup_vq_resources(ndev, false);
> > > > > +       up_write(&ndev->reslock);
> > > > > +       if (err)
> > > > > +               goto err_setup_vq_res;
> > > > > +
> > > > >         return 0;
> > > > > 
> > > > > +err_setup_vq_res:
> > > > > +       _vdpa_unregister_device(&mvdev->vdev);
> > > > >  err_reg:
> > > > >         destroy_workqueue(mvdev->wq);
> > > > >  err_res2:
> > > > > @@ -3863,6 +3885,11 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > > > 
> > > > >         unregister_link_notifier(ndev);
> > > > >         _vdpa_unregister_device(dev);
> > > > > +
> > > > > +       down_write(&ndev->reslock);
> > > > > +       teardown_vq_resources(ndev);
> > > > > +       up_write(&ndev->reslock);
> > > > > +
> > > > >         wq = mvdev->wq;
> > > > >         mvdev->wq = NULL;
> > > > >         destroy_workqueue(wq);
> > > > > 
> > > > > --
> > > > > 2.45.1
> > > > > 
> > > > 
> > > 
> > 
> 


  reply	other threads:[~2024-07-08 11:12 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-17 15:07 [PATCH vhost 00/23] vdpa/mlx5: Pre-create HW VQs to reduce LM downtime Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 01/23] vdpa/mlx5: Clarify meaning thorough function rename Dragos Tatulea
2024-06-19 10:37   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 02/23] vdpa/mlx5: Make setup/teardown_vq_resources() symmetrical Dragos Tatulea
2024-06-19 10:38   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 03/23] vdpa/mlx5: Drop redundant code Dragos Tatulea
2024-06-19 10:55   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 04/23] vdpa/mlx5: Drop redundant check in teardown_virtqueues() Dragos Tatulea
2024-06-19 10:56   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 05/23] vdpa/mlx5: Iterate over active VQs during suspend/resume Dragos Tatulea
2024-06-19 11:04   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 06/23] vdpa/mlx5: Remove duplicate suspend code Dragos Tatulea
2024-06-19 11:02   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 07/23] vdpa/mlx5: Initialize and reset device with one queue pair Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 08/23] vdpa/mlx5: Clear and reinitialize software VQ data on reset Dragos Tatulea
2024-06-19 11:28   ` Eugenio Perez Martin
2024-06-19 17:03     ` Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 09/23] vdpa/mlx5: Add support for modifying the virtio_version VQ field Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 10/23] vdpa/mlx5: Add support for modifying the VQ features field Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 11/23] vdpa/mlx5: Set an initial size on the VQ Dragos Tatulea
2024-06-19 15:08   ` Eugenio Perez Martin
2024-06-19 17:06     ` Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 12/23] vdpa/mlx5: Start off rqt_size with max VQPs Dragos Tatulea
2024-06-19 15:33   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 13/23] vdpa/mlx5: Set mkey modified flags on all VQs Dragos Tatulea
2024-06-19 15:33   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 14/23] vdpa/mlx5: Allow creation of blank VQs Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 15/23] vdpa/mlx5: Accept Init -> Ready VQ transition in resume_vq() Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 16/23] vdpa/mlx5: Add error code for suspend/resume VQ Dragos Tatulea
2024-06-19 15:41   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 17/23] vdpa/mlx5: Consolidate all VQ modify to Ready to use resume_vq() Dragos Tatulea
2024-06-19 15:43   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 18/23] vdpa/mlx5: Forward error in suspend/resume device Dragos Tatulea
2024-06-23 11:19   ` Zhu Yanjun
2024-06-26  9:28     ` Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 19/23] vdpa/mlx5: Use suspend/resume during VQP change Dragos Tatulea
2024-06-19 15:46   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 20/23] vdpa/mlx5: Pre-create hardware VQs at vdpa .dev_add time Dragos Tatulea
2024-06-19 15:54   ` Eugenio Perez Martin
2024-06-26  9:27     ` Dragos Tatulea
2024-07-03 16:01       ` Eugenio Perez Martin
2024-07-08 11:01         ` Dragos Tatulea
2024-07-08 11:11           ` Michael S. Tsirkin [this message]
2024-07-08 11:17             ` Dragos Tatulea
2024-07-08 11:25               ` Michael S. Tsirkin
2024-07-08 16:22   ` Zhu Yanjun
2024-07-08 16:43     ` Dragos Tatulea
2024-06-17 15:07 ` [PATCH vhost 21/23] vdpa/mlx5: Re-create HW VQs under certain conditions Dragos Tatulea
2024-06-19 16:04   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 22/23] vdpa/mlx5: Don't reset VQs more than necessary Dragos Tatulea
2024-06-19 16:14   ` Eugenio Perez Martin
2024-06-17 15:07 ` [PATCH vhost 23/23] vdpa/mlx5: Don't enable non-active VQs in .set_vq_ready() Dragos Tatulea
2024-06-19 16:39   ` Eugenio Perez Martin

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=20240708071005-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cratiu@nvidia.com \
    --cc=dtatulea@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@nvidia.com \
    --cc=si-wei.liu@oracle.com \
    --cc=tariqt@nvidia.com \
    --cc=virtualization@lists.linux.dev \
    --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.