From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jianfeng.tan@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
by dpdk.org (Postfix) with ESMTP id DB066101B
for <dev@dpdk.org>; Sat, 30 Sep 2017 12:50:44 +0200 (CEST)
Received: from orsmga005.jf.intel.com ([10.7.209.41])
by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
30 Sep 2017 03:50:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.42,457,1500966000"; d="scan'208";a="155110832"
Received: from tanjianf-mobl.ccr.corp.intel.com (HELO [10.255.30.130])
([10.255.30.130])
by orsmga005.jf.intel.com with ESMTP; 30 Sep 2017 03:50:42 -0700
To: Yuanhan Liu <yliu@fridaylinux.org>
References: <1503654052-84730-1-git-send-email-jianfeng.tan@intel.com>
<1503654052-84730-11-git-send-email-jianfeng.tan@intel.com>
<20170921033323.GA2251@yliu-home>
<59f2bfc0-91ee-b276-68e3-563e5b5af89b@intel.com>
<20170921091759.GE2251@yliu-home>
<ED26CBA2FAD1BF48A8719AEF02201E36512EF4CE@SHSMSX103.ccr.corp.intel.com>
<20170927093607.GJ2251@yliu-home>
<ED26CBA2FAD1BF48A8719AEF02201E36512F919B@SHSMSX103.ccr.corp.intel.com>
<20170930081846.GC6251@yliu-home>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
"mtetsuyah@gmail.com" <mtetsuyah@gmail.com>
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Message-ID: <41f24385-b540-529e-2d96-8a274a4f9ad8@intel.com>
Date: Sat, 30 Sep 2017 18:50:41 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170930081846.GC6251@yliu-home>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH 10/12] vhost: support to kick in secondary
process
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Sep 2017 10:50:46 -0000
On 9/30/2017 4:18 PM, Yuanhan Liu wrote:
> On Thu, Sep 28, 2017 at 08:09:38AM +0000, Tan, Jianfeng wrote:
>>> Actually, the key (and typical) issue of multi-process here is the fds are
>>> process specific, while they are stored in the shared memory. That means
>>> only one will take effect eventually. Worse, the old ones are lost.
>>>
>>> So, I think to make it right in this case, you should move the fds from
>>> the shared memory and store them in the memory of the corresponding
>>> process.
>>> If that's done, all processes could have its own valid fds, then every
>>> process could do the kick (if that's really necessary).
>>>
>>> You could check following commit for more info.
>>> 553f45932fb7 ("net/virtio: store PCI operators pointer locally")
>> Have referred to the above solution, but seems not feasible for this case since there are too many queues. For example, if we define an array like this:
>> int vhost_callfds[index_by_vid][index_by_queue_id];
>> The size would be MAX_VHOST_DEVICE * VHOST_MAX_VRING * 8Byte = 2Mbyte.
> I think you can do it in a dynamic way, like what we did for vhost_dev
> allocation?
I'll give it a try, thanks!
Thanks,
Jianfeng
>
> --yliu
>> Instead, can we propose something like process_id to index array located at shared memory?
>>
>> Thanks,
>> Jianfeng