DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xia, Chenbo" <chenbo.xia@intel.com>
To: "Liu, Changpeng" <changpeng.liu@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: RE: [PATCH] vhost: use try_lock in rte_vhost_vring_call
Date: Tue, 20 Sep 2022 02:53:55 +0000	[thread overview]
Message-ID: <SN6PR11MB3504DEF441C81F2B16A913829C4C9@SN6PR11MB3504.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR11MB5093F56566072A01624D8C88EE4C9@PH0PR11MB5093.namprd11.prod.outlook.com>

> -----Original Message-----
> From: Liu, Changpeng <changpeng.liu@intel.com>
> Sent: Tuesday, September 20, 2022 10:34 AM
> To: Xia, Chenbo <chenbo.xia@intel.com>; dev@dpdk.org
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Subject: RE: [PATCH] vhost: use try_lock in rte_vhost_vring_call
> 
> Hi Bo,
> 
> > -----Original Message-----
> > From: Xia, Chenbo <chenbo.xia@intel.com>
> > Sent: Tuesday, September 20, 2022 10:25 AM
> > To: Liu, Changpeng <changpeng.liu@intel.com>; dev@dpdk.org
> > Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> > Subject: RE: [PATCH] vhost: use try_lock in rte_vhost_vring_call
> >
> > Hi Changpeng,
> >
> > > -----Original Message-----
> > > From: Liu, Changpeng <changpeng.liu@intel.com>
> > > Sent: Tuesday, September 6, 2022 10:22 AM
> > > To: dev@dpdk.org
> > > Cc: Liu, Changpeng <changpeng.liu@intel.com>; Maxime Coquelin
> > > <maxime.coquelin@redhat.com>; Xia, Chenbo <chenbo.xia@intel.com>
> > > Subject: [PATCH] vhost: use try_lock in rte_vhost_vring_call
> > >
> > > Note that this function is in data path, so the thread context
> > > may not same as socket messages processing context, by using
> > > try_lock here, users can have another try in case of VQ's access
> > > lock is held by `vhost-events` thread.
> >
> > Better to describe the issue this patch wants to fix and how does
> > it fix.
> >
> > I remember it's a bz issue, do you want to backport? And it has
> > some bz ID, we need to add it in commit message.
> Actually it's my intention not to add bz ID, as I think for this bz ID,
> It's better not to lock all VQ's access lock for KICK/CALLFD messages,

Do you plan to add this change? I think that may be an improvement to current
locking implementation.

Maxime, what do you think of this idea about only locking specific queue when
handling vring related message (not global config like mem table)?

> What do you think? If this is identified as a fix, I can backport it to
> 22.05.

You can decide, if this is planned to be the fix, just backport. I am just
thinking if this is not the fix for the bz, do we still need this?

Thanks,
Chenbo

> >
> > >
> > > Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
> > > ---
> > >  lib/vhost/vhost.c | 6 +++++-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
> > > index 60cb05a0ff..072d2acb7b 100644
> > > --- a/lib/vhost/vhost.c
> > > +++ b/lib/vhost/vhost.c
> > > @@ -1329,7 +1329,11 @@ rte_vhost_vring_call(int vid, uint16_t
> vring_idx)
> > >  	if (!vq)
> > >  		return -1;
> > >
> > > -	rte_spinlock_lock(&vq->access_lock);
> > > +	if (!rte_spinlock_trylock(&vq->access_lock)) {
> > > +		VHOST_LOG_CONFIG(dev->ifname, DEBUG,
> >
> > Should use VHOST_LOG_DATA
> OK.
> >
> > Thanks,
> > Chenbo
> >
> > > +			"failed to kick guest, virtqueue busy.\n");
> > > +		return -1;
> > > +	}
> > >
> > >  	if (vq_is_packed(dev))
> > >  		vhost_vring_call_packed(dev, vq);
> > > --
> > > 2.21.3


  reply	other threads:[~2022-09-20  2:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06  2:22 Changpeng Liu
2022-09-06 21:15 ` Stephen Hemminger
2022-09-07  0:40   ` Liu, Changpeng
2022-09-20  7:12     ` Maxime Coquelin
2022-09-20  2:24 ` Xia, Chenbo
2022-09-20  2:34   ` Liu, Changpeng
2022-09-20  2:53     ` Xia, Chenbo [this message]
2022-09-20  3:00       ` Liu, Changpeng
2022-09-20  7:23       ` Maxime Coquelin
2022-09-20  7:30         ` Maxime Coquelin
2022-09-20  7:19 ` Maxime Coquelin
2022-09-20  7:29   ` Liu, Changpeng
2022-09-20  7:34     ` Maxime Coquelin
2022-09-20  7:45       ` Liu, Changpeng
2022-09-20  8:12         ` Maxime Coquelin
2022-09-20  8:43           ` Liu, Changpeng
2022-09-21  9:41             ` Maxime Coquelin
2022-09-21  9:52               ` Liu, Changpeng
2022-10-11 11:56                 ` Maxime Coquelin
2022-10-12  6:40 ` [PATCH v2] vhost: add new `rte_vhost_vring_call_nonblock` API Changpeng Liu
2022-10-13  7:56   ` Maxime Coquelin
2022-10-17  6:46   ` Xia, Chenbo
2022-10-17  7:17     ` Liu, Changpeng
2022-10-17  7:14   ` [PATCH v3] " Changpeng Liu
2022-10-17  7:39     ` Xia, Chenbo
2022-10-17  7:50       ` Liu, Changpeng
2022-10-17  7:48     ` [PATCH v4] " Changpeng Liu
2022-10-19  5:27       ` Xia, Chenbo
2022-10-26  9:24       ` Xia, Chenbo

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=SN6PR11MB3504DEF441C81F2B16A913829C4C9@SN6PR11MB3504.namprd11.prod.outlook.com \
    --to=chenbo.xia@intel.com \
    --cc=changpeng.liu@intel.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.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 NNTP newsgroup(s).