From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id F0BEA7CD8 for ; Sat, 30 Sep 2017 06:03:37 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 21:03:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,455,1500966000"; d="scan'208";a="155042622" Received: from tanjianf-mobl.ccr.corp.intel.com (HELO [10.255.30.130]) ([10.255.30.130]) by orsmga005.jf.intel.com with ESMTP; 29 Sep 2017 21:03:34 -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> 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: <7d8d48ce-85a2-80a0-744c-48cbeee8ab3c@intel.com> Date: Sat, 30 Sep 2017 12:03:33 +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: <20170929082817.GN2251@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: Sat, 30 Sep 2017 04:03:38 -0000 Hi Yuanhan, On 9/29/2017 4:28 PM, Yuanhan Liu wrote: > On Thu, Sep 28, 2017 at 01:55:59PM +0000, Jianfeng Tan wrote: >> static int >> +share_device(int vid) >> +{ >> + uint32_t i, vring_num; >> + int len; >> + int fds[8]; >> + struct rte_vhost_memory *mem; >> + struct vhost_params *params; >> + struct rte_vhost_vring vring; >> + >> + /* share mem table */ >> + if (rte_vhost_get_mem_table(vid, &mem) < 0) { >> + RTE_LOG(ERR, PMD, "Failed to get mem table\n"); >> + return 0; >> + } >> + for (i = 0; i < mem->nregions; ++i) >> + fds[i] = mem->regions[i].fd; >> + >> + len = sizeof(struct rte_vhost_mem_region) * mem->nregions; >> + params = malloc(sizeof(*params) + len); >> + if (params == NULL) { >> + RTE_LOG(ERR, PMD, "Failed to allocate memory\n"); >> + return -1; >> + } >> + >> + params->type = VHOST_MSG_TYPE_REGIONS; >> + params->vid = vid; >> + memcpy(params->regions, mem->regions, len); >> + >> + if (rte_eal_mp_sendmsg("vhost pmd", params, sizeof(*params) + len, > To me, it's not a good idea to identify an object by a string. The common > practice is to use a handler, which could either be a struct or a nubmer. My point is that if we choose the way you suggested, we need somewhere to maintain them. For example, every time we need register a new action, we need to update that file to add a new entry (number). In current way, the duplicated register with the same name will fail, developers is responsible to check that. > >> + fds, mem->nregions) < 0) { >> + RTE_LOG(ERR, PMD, "Failed to share mem table\n"); >> + free(params); >> + return -1; >> + } >> + >> + /* 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. Thanks, Jianfeng