From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id C761F1B1AA for ; 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 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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