From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 2505E107A for ; Sat, 30 Sep 2017 12:06:49 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP; 30 Sep 2017 03:06:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,457,1500966000"; d="scan'208";a="133812281" Received: from tanjianf-mobl.ccr.corp.intel.com (HELO [10.255.30.130]) ([10.255.30.130]) by orsmga004.jf.intel.com with ESMTP; 30 Sep 2017 03:06:45 -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> 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: <3f6da5f9-9df0-a2c0-6823-c95f459b4d64@intel.com> Date: Sat, 30 Sep 2017 18:06:44 +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: <20170930075554.GB6251@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 10:06:50 -0000 On 9/30/2017 4:16 PM, Yuanhan Liu wrote: > On Sat, Sep 30, 2017 at 12:03:33PM +0800, Tan, Jianfeng wrote: >>>> + 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). > Not really. You could let the register function to return a struct, in > which there is a name field. > > Anyway, I think it's not a big deal to turn it to struct, judging that > it may only contain one field only: the name. But at least, you should > not type the same string everywhere. Use macro instead. Agreed. Will fix that. > >> 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. > 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. Thanks, Jianfeng > > --yliu