From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A08F3107A for ; Thu, 28 Sep 2017 10:09:51 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 01:09:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,449,1500966000"; d="scan'208";a="133118848" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga004.jf.intel.com with ESMTP; 28 Sep 2017 01:09:41 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 28 Sep 2017 01:09:41 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 28 Sep 2017 01:09:40 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.98]) with mapi id 14.03.0319.002; Thu, 28 Sep 2017 16:09:38 +0800 From: "Tan, Jianfeng" To: Yuanhan Liu CC: "dev@dpdk.org" , "maxime.coquelin@redhat.com" , "mtetsuyah@gmail.com" Thread-Topic: [PATCH 10/12] vhost: support to kick in secondary process Thread-Index: AQHTHYYUzV4m+ArMUUSWfES1Dvn3uKK+U5qAgADBIYD//58lgIABpjxggAfM0oCAAfvWkA== Date: Thu, 28 Sep 2017 08:09:38 +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> <20170927093607.GJ2251@yliu-home> In-Reply-To: <20170927093607.GJ2251@yliu-home> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:09:52 -0000 > -----Original Message----- > From: Yuanhan Liu [mailto:yliu@fridaylinux.org] > Sent: Wednesday, September 27, 2017 5:36 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 Fri, Sep 22, 2017 at 02:30:21AM +0000, Tan, Jianfeng wrote: > > > > > > > -----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 proces= s > > > > > > 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 proces= s > > > > >>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 > secondary > > > > process now, as this fd does not mean anything to the primary proce= ss) > > > > > > I was thinking that those fds will be retrieved by the primary proces= s > > > once? So thsoe it got at beginning are still valid? > > > > Yes, the FDs are valid to primary process at step 1. But After overwrit= ing in > step 2, those FDs are not valid to primary. >=20 > Yes, but the primary process has already got its correct fds saved, right= ? > With the saved fds, it then could share it with another secondary process= . >=20 > Actually, the key (and typical) issue of multi-process here is the fds ar= e > process specific, while they are stored in the shared memory. That means > only one will take effect eventually. Worse, the old ones are lost. >=20 > 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). >=20 > 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 s= ince there are too many queues. For example, if we define an array like thi= s: int vhost_callfds[index_by_vid][index_by_queue_id]; The size would be MAX_VHOST_DEVICE * VHOST_MAX_VRING * 8Byte =3D 2Mbyte. Instead, can we propose something like process_id to index array located at= shared memory? Thanks, Jianfeng