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 F0009A0032; Fri, 22 Apr 2022 11:49:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 984C74067B; Fri, 22 Apr 2022 11:49:57 +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 7E26B40042 for ; Fri, 22 Apr 2022 11:49:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650620996; 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: in-reply-to:in-reply-to:references:references; bh=gxG0bUhZUUmlo+yFvnqU1T5ekqHPP8Q9yI838HrrABw=; b=Yxe5wMsjDfvoxRCWmSRfYksb4ZO2Vfo8PGeE7noPJe3IxxRoVtcv1hUsHREVEuzup3jPys WIzu2EnkUhXCd6O0RppujbDFfkD55ryBHDgUipPGzuo+htTl/KWlCrCqQUlzzsIO668E/E pPYqEJFLhf59SJucPGiGlrkZdqxOoiY= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-505-Cd_Ls9DNO5m_472lxQqfYg-1; Fri, 22 Apr 2022 05:49:54 -0400 X-MC-Unique: Cd_Ls9DNO5m_472lxQqfYg-1 Received: by mail-lj1-f199.google.com with SMTP id d18-20020a2e8912000000b0024dc30cb56dso2211921lji.15 for ; Fri, 22 Apr 2022 02:49:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gxG0bUhZUUmlo+yFvnqU1T5ekqHPP8Q9yI838HrrABw=; b=MWO9DBbvjnxXwst6PilsJ3regowU0OB8FLTIgsXErNtg2QYsOcxafz/WFWb5i7BV+B dExP61kNJ19HaorpC0eWcLnp/oQJhQiAppnrKAezgnU61zVQ0krNKBxKLISEQhoTOQdX 7LmzNgMbsAUhG3i4lBkZiyZ+NhoaZqI65gbJw7rdE/VSUc0bkGacIEMC0NOUooVfngqr BwDpOYVZXbyk4uzOSqhGlcxleHTyw5VUwSECGfsUI02YhWFvvW0M9wX7xHU4XT0zM8WM Bygr7MME6IBlWZ7ilxx1l8vXA6MIa6DC0FSJCJOhYw8QAaYqdm/1Df0yLCgWkGg+Y+WD s6BA== X-Gm-Message-State: AOAM530EhcFKSaXloGTZTl1TqDE8hfctDWWjg883mqxcF6HLqbYM9nPm oK4oF4kOTc8GsphIUB2+LqdI1v5Ca9q1hb3bWm2NfzIDDL5uKNNUr/zKavWE+CXzL/0HFPuQ1W4 +8WQP4pE4HPFk6KWFR4E= X-Received: by 2002:a05:651c:994:b0:24a:fc47:d6ca with SMTP id b20-20020a05651c099400b0024afc47d6camr2292862ljq.297.1650620993429; Fri, 22 Apr 2022 02:49:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWCixJVCA39jbsQSyrdaXRQ+cUJaJ3wqdv1tGoYlX3SqcGxTeLqpZ1rcGeQZdvOaudwnyxQuAX0fZxT9QqJWM= X-Received: by 2002:a05:651c:994:b0:24a:fc47:d6ca with SMTP id b20-20020a05651c099400b0024afc47d6camr2292847ljq.297.1650620993191; Fri, 22 Apr 2022 02:49:53 -0700 (PDT) MIME-Version: 1.0 References: <20220328121758.26632-1-david.marchand@redhat.com> <20220411110013.18624-1-david.marchand@redhat.com> <20220411110013.18624-3-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Fri, 22 Apr 2022 11:49:42 +0200 Message-ID: Subject: Re: [RFC PATCH v3 2/8] vhost: annotate virtqueue access lock To: Maxime Coquelin Cc: dev , Stephen Hemminger , "Xia, Chenbo" , Jiayu Hu , "Wang, YuanX" , Xuan Ding Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 Thu, Apr 21, 2022 at 5:25 PM Maxime Coquelin wrote: > 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. We did discuss some ideas off-list, but in the end, since we have multiple locks being dynamically taken in vhost_user_lock_all_queue_pairs, I see no way to statically annotate the code. We could rework the code to have message handlers in a consolidated static array, but that would not help with annotations. I had some patches going in that direction (related to some fd fixes I sent before), but it needs more work. I'll see if I can send this later in the release or it will go to next release. -- David Marchand