From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 6A626968 for ; Wed, 6 Sep 2017 09:50:43 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 99B00155E2; Wed, 6 Sep 2017 07:50:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 99B00155E2 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=maxime.coquelin@redhat.com Received: from [10.36.112.20] (ovpn-112-20.ams2.redhat.com [10.36.112.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AB0DB2CFFC; Wed, 6 Sep 2017 07:50:29 +0000 (UTC) To: Stephen Hemminger , 'Tiwei Bie' Cc: dev@dpdk.org, yliu@fridaylinux.org, jfreiman@redhat.com, mst@redhat.com, vkaplans@redhat.com, jasowang@redhat.com, lei.a.yao@intel.com, cunming.liang@intel.com References: <20170831095023.21037-1-maxime.coquelin@redhat.com> <20170831095023.21037-4-maxime.coquelin@redhat.com> <20170905044516.GC31895@debian-ZGViaWFuCg> <68468145-5b45-5875-b37f-35df3482379a@redhat.com> <20170905100751.GA7290@debian-ZGViaWFuCg> <0362ed01-211f-d4fc-d4ae-11ea81ad5df1@redhat.com> <20170906011459.GA3965@debian-ZGViaWFuCg> <000e01d326bc$27fdfbe0$77f9f3a0$@networkplumber.org> From: Maxime Coquelin Message-ID: <13099d85-44d9-c3b9-7db1-20b6ff2b53d9@redhat.com> Date: Wed, 6 Sep 2017 09:50:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <000e01d326bc$27fdfbe0$77f9f3a0$@networkplumber.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 06 Sep 2017 07:50:42 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 03/21] vhost: protect virtio_net device struct X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 07:50:43 -0000 Hi Stephen, On 09/06/2017 04:59 AM, Stephen Hemminger wrote: >>>> This lock has currently two purposes: >>>> 1. Prevent referencing freed virtio_dev struct in case of numa_realloc. >>>> 2. Protect vring pages against invalidation. >>>> >>>> For 2., it can be fixed by using the per-vq IOTLB lock (it was not the >>>> case in my early prototypes that had per device IOTLB cache). >>>> >>>> For 1., this is an existing problem, so we might consider it is >>>> acceptable to keep current state. Maybe it could be improved by only >>>> reallocating in case VQ0 is not on the right NUMA node, the other VQs >>>> not being initialized at this point. > > Something like RCU does a better job of protecting against freed virtio_dev. > But using RCU requires quiescent callback in the main loop. In my early prototypes, I used the urcu library for the IOTLB cache implementation. The problems are that: 1. The lib is LGPL, so only small functions can be inlined into the code (maybe not a important, if "large functions" are only called in the slow path). 2. It adds an external dependency, and the lib is not distributed with every distributions (For RHEL, it is only distributed in EPEL repos). For the virtio_dev protection, my understanding might be incorrect as this is the first time I used RCU, but the struct has one field that the processing threads can write (broadcast_rarp). But it may not be a problem because at worst, only broadcast_rarp clearing would be lost, so we would broadcast RARP one more time. Maxime