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 8C70BA0093; Thu, 21 Apr 2022 17:25:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4E49940042; Thu, 21 Apr 2022 17:25:20 +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 9844340040 for ; Thu, 21 Apr 2022 17:25:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650554718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UP6GsfKNQr+tnGT8lU642uL2oIy0ptLJJDgHYuPHG0U=; b=I0RUB98UFh5yUX9Ly4ifGLGWZn+SSllLZ2lb9M6yn2cSxebXDZ8s4kQir9wg/4H9bAkzwW xKutE0WUj+2rIQ6f3K3dHd/LA1QnByU8BkB04A4jrO8xI6a/6oSf6mDatmuHjakQKjmlly dHqJRMLtnX8d0XDEQ/bK6lvSjzmFVs8= 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-501-0G0n0wc0OV-H_RmFdWY9qQ-1; Thu, 21 Apr 2022 11:25:14 -0400 X-MC-Unique: 0G0n0wc0OV-H_RmFdWY9qQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3DBA6803D7C; Thu, 21 Apr 2022 15:25:14 +0000 (UTC) Received: from [10.39.208.35] (unknown [10.39.208.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ED97454ED05; Thu, 21 Apr 2022 15:25:12 +0000 (UTC) Message-ID: Date: Thu, 21 Apr 2022 17:25:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: David Marchand , dev@dpdk.org Cc: stephen@networkplumber.org, chenbo.xia@intel.com, jiayu.hu@intel.com, yuanx.wang@intel.com, xuan.ding@intel.com References: <20220328121758.26632-1-david.marchand@redhat.com> <20220411110013.18624-1-david.marchand@redhat.com> <20220411110013.18624-3-david.marchand@redhat.com> From: Maxime Coquelin Subject: Re: [RFC PATCH v3 2/8] vhost: annotate virtqueue access lock In-Reply-To: <20220411110013.18624-3-david.marchand@redhat.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com 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: 7bit 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 4/11/22 13:00, David Marchand wrote: > This change simply annotates existing paths of the code leading to > manipulations of the vq->access_lock. > > One small change is required: vhost_poll_enqueue_completed was getting > a queue_id to get hold of the vq, while its callers already knew of > the vq. For the annotation sake, vq is now directly passed. It is anyway more consistent with the rest of the code to pass directly the vq in internal API when queue ID is not needed. > vhost_user_lock_all_queue_pairs and vhost_user_unlock_all_queue_pairs > are skipped since vq->access_lock are conditionally held. As discussed off-list, I wonder whether it could be possible to rework the conditional lock holding using the static array and some macros so that we could statically specify for each request if the lock is required. > Signed-off-by: David Marchand > --- > lib/vhost/vhost.h | 2 ++ > lib/vhost/vhost_user.c | 2 ++ > lib/vhost/virtio_net.c | 16 ++++++++++++---- > 3 files changed, 16 insertions(+), 4 deletions(-) > Reviewed-by: Maxime Coquelin Thanks, Maxime