[dpdk-dev] [PATCH 3/3] vfio: use the generic multi-process channel
Burakov, Anatoly
anatoly.burakov at intel.com
Mon Dec 11 13:01:08 CET 2017
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 at 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
More information about the dev
mailing list