From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tan, Jianfeng" Subject: Re: [PATCH 10/12] vhost: support to kick in secondary process Date: Fri, 22 Sep 2017 02:30:21 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "maxime.coquelin@redhat.com" , "mtetsuyah@gmail.com" To: Yuanhan Liu Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 3438A1AEF6 for ; Fri, 22 Sep 2017 04:30:25 +0200 (CEST) In-Reply-To: <20170921091759.GE2251@yliu-home> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Yuanhan Liu [mailto:yliu@fridaylinux.org] > Sent: Thursday, September 21, 2017 5:18 PM > To: Tan, Jianfeng > Cc: dev@dpdk.org; maxime.coquelin@redhat.com; mtetsuyah@gmail.com > Subject: Re: [PATCH 10/12] vhost: support to kick in secondary process >=20 > On Thu, Sep 21, 2017 at 03:04:39PM +0800, Tan, Jianfeng wrote: > > >On Fri, Aug 25, 2017 at 09:40:50AM +0000, Jianfeng Tan wrote: > > >>To support kick in secondary process, we propose callfd_pri and > > >>kickfd_pri to store the value in primary process; and by a new > > >>API, rte_vhost_set_vring_effective_fd(), we can set effective > > >>callfd and kickfd which can be used by secondary process. > > >> > > >>Note in this case, either primary process or the secondary process > > >>can kick the frontend; that is, they cannot kick a vring at the > > >>same time. > > >Since only one can work, why not just overwriting the fd? Say, you > > >could introudce some APIs like "rte_vhost_set_vring_callfd", then > > >you don't need to introduce few more fields like "callfd_pri". > > > > That cannot address the below case: > > 1. Primary starts; > > 2. Secondary one starts; (if we overwrite it without storing it in some > > other fields) > > 3. Secondary one exits; > > 4. Secondary two starts. (primary cannot share the fd with this seconda= ry > > process now, as this fd does not mean anything to the primary process) >=20 > I was thinking that those fds will be retrieved by the primary process > once? So thsoe it got at beginning are still valid? Yes, the FDs are valid to primary process at step 1. But After overwriting = in step 2, those FDs are not valid to primary.