Re: [dpdk-dev] [PATCH v5 2/2] eal/vfio: export internal vfio functions

2018-04-11 Thread Hemant Agrawal




Please, could you rebase on HEAD (on top of Anatoly's patches)?


done





Re: [dpdk-dev] [PATCH v5 2/2] eal/vfio: export internal vfio functions

2018-04-11 Thread Thomas Monjalon
04/04/2018 09:48, Hemant Agrawal:
> This patch moves some of the internal vfio functions from
> eal_vfio.h to rte_vfio.h for common uses with "rte_" prefix.
> 
> This patch also change the FSLMC bus usages from the internal
> VFIO functions to external ones with "rte_" prefix
> 
> Signed-off-by: Hemant Agrawal 
> Acked-by: Anatoly Burakov 
> ---
> v5: fix the bsd compilation
> 
>  drivers/bus/fslmc/Makefile |  1 -
>  drivers/bus/fslmc/fslmc_vfio.c |  7 +--
>  drivers/bus/fslmc/fslmc_vfio.h |  2 -
>  drivers/bus/fslmc/meson.build  |  1 -
>  lib/librte_eal/bsdapp/eal/eal.c| 24 +
>  lib/librte_eal/common/include/rte_vfio.h   | 75 
> +-
>  lib/librte_eal/linuxapp/eal/eal_vfio.c | 39 +++---
>  lib/librte_eal/linuxapp/eal/eal_vfio.h | 21 
>  lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c |  4 +-
>  lib/librte_eal/rte_eal_version.map |  3 ++
>  10 files changed, 127 insertions(+), 50 deletions(-)

Please, could you rebase on HEAD (on top of Anatoly's patches)?





Re: [dpdk-dev] [PATCH v5 2/2] eal/vfio: export internal vfio functions

2018-04-05 Thread Wang, Xiao W
Yes, it's private. We could do that if really needed.

BRs,
Xiao
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Thursday, April 5, 2018 6:23 PM
> To: Wang, Xiao W 
> Cc: Hemant Agrawal ; dev@dpdk.org; Burakov,
> Anatoly 
> Subject: Re: [dpdk-dev] [PATCH v5 2/2] eal/vfio: export internal vfio 
> functions
> 
> 05/04/2018 11:03, Wang, Xiao W:
> 
> > > +int rte_vfio_get_group_num(const char *sysfs_base, const char
> *dev_addr,
> > > +int *iommu_group_num);
> > > +int rte_vfio_get_container_fd(void);
> > > +int rte_vfio_get_group_fd(int iommu_group_num);
> >
> > Considering the "group_no" field defined in eal_vfio.h, will
> "iommu_group_num" cause inconsistency
> > In naming?
> 
> I asked to change the function name to "num" because it is more meaningful.
> "group_no" field is private? Can it be renamed?
> 



Re: [dpdk-dev] [PATCH v5 2/2] eal/vfio: export internal vfio functions

2018-04-05 Thread Thomas Monjalon
05/04/2018 11:03, Wang, Xiao W:

> > +int rte_vfio_get_group_num(const char *sysfs_base, const char *dev_addr,
> > +  int *iommu_group_num);
> > +int rte_vfio_get_container_fd(void);
> > +int rte_vfio_get_group_fd(int iommu_group_num);
> 
> Considering the "group_no" field defined in eal_vfio.h, will 
> "iommu_group_num" cause inconsistency
> In naming?

I asked to change the function name to "num" because it is more meaningful.
"group_no" field is private? Can it be renamed?




Re: [dpdk-dev] [PATCH v5 2/2] eal/vfio: export internal vfio functions

2018-04-05 Thread Wang, Xiao W
Hi Hemant,

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Hemant Agrawal
> Sent: Wednesday, April 4, 2018 3:49 PM
> To: dev@dpdk.org
> Cc: Burakov, Anatoly ; tho...@monjalon.net
> Subject: [dpdk-dev] [PATCH v5 2/2] eal/vfio: export internal vfio functions
> 
> This patch moves some of the internal vfio functions from
> eal_vfio.h to rte_vfio.h for common uses with "rte_" prefix.
> 
> This patch also change the FSLMC bus usages from the internal
> VFIO functions to external ones with "rte_" prefix
> 
> Signed-off-by: Hemant Agrawal 
> Acked-by: Anatoly Burakov 
> ---
> v5: fix the bsd compilation
> 
>  drivers/bus/fslmc/Makefile |  1 -
>  drivers/bus/fslmc/fslmc_vfio.c |  7 +--
>  drivers/bus/fslmc/fslmc_vfio.h |  2 -
>  drivers/bus/fslmc/meson.build  |  1 -
>  lib/librte_eal/bsdapp/eal/eal.c| 24 +
>  lib/librte_eal/common/include/rte_vfio.h   | 75
> +-
>  lib/librte_eal/linuxapp/eal/eal_vfio.c | 39 +++---
>  lib/librte_eal/linuxapp/eal/eal_vfio.h | 21 
>  lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c |  4 +-
>  lib/librte_eal/rte_eal_version.map |  3 ++
>  10 files changed, 127 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/bus/fslmc/Makefile b/drivers/bus/fslmc/Makefile
> index 93870ba..3aa34e2 100644
> --- a/drivers/bus/fslmc/Makefile
> +++ b/drivers/bus/fslmc/Makefile
> @@ -16,7 +16,6 @@ CFLAGS += $(WERROR_FLAGS)
>  CFLAGS += -I$(RTE_SDK)/drivers/bus/fslmc
>  CFLAGS += -I$(RTE_SDK)/drivers/bus/fslmc/mc
>  CFLAGS += -I$(RTE_SDK)/drivers/bus/fslmc/qbman/include
> -CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal
>  CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common
>  LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
>  LDLIBS += -lrte_ethdev
> diff --git a/drivers/bus/fslmc/fslmc_vfio.c b/drivers/bus/fslmc/fslmc_vfio.c
> index 62499de..f3b2960 100644
> --- a/drivers/bus/fslmc/fslmc_vfio.c
> +++ b/drivers/bus/fslmc/fslmc_vfio.c
> @@ -91,7 +91,8 @@ fslmc_get_container_group(int *groupid)
>   }
> 
>   /* get group number */
> - ret = vfio_get_group_no(SYSFS_FSL_MC_DEVICES, g_container,
> groupid);
> + ret = rte_vfio_get_group_num(SYSFS_FSL_MC_DEVICES,
> +  g_container, groupid);
>   if (ret <= 0) {
>   DPAA2_BUS_ERR("Unable to find %s IOMMU group",
> g_container);
>   return -1;
> @@ -124,7 +125,7 @@ vfio_connect_container(void)
>   }
> 
>   /* Opens main vfio file descriptor which represents the "container" */
> - fd = vfio_get_container_fd();
> + fd = rte_vfio_get_container_fd();
>   if (fd < 0) {
>   DPAA2_BUS_ERR("Failed to open VFIO container");
>   return -errno;
> @@ -620,7 +621,7 @@ fslmc_vfio_setup_group(void)
>   }
> 
>   /* Get the actual group fd */
> - ret = vfio_get_group_fd(groupid);
> + ret = rte_vfio_get_group_fd(groupid);
>   if (ret < 0)
>   return ret;
>   vfio_group.fd = ret;
> diff --git a/drivers/bus/fslmc/fslmc_vfio.h b/drivers/bus/fslmc/fslmc_vfio.h
> index e8fb344..9e2c4fe 100644
> --- a/drivers/bus/fslmc/fslmc_vfio.h
> +++ b/drivers/bus/fslmc/fslmc_vfio.h
> @@ -10,8 +10,6 @@
> 
>  #include 
> 
> -#include "eal_vfio.h"
> -
>  #define DPAA2_MC_DPNI_DEVID  7
>  #define DPAA2_MC_DPSECI_DEVID3
>  #define DPAA2_MC_DPCON_DEVID 5
> diff --git a/drivers/bus/fslmc/meson.build b/drivers/bus/fslmc/meson.build
> index e94340e..78f9d92 100644
> --- a/drivers/bus/fslmc/meson.build
> +++ b/drivers/bus/fslmc/meson.build
> @@ -22,6 +22,5 @@ sources = files('fslmc_bus.c',
> 
>  allow_experimental_apis = true
> 
> -includes += include_directories('../../../lib/librte_eal/linuxapp/eal')
>  includes += include_directories('mc', 'qbman/include', 'portal')
>  cflags += ['-D_GNU_SOURCE']
> diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
> index 4eafcb5..e2f2df1 100644
> --- a/lib/librte_eal/bsdapp/eal/eal.c
> +++ b/lib/librte_eal/bsdapp/eal/eal.c
> @@ -746,6 +746,10 @@ int rte_vfio_enable(const char *modname);
>  int rte_vfio_is_enabled(const char *modname);
>  int rte_vfio_noiommu_is_enabled(void);
>  int rte_vfio_clear_group(int vfio_group_fd);
> +int rte_vfio_get_group_num(const char *sysfs_base, const char *dev_addr,
> +int *iommu_group_num);
> +int rte_vfio_get_container_fd(void);
> +int rte_vfio_get_group_fd(int iommu_group_num);

Considering the "group_no" field defined in eal_vfio.h, will "iommu_group_num" 
cause inconsistency
In naming?
 
/*
 * we don't need to store device fd's anywhere since they can be obtained from
 * the group fd via an ioctl() call.
 */
struct vfio_group {
int group_no;
int fd;
int devices;
};

BRs,
Xiao