From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0A7A0A00C3; Tue, 20 Sep 2022 09:30:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F260540DFB; Tue, 20 Sep 2022 09:30:29 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id A42EE4069B for ; Tue, 20 Sep 2022 09:30:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663659028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LnIHSB+LUCff42ZixDVu0Agk+rHHA+w84zckiDXuuxU=; b=CZe5eQzwxWPwdbyXnwcNPX974hXzwNWLt3DvRg29Ia8rCKGSYacF5Ug8meWmLw3WvMHNqN zncc/PfmukZ4QQLexZ6lxlHoyHOgrtuVFV+Ek0EGia5ly3W23sABgdXo9HPxXvjnBH5DBQ iTTmQq/Usdqrg5lBQ5ry6fj0Omxe7FE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-227-b6PEFHG3Or6fi_UE8D7f_w-1; Tue, 20 Sep 2022 03:30:25 -0400 X-MC-Unique: b6PEFHG3Or6fi_UE8D7f_w-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0654101E148; Tue, 20 Sep 2022 07:30:24 +0000 (UTC) Received: from [10.39.208.16] (unknown [10.39.208.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7E11D40C6EC2; Tue, 20 Sep 2022 07:30:23 +0000 (UTC) Message-ID: <7c3269f3-8c7e-d0b1-59d3-65ca297c898d@redhat.com> Date: Tue, 20 Sep 2022 09:30:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH] vhost: use try_lock in rte_vhost_vring_call From: Maxime Coquelin To: "Xia, Chenbo" , "Liu, Changpeng" , "dev@dpdk.org" References: <20220906022225.17215-1-changpeng.liu@intel.com> In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 9/20/22 09:23, Maxime Coquelin wrote: > > > On 9/20/22 04:53, Xia, Chenbo wrote: >>> -----Original Message----- >>> From: Liu, Changpeng >>> Sent: Tuesday, September 20, 2022 10:34 AM >>> To: Xia, Chenbo ; dev@dpdk.org >>> Cc: Maxime Coquelin >>> Subject: RE: [PATCH] vhost: use try_lock in rte_vhost_vring_call >>> >>> Hi Bo, >>> >>>> -----Original Message----- >>>> From: Xia, Chenbo >>>> Sent: Tuesday, September 20, 2022 10:25 AM >>>> To: Liu, Changpeng ; dev@dpdk.org >>>> Cc: Maxime Coquelin >>>> Subject: RE: [PATCH] vhost: use try_lock in rte_vhost_vring_call >>>> >>>> Hi Changpeng, >>>> >>>>> -----Original Message----- >>>>> From: Liu, Changpeng >>>>> Sent: Tuesday, September 6, 2022 10:22 AM >>>>> To: dev@dpdk.org >>>>> Cc: Liu, Changpeng ; Maxime Coquelin >>>>> ; Xia, Chenbo >>>>> 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)? > > I think this is not a good idea. > For example SET_VRING_KICK can currently call > translate_ring_addresses(), which itself can call numa_realloc(). > > numa_realloc() may reallocate the dev, so you don't want it to be used > by other queues while it happens. Hmm, actually that may be possible because numa_realloc() reallocs the dev only if it is not running. So maybe you can propose something, but you will have to test it carefully with use-cases involving NUMA reallocation. >>> 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 >>>>> --- >>>>>   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 >>