From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: Re: [PATCH 3/3] vfio: use the generic multi-process
	channel
Date: Mon, 11 Dec 2017 12:01:08 +0000
Message-ID: <78628ca0-ae53-5116-c4aa-f3a2b1c9f340@intel.com>
References: <1512067450-59203-1-git-send-email-jianfeng.tan@intel.com>
 <1512067450-59203-4-git-send-email-jianfeng.tan@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: bruce.richardson@intel.com, konstantin.ananyev@intel.com,
 thomas@monjalon.net
To: Jianfeng Tan <jianfeng.tan@intel.com>, dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151])
 by dpdk.org (Postfix) with ESMTP id 3EEDB237
 for <dev@dpdk.org>; Mon, 11 Dec 2017 13:01:10 +0100 (CET)
In-Reply-To: <1512067450-59203-4-git-send-email-jianfeng.tan@intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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 <jianfeng.tan@intel.com>
> ---
>   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