From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CjbmgZEtJUXOdz8m85B4JYVQh8DFMrLTAevtfvmLz9I=; b=t3iK6OZlRiv2HVg3RzsTgItSgc96C06Sr3HJ7Xdz9N/jTNpTO+f0mhwbwd7RAGjPMG gQdGobGrZNrWRpwgQAky7p9whSz0PHrZCCeWsrakaaUV2rXFpfs7ZGFzWJvTdh1vTJs3 zSMekccdyVjBVV+mdD/xJzLDu5comCpg/e5YHnrAGTHfNUmFiY15kllewrSZ+aRwzWcn Npeur9zkfDkxzVGVQsS7Pbd8r7NfKp3xN6CeyVkCh6sR/AqDwtj+4Cfcj4gopBYeUotL Galn24kcsmcsum3rZuwyKOzpAPYu0vRL+F0INOUBf5YmkRIrpwYyVtvMir7fi5rFozKl mueQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=CjbmgZEtJUXOdz8m85B4JYVQh8DFMrLTAevtfvmLz9I=; b=e6yF2cQL4XfhVu7qDqll/MwWDAkQs1EjGf3BpS9fqNxQVoKWVa1CiCG5077oCWLfB+ 7fWLMhWBdja49AbC3U/39pPJiL6SXQRVfLaM8Q/yoeE1VyOUYmd459uBYBPOOUqiHlcY WrwBqsvpDwdjVug3xZGcn+siBdQav6CEW+X5U3Y+hkEmJ/98dJQ26PUHkXaw4DIGKLXE RISdSolyopreR54ZLnfy0wEDRFUnw8qKccmvDALNGpn5bdUGzh5RtBqLLZI3hI6gF3u4 ZYBLhNS+cHpo/87Z/wSJoJwV8CWeKAQPH+kMW5LEx4mDkx9dBKTvv34OUOprCuL3/4gd TxWw== X-Gm-Message-State: AMCzsaVNLKcMIpemfYlQePcuLU0MYfG0j+Wo90W+BR9PNonYbL4g/N30 rDpIpgDy4nyv30Wuk0UI6aboHA== X-Google-Smtp-Source: AOwi7QBmk348BQ3eVdByhn62Zec5Ma/6wfiShSKTHAdoSxe1Mda6GNbs10sXS70SAwwq/UDWw6v0Rg== X-Received: by 10.98.55.3 with SMTP id e3mr275464pfa.215.1506759379310; Sat, 30 Sep 2017 01:16:19 -0700 (PDT) Received: from yliu-home ([222.64.175.152]) by smtp.gmail.com with ESMTPSA id 76sm9747825pfp.158.2017.09.30.01.16.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 30 Sep 2017 01:16:17 -0700 (PDT) Date: Sat, 30 Sep 2017 16:16:14 +0800 From: Yuanhan Liu To: "Tan, Jianfeng" 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 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 Content-Disposition: inline In-Reply-To: <7d8d48ce-85a2-80a0-744c-48cbeee8ab3c@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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 08:16:20 -0000 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