From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 3EEDB237 for ; Mon, 11 Dec 2017 13:01:10 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 04:01:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,391,1508828400"; d="scan'208";a="185931505" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.117]) ([10.237.220.117]) by fmsmga006.fm.intel.com with ESMTP; 11 Dec 2017 04:01:08 -0800 To: Jianfeng Tan , dev@dpdk.org Cc: bruce.richardson@intel.com, konstantin.ananyev@intel.com, thomas@monjalon.net References: <1512067450-59203-1-git-send-email-jianfeng.tan@intel.com> <1512067450-59203-4-git-send-email-jianfeng.tan@intel.com> From: "Burakov, Anatoly" Message-ID: <78628ca0-ae53-5116-c4aa-f3a2b1c9f340@intel.com> Date: Mon, 11 Dec 2017 12:01:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512067450-59203-4-git-send-email-jianfeng.tan@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 3/3] vfio: use the generic multi-process channel 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: Mon, 11 Dec 2017 12:01:11 -0000 On 30-Nov-17 6:44 PM, Jianfeng Tan wrote: > Previously, vfio has its own channel for the secondary process to > get container fd and group fd from the primary process. > > This patch changes to use the generic mp channel. > > Signed-off-by: Jianfeng Tan > --- > lib/librte_eal/linuxapp/eal/eal.c | 14 +- > lib/librte_eal/linuxapp/eal/eal_vfio.c | 139 +++------ > lib/librte_eal/linuxapp/eal/eal_vfio.h | 15 +- > lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c | 416 ++++--------------------- > 4 files changed, 109 insertions(+), 475 deletions(-) > > diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c > index a84eab4..93824bf 100644 > --- a/lib/librte_eal/linuxapp/eal/eal.c > +++ b/lib/librte_eal/linuxapp/eal/eal.c <...snip...> > - default: > - RTE_LOG(ERR, EAL, " cannot get container fd!\n"); > - close(socket_fd); > - return -1; > - } > + ret = rte_eal_mp_sendmsg("vfio", &p, sizeof(p), NULL, 0, 1); > + if (ret < 0) { > + RTE_LOG(ERR, EAL, " cannot request group fd!\n"); > + cur_grp->group_no = -1; > + } else { > + cur_grp->group_no = iommu_group_no; > + vfio_cfg.vfio_active_groups++; > } Either i'm missing something here, or i don't see where we actually store the group fd (e.g. the "cur_gtp->fd = vfio_group_fd" part from the previous code). Also, this is why i mentioned "receive parameters" in comments to previous patch - looking at this code, it is quite unclear that the return from rte_eal_mp_sendmsg is either error or, well, "something", defined as "whatever mp_action returns". It would be much clearer if we were explicitly getting some data in response. > - return -1; > + > + return ret; > } > > <...snip...> > + /* For secondary process, request container fd from primary process */ > + > + p.req = SOCKET_REQ_CONTAINER; > + > + ret = rte_eal_mp_sendmsg("vfio", &p, sizeof(p), NULL, 0, 1); > + if (ret < 0) > + RTE_LOG(ERR, EAL, " cannot request container fd!\n"); Again here, looks counter-intuitive to get container fd in return - it would've been much clearer to have a separate response parameter. > + > + return ret; > } > <...snip...> > > static int > -vfio_mp_sync_socket_setup(void) > +vfio_mp_secondary(const void *params, int len, int fds[], > + int fds_num __rte_unused) fds_num isn't unused here. > { -- Thanks, Anatoly