From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jianfeng.tan@intel.com>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by dpdk.org (Postfix) with ESMTP id C761F1B1AA
for <dev@dpdk.org>; Mon, 2 Oct 2017 01:48:08 +0200 (CEST)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
01 Oct 2017 16:48:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.42,466,1500966000"; d="scan'208";a="1020458204"
Received: from tanjianf-mobl.ccr.corp.intel.com (HELO [10.255.25.45])
([10.255.25.45])
by orsmga003.jf.intel.com with ESMTP; 01 Oct 2017 16:48:05 -0700
To: Yuanhan Liu <yliu@fridaylinux.org>
References: <1503654052-84730-1-git-send-email-jianfeng.tan@intel.com>
<1506606959-76230-1-git-send-email-jianfeng.tan@intel.com>
<1506606959-76230-13-git-send-email-jianfeng.tan@intel.com>
<20170929082817.GN2251@yliu-home>
<7d8d48ce-85a2-80a0-744c-48cbeee8ab3c@intel.com>
<20170930075554.GB6251@yliu-home> <20170930114953.GG6251@yliu-home>
Cc: dev@dpdk.org, bruce.richardson@intel.com, konstantin.ananyev@intel.com,
pablo.de.lara.guarch@intel.com, thomas@monjalon.net,
maxime.coquelin@redhat.com, mtetsuyah@gmail.com, ferruh.yigit@intel.com
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Message-ID: <0e7e2108-9890-69ab-e457-2e5875ad52a2@intel.com>
Date: Mon, 2 Oct 2017 07:48:04 +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: <20170930114953.GG6251@yliu-home>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v2 12/12] net/vhost: support to run in the
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: Sun, 01 Oct 2017 23:48:09 -0000
On 9/30/2017 7:49 PM, Yuanhan Liu wrote:
> On Sat, Sep 30, 2017 at 12:06:44PM 0000, Jianfeng Tan wrote:
>>>>>> + /* share callfd and kickfd */
>>>>>> + params->type = VHOST_MSG_TYPE_SET_FDS;
>>>>>> + vring_num = rte_vhost_get_vring_num(vid);
>>>>>> + for (i = 0; i < vring_num; i++) {
>>>>>> + if (rte_vhost_get_vhost_vring(vid, i, &vring) < 0) {
>>>>> If you save the fds here, you don't have to get it every time when there
>>>>> is a new secondary process attached. Then as I have suggested firstly,
>>>>> you don't have to introduce callfd_pri in the vhost lib.
>>>> If we don't introduce callfd_pri, when we do virtqueue cleanup (or similar
>>>> operations) in vhost lib, it will wrongly close fds belonging to secondary
>>>> process.
>>>>
>>>> You remind me that, instead of introduce callfd_pri, we can introduce
>>>> callfd_effective, to reduce the modification lines.
>>> It's not about how many lines are modified. You were adding "effective"
>>> fds, which is a semantic change. It makes the logic a bit more complex.
>>> What's worse, it even doesn't resolve the issue completely.
>> Yes, it still has limitation. Just wonder if possible to move event fd
>> write out of vhost lib.
> It could be another solution: we have the valid fd and vring_avail
> outside the vhost lib. It's just that the callfd write is inside
> the vhost lib. If you just take it out (remove it), it breaks some
> users who rely on it: it's an API behaviour change.
Make sense.
Thanks,
Jianfeng