| Message ID | 20190207130051.17459-1-i.maximets@samsung.com |
|---|---|
| State | Accepted |
| Delegated to: | Ian Stokes |
| Headers | show |
| Series | [ovs-dev] acinclude: Use NUMA_AWARE_HUGEPAGES too for libnuma check. | expand |
On 2/7/2019 1:00 PM, Ilya Maximets wrote: > This fixes build with NUMA_AWARE_HUGEPAGES enabled and VHOST_NUMA > disabled. This should not be a usual case. But it's possible to > configure DPDK this way. > Out of interest, with RTE_EAL_NUMA_AWARE_HUGEPAGES defined but not RTE_LIBRTE_VHOST_NUMA, does vhost numa still work as expected? Ian > Fixes: 5e925ccc2a6f ("netdev-dpdk: DPDK v17.11 upgrade") > > Signed-off-by: Ilya Maximets <i.maximets@samsung.com> > --- > acinclude.m4 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/acinclude.m4 b/acinclude.m4 > index c51af246a..e2af4ee16 100644 > --- a/acinclude.m4 > +++ b/acinclude.m4 > @@ -254,7 +254,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > AC_LANG_PROGRAM( > [ > #include <rte_config.h> > -#if RTE_LIBRTE_VHOST_NUMA > +#if defined(RTE_LIBRTE_VHOST_NUMA) || defined(RTE_EAL_NUMA_AWARE_HUGEPAGES) > #error > #endif > ], []) >
On 07.02.2019 19:18, Ian Stokes wrote: > On 2/7/2019 1:00 PM, Ilya Maximets wrote: >> This fixes build with NUMA_AWARE_HUGEPAGES enabled and VHOST_NUMA >> disabled. This should not be a usual case. But it's possible to >> configure DPDK this way. >> > > Out of interest, with RTE_EAL_NUMA_AWARE_HUGEPAGES defined but not RTE_LIBRTE_VHOST_NUMA, does vhost numa still work as expected? If RTE_LIBRTE_VHOST_NUMA disabled, all the numa related code from librte_vhost will be compiled out. So, rte_vhost_get_numa_node() will always return -1. i.e. we will not be able to reallocate memory pools according to numa node where VM started. At the same time eal_memory and eal_memalloc modules will work fine allocating hugepages and memory from the requested numa nodes. > > Ian >> Fixes: 5e925ccc2a6f ("netdev-dpdk: DPDK v17.11 upgrade") >> >> Signed-off-by: Ilya Maximets <i.maximets@samsung.com> >> --- >> acinclude.m4 | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/acinclude.m4 b/acinclude.m4 >> index c51af246a..e2af4ee16 100644 >> --- a/acinclude.m4 >> +++ b/acinclude.m4 >> @@ -254,7 +254,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [ >> AC_LANG_PROGRAM( >> [ >> #include <rte_config.h> >> -#if RTE_LIBRTE_VHOST_NUMA >> +#if defined(RTE_LIBRTE_VHOST_NUMA) || defined(RTE_EAL_NUMA_AWARE_HUGEPAGES) >> #error >> #endif >> ], []) >> > > >
On 07.02.2019 19:26, Ilya Maximets wrote: > On 07.02.2019 19:18, Ian Stokes wrote: >> On 2/7/2019 1:00 PM, Ilya Maximets wrote: >>> This fixes build with NUMA_AWARE_HUGEPAGES enabled and VHOST_NUMA >>> disabled. This should not be a usual case. But it's possible to >>> configure DPDK this way. >>> >> >> Out of interest, with RTE_EAL_NUMA_AWARE_HUGEPAGES defined but not RTE_LIBRTE_VHOST_NUMA, does vhost numa still work as expected? > > If RTE_LIBRTE_VHOST_NUMA disabled, all the numa related code from > librte_vhost will be compiled out. So, rte_vhost_get_numa_node() > will always return -1. i.e. we will not be able to reallocate > memory pools according to numa node where VM started. > > At the same time eal_memory and eal_memalloc modules will work fine > allocating hugepages and memory from the requested numa nodes. > There are few realistic examples for that case: 1. User builds dpdk without vhost library because there is no plan to run VMs on target platform. (Some HW switch or edge node). 2. User builds dpdk without vhost library because there is a plan to use SR-IOV with full HW offloading and port representors. No vhost ports planned. (Not possible with upstream OVS, but patches are already on a list). >> >> Ian >>> Fixes: 5e925ccc2a6f ("netdev-dpdk: DPDK v17.11 upgrade") >>> >>> Signed-off-by: Ilya Maximets <i.maximets@samsung.com> >>> --- >>> acinclude.m4 | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/acinclude.m4 b/acinclude.m4 >>> index c51af246a..e2af4ee16 100644 >>> --- a/acinclude.m4 >>> +++ b/acinclude.m4 >>> @@ -254,7 +254,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [ >>> AC_LANG_PROGRAM( >>> [ >>> #include <rte_config.h> >>> -#if RTE_LIBRTE_VHOST_NUMA >>> +#if defined(RTE_LIBRTE_VHOST_NUMA) || defined(RTE_EAL_NUMA_AWARE_HUGEPAGES) >>> #error >>> #endif >>> ], []) >>> >> >> >>
On 2/8/2019 2:28 PM, Ilya Maximets wrote: > On 07.02.2019 19:26, Ilya Maximets wrote: >> On 07.02.2019 19:18, Ian Stokes wrote: >>> On 2/7/2019 1:00 PM, Ilya Maximets wrote: >>>> This fixes build with NUMA_AWARE_HUGEPAGES enabled and VHOST_NUMA >>>> disabled. This should not be a usual case. But it's possible to >>>> configure DPDK this way. >>>> >>> >>> Out of interest, with RTE_EAL_NUMA_AWARE_HUGEPAGES defined but not RTE_LIBRTE_VHOST_NUMA, does vhost numa still work as expected? >> >> If RTE_LIBRTE_VHOST_NUMA disabled, all the numa related code from >> librte_vhost will be compiled out. So, rte_vhost_get_numa_node() >> will always return -1. i.e. we will not be able to reallocate >> memory pools according to numa node where VM started. >> >> At the same time eal_memory and eal_memalloc modules will work fine >> allocating hugepages and memory from the requested numa nodes. >> > > There are few realistic examples for that case: > 1. User builds dpdk without vhost library because there is no plan to > run VMs on target platform. (Some HW switch or edge node). > 2. User builds dpdk without vhost library because there is a plan to > use SR-IOV with full HW offloading and port representors. No > vhost ports planned. (Not possible with upstream OVS, but patches > are already on a list). > Thanks for the clarification. I've pushed to master and backported to OVS 2.9. Thanks Ian
diff --git a/acinclude.m4 b/acinclude.m4 index c51af246a..e2af4ee16 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -254,7 +254,7 @@ AC_DEFUN([OVS_CHECK_DPDK], [ AC_LANG_PROGRAM( [ #include <rte_config.h> -#if RTE_LIBRTE_VHOST_NUMA +#if defined(RTE_LIBRTE_VHOST_NUMA) || defined(RTE_EAL_NUMA_AWARE_HUGEPAGES) #error #endif ], [])
This fixes build with NUMA_AWARE_HUGEPAGES enabled and VHOST_NUMA disabled. This should not be a usual case. But it's possible to configure DPDK this way. Fixes: 5e925ccc2a6f ("netdev-dpdk: DPDK v17.11 upgrade") Signed-off-by: Ilya Maximets <i.maximets@samsung.com> --- acinclude.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)