From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuanhan Liu Subject: Re: [PATCH v2 12/12] net/vhost: support to run in the secondary process Date: Sat, 30 Sep 2017 16:16:14 +0800 Message-ID: <20170930075554.GB6251@yliu-home> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 To: "Tan, Jianfeng" Return-path: Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com [209.85.192.174]) by dpdk.org (Postfix) with ESMTP id 24FD237B4 for ; Sat, 30 Sep 2017 10:16:20 +0200 (CEST) Received: by mail-pf0-f174.google.com with SMTP id y29so866877pff.0 for ; Sat, 30 Sep 2017 01:16:19 -0700 (PDT) Content-Disposition: inline In-Reply-To: <7d8d48ce-85a2-80a0-744c-48cbeee8ab3c@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. > 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. --yliu