[dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[Nissim Nisimov]

Problem:
In DPDK Primary/Secondary module we assume mapping same regions of virtual memory addresses for Primary process and Secondary.
An issue may occur when the Primary and secondary processes are not symmetric in such way that the code is not the same (for example, Primary process is a traffic distributer and secondary is a worker). The result may be that specific virtual address region in the first process won't be available in the second process.

Changes done at eal init:
map all related rte configuration and uio sections close to the end of huge pages memory (that mean rte_eal_memory_init() should be called before rte_config_init() in primary process)
According to our observations there will be more probability to success when allocating rte_config and uio memzones after huge pages sections (actually uio is already allocated after the huge pages area)

Signed-off-by: Nissim Nisimov <nissimn@radware.com>
---
 lib/librte_eal/linuxapp/eal/eal.c         | 28 ++++++++++++++++++++++------
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 10 +++++++---
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 33e1067..3cb354b 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -87,6 +87,7 @@
 
 #define SOCKET_MEM_STRLEN (RTE_MAX_NUMA_NODES * 10)
 
+void *pci_find_max_end_va(void);
 /* Allow the application to print its usage message too if set */
 static rte_usage_hook_t	rte_application_usage_hook = NULL;
 
@@ -189,12 +190,15 @@ rte_eal_config_create(void)
 		return;
 
 	/* map the config before hugepage address so that we don't waste a page */
-	if (internal_config.base_virtaddr != 0)
+	if (internal_config.base_virtaddr != 0){
 		rte_mem_cfg_addr = (void *)
 			RTE_ALIGN_FLOOR(internal_config.base_virtaddr -
 			sizeof(struct rte_mem_config), sysconf(_SC_PAGE_SIZE));
-	else
-		rte_mem_cfg_addr = NULL;
+        }
+	else{
+		rte_mem_cfg_addr = pci_find_max_end_va();
+                RTE_LOG(INFO, EAL, "rte_mem_cfg_addr =  0x%llx PType=%s\n",(unsigned long long)rte_mem_cfg_addr,rte_config.process_type == RTE_PROC_PRIMARY ? "PRIMARY" : "SECONDARY");
+        }
 
 	if (mem_cfg_fd < 0){
 		mem_cfg_fd = open(pathname, O_RDWR | O_CREAT, 0660);
@@ -227,7 +231,7 @@ rte_eal_config_create(void)
 	/* store address of the config in the config itself so that secondary
 	 * processes could later map the config into this exact location */
 	rte_config.mem_config->mem_cfg_addr = (uintptr_t) rte_mem_cfg_addr;
-
+        
 }
 
 /* attach to an existing shared memory config */
@@ -784,6 +788,13 @@ rte_eal_init(int argc, char **argv)
 
 	rte_srand(rte_rdtsc());
 
+        /* Primary process should allocate hugepages before configuration */
+	if(internal_config.process_type == RTE_PROC_PRIMARY){
+		RTE_LOG(INFO, EAL, "Calling rte_eal_memory_init as =%s\n",(rte_config.process_type == RTE_PROC_PRIMARY) ? "PRIMARY" : "SECONDARY");
+		if (rte_eal_memory_init() < 0)
+			rte_panic("Cannot init memory\n");
+	}
+
 	rte_config_init();
 
 	if (rte_eal_pci_init() < 0)
@@ -793,8 +804,13 @@ rte_eal_init(int argc, char **argv)
 	if (rte_eal_ivshmem_init() < 0)
 		rte_panic("Cannot init IVSHMEM\n");
 #endif
-
-	if (rte_eal_memory_init() < 0)
+        /* secondary process will call memory init only after calling to rte_config_init() */
+	if(internal_config.process_type == RTE_PROC_SECONDARY){
+		RTE_LOG(INFO, EAL, "Calling rte_eal_memory_init as =%s\n",rte_config.process_type == RTE_PROC_PRIMARY ? "PRIMARY" : "SECONDARY");
+		if (rte_eal_memory_init() < 0)
+			rte_panic("Cannot init memory\n");
+	}
+        if (rte_eal_memory_init() < 0)
 		rte_panic("Cannot init memory\n");
 
 	/* the directories are locked during eal_hugepage_info_init */
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index ac50e13..6812c37 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -338,9 +338,13 @@ pci_uio_map_resource_by_index(struct rte_pci_device *dev, int res_idx,
 	}
 
 	/* try mapping somewhere close to the end of hugepages */
-	if (pci_map_addr == NULL)
-		pci_map_addr = pci_find_max_end_va();
-
+	if (pci_map_addr == NULL){
+		if (internal_config.base_virtaddr != 0){
+                	pci_map_addr = pci_find_max_end_va();
+                } else{
+                	pci_map_addr = (void*)RTE_PTR_ALIGN(((char*)rte_eal_get_configuration()->mem_config->mem_cfg_addr + sizeof(struct rte_mem_config)),sysconf(_SC_PAGE_SIZE));
+                }
+        }
 	mapaddr = pci_map_resource(pci_map_addr, fd, 0,
 			(size_t)dev->mem_resource[res_idx].len, 0);
 	close(fd);
-- 
2.6.1

Re: [dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[Burakov, Anatoly]

Hi

> Problem:
> In DPDK Primary/Secondary module we assume mapping same regions of
> virtual memory addresses for Primary process and Secondary.
> An issue may occur when the Primary and secondary processes are not
> symmetric in such way that the code is not the same (for example, Primary
> process is a traffic distributer and secondary is a worker). The result may be
> that specific virtual address region in the first process won't be available in
> the second process.
> 
> Changes done at eal init:
> map all related rte configuration and uio sections close to the end of huge
> pages memory (that mean rte_eal_memory_init() should be called before
> rte_config_init() in primary process)
> According to our observations there will be more probability to success when
> allocating rte_config and uio memzones after huge pages sections (actually
> uio is already allocated after the huge pages area)

Not sure I understand the purpose of the patch. Doesn't --base-virtaddr flag solve your issues?

Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[Nissim Nisimov]

Hi Anatoly,


Actually the use of --base-virtaddr will be valuable only when user know in advance the virtual addresses he wishes for huge pages in his application.

We found out that in some of the cases we don't know it in advance and propose a more generic solution which will solve the below issue without user interfering.

If user --base-virtaddr is not null (i.e user know the addresses he wants for the hugepages) our changes will be disabled and the code will act exactly as today without the patch.

Pls let me know if u have any more doubts.

Thx
Nissim

-----Original Message-----
From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com] 
Sent: Thursday, October 15, 2015 3:33 PM
To: Nissim Nisimov; dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

Hi

> Problem:
> In DPDK Primary/Secondary module we assume mapping same regions of 
> virtual memory addresses for Primary process and Secondary.
> An issue may occur when the Primary and secondary processes are not 
> symmetric in such way that the code is not the same (for example, 
> Primary process is a traffic distributer and secondary is a worker). 
> The result may be that specific virtual address region in the first 
> process won't be available in the second process.
> 
> Changes done at eal init:
> map all related rte configuration and uio sections close to the end of 
> huge pages memory (that mean rte_eal_memory_init() should be called 
> before
> rte_config_init() in primary process)
> According to our observations there will be more probability to 
> success when allocating rte_config and uio memzones after huge pages 
> sections (actually uio is already allocated after the huge pages area)

Not sure I understand the purpose of the patch. Doesn't --base-virtaddr flag solve your issues?

Thanks,
Anatoly