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 5BBC7A0A0C; Thu, 1 Jul 2021 17:43:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0B5D240141; Thu, 1 Jul 2021 17:43:08 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 5B26F4003E for ; Thu, 1 Jul 2021 17:43:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625154185; 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=UIX7Rt1J352cmEOFtDso6YUmmxoWez0oqJx2eG6VCps=; b=f09sA/FXb8f87BMIy3jPhXqo9GEzcJ3x9d1ZrkTks+CH/HsNobQUHjIBn7ghlRPlZTZook cSCmLU50OQJVx7K9AIG2HyGyOSiLSs34okYu7PNZohwyKLfLDfmb+q6XgEf0UwFU47R6c/ 2scCuvB7YWon6H96EdVgHJFpLxaHbYA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-225-qylRmzjwM4iPmOmY5Aouvw-1; Thu, 01 Jul 2021 11:43:03 -0400 X-MC-Unique: qylRmzjwM4iPmOmY5Aouvw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D910C948; Thu, 1 Jul 2021 15:43:01 +0000 (UTC) Received: from [10.36.110.32] (unknown [10.36.110.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 94AE25D9D3; Thu, 1 Jul 2021 15:43:00 +0000 (UTC) To: "Hu, Jiayu" , Maxime Coquelin , "dev@dpdk.org" Cc: "Xia, Chenbo" , "Wang, Yinan" , David Marchand References: <1622189463-392610-1-git-send-email-jiayu.hu@intel.com> <48481706-5745-40b6-0a1a-88911cb4ae0f@redhat.com> <3237b4e8040f45f7bdaefff67828cb71@intel.com> From: Maxime Coquelin Message-ID: <2c2bff9d-c703-d914-6b06-13c20c81146c@redhat.com> Date: Thu, 1 Jul 2021 17:42:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3237b4e8040f45f7bdaefff67828cb71@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 0/2] provide thread unsafe async registration functions 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 Sender: "dev" Hi Jiayu, On 6/29/21 7:36 AM, Hu, Jiayu wrote: > Hi Maxime, > >> -----Original Message----- >> From: Maxime Coquelin >> Sent: Monday, June 7, 2021 9:20 PM >> To: Hu, Jiayu ; dev@dpdk.org >> Cc: maxime.coquelin@redhat.com; Xia, Chenbo ; >> Wang, Yinan >> Subject: Re: [PATCH 0/2] provide thread unsafe async registration functions >> >> Hi Jiayu, >> >> On 6/7/21 10:07 AM, Hu, Jiayu wrote: >>> Hi Maxime, >>> >>>> -----Original Message----- >>>> From: Maxime Coquelin >>>> Sent: Friday, June 4, 2021 3:25 PM >>>> To: Hu, Jiayu ; dev@dpdk.org >>>> Cc: maxime.coquelin@redhat.com; Xia, Chenbo ; >>>> Wang, Yinan >>>> Subject: Re: [PATCH 0/2] provide thread unsafe async registration >>>> functions >>>> >>>> Sorry, for previous blank reply. >>>> >>>> On 5/28/21 10:11 AM, Jiayu Hu wrote: >>>>> Lock protection is needed during the vhost notifies the application >>>>> of device readiness, so the first patch is to add lock protection. >>>>> After performing locking, existed async vhost registration functions >>>>> will cause deadlock, as they acquire lock too. So the second patch >>>>> is to provide unsafe registration functions to support calling >>>>> within vhost callback functions. >>>> >>>> I agree the callback should be always protected, and in that case >>>> having a new thread-unsafe API makes sense for async registration. >>>> >>>> Regarding backport, I'm not sure what we should do. >>>> >>>> Backporting new API is a no-go, but with only backporting patch 1 >>>> async feature will be always broken on 20.11 LTS, right? >>> >>> Yes, if only backporting this fix patch to 20.11 LTS, it may break >>> apps who call async registration functions inside vhost callbacks. >>> >>> How about making this patch not a fix, but a new feature? >> >> Async will be still broken in v20.11 in this case. >> Maybe the better thing would be to remove async support in v20.11, as its >> support was quite limited in that release anyway. Does that make sense? > > The code of supporting async vhost are beyond 1000 lines. I am afraid that > removing such more code in 20.11 LTS may get objected. Can we note async > register/unregister only work in new_/destroy_device, and using them in > other vhost callback functions will cause deadlock in 20.11 LTS instead? > Does it make sense to you? You are right, that removing 1L LoC in LTS might not be the best idea, since it will cause conflicts when doing backports later on. Maybe the best way is to return -1 at async registration time, with logging an error? Thanks, Maxime > Thanks, > Jiayu >> >> Thanks, >> Maxime >> >>> Thanks, >>> Jiayu >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> Maxime >