[dpdk-dev] Intel fortville not working with multi-segment

[Nissim Nisimov]

Hi Helin,

Any news regarding this issue? do u know if there is any related patch I can 
apply on my application in order to work with multi-segment packets?

Thanks,
Nissim

-Original Message-
From: Zhang, Helin [mailto:helin.zh...@intel.com] 
Sent: Tuesday, May 12, 2015 11:51 AM
To: Nissim Nisimov
Cc: 'dev at dpdk.org'
Subject: RE: Intel fortville not working with multi-segment

Hi Nissim

It seems that our validation guys here can reproduce it in our lab. I will 
check that soon later, and update you later.
Thank you very much for the good finding!

Regards,
Helin

> -Original Message-
> From: Nissim Nisimov [mailto:NissimN at Radware.com]
> Sent: Monday, May 11, 2015 11:44 AM
> To: Zhang, Helin
> Cc: 'dev at dpdk.org'
> Subject: RE: Intel fortville not working with multi-segment
> 
> Hi,
> 
> I am using PF pass-through and it doesn't work even with 2000 bytes of 
> server response page size.
> Looks like the first segment of each session is not received.
> 
> When i am changing the server response size to 1000 bytes, all works 
> as expected.
> 
> I am working with dpdk 1.8 version.
> 
> Any idea why ? Is it related to i40e multi segment support?
> 
> Thx
> Nissim
> 
> On May 11, 2015 5:03 AM, "Zhang, Helin" 
> wrote:
> >
> > Hi Nissim
> >
> > Are you using PF pass-through or VF pass-through?
> > For PF pass-through, you might have already gotten the fix.
> > For VF pass-through, there is
> 
> Hi Nissim
> 
> Are you using PF pass-through or VF pass-through?
> For PF pass-through, you might have already gotten the fix.
> For VF pass-through, there is a bug fix which is needed for supporting 
> jumbo frame and multiple mbuf.
> http://www.dpdk.org/dev/patchwork/patch/4641/
> 
> 
> Regards,
> Helin
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov
> > Sent: Monday, May 11, 2015 3:48 AM
> > To: Nissim Nisimov; 'dev at dpdk.org'
> > Subject: Re: [dpdk-dev] Intel fortville not working with 
> > multi-segment
> >
> > Hi,
> >
> > can someone assist regarding this issue?
> >
> > Is it a known limitation in i40e/dpdk (no support for multi-segment)?
> >
> > Thx
> > Nissim
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov
> > Sent: Thursday, May 07, 2015 5:44 PM
> > To: 'dev at dpdk.org'
> > Subject: [dpdk-dev] Intel fortville not working with multi-segment
> >
> > Hi,
> >
> >
> >
> > I am trying to work with Intel Fortville (XL710) NICs in Passthrough 
> > mode from a VM running dpdk app.
> >
> >
> > First I didn't have any TX traffic from the VM, I got dpdk patch for 
> > this issue and it fixed it.
> > (http://www.dpdk.org/dev/patchwork/patch/4588/)
> >
> > But now I see that when trying to run multi-segment traffic not all 
> > the packets reaching the VM (I tested it on bare metal as well and 
> > saw the same issue)
> >
> > Is it a known issue? any workaround for it?
> >
> > Thanks,
> > Nissim

[dpdk-dev] calling rte_eth_rx_queue_setup from secondary processes

[Nissim Nisimov]

Hi all,

I wonder if there is a possibility to call rte_eth_rx_queue_setup() from 
different processes (for different RSS queues off course)

For example, the code will look something like:


>From Process 1:

retval = rte_eth_rx_queue_setup(port_num, 0, rx_ring_size,

rte_eth_dev_socket_id(port_num), &rx_conf_default, dpdk_mp_handle);


from process 2:

retval = rte_eth_rx_queue_setup(port_num, 1, rx_ring_size,

rte_eth_dev_socket_id(port_num), &rx_conf_default, dpdk_mp_handle);




I know that rte_eth_rx_queue_setup() is not meant to work on secondary 
processes but my question is if there is a real reason for it. and if it can be 
changed so it will indeed work in such case

Thanks!
Nissim

[dpdk-dev] working with pthreads and Processes in parallel

[Nissim Nisimov]

Hi,

Is there any limit to work with dpdk within different pthreads in parallel to 
multi-process system

For example, I will have a system with one primary processes with 4 pthreads 
and in addition I will have another 4 secondary processes 

All of the above will call to dpdk APIs. Is it possible in today code?


Thx
Nissim

[dpdk-dev] running dpdk 2.1 on openstak causes CPU soft lockup

[Nissim Nisimov]

Yup this is exactly our issue.

We blacked list the specific interface and its working again.

Thx
Nissim

-Original Message-
From: Franck BAUDIN [mailto:franck.bau...@qosmos.com] 
Sent: Tuesday, December 01, 2015 2:20 PM
To: Nissim Nisimov; dev at dpdk.org
Subject: RE: running dpdk 2.1 on openstak causes CPU soft lockup

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov
> Sent: lundi 23 novembre 2015 20:44
> To: dev at dpdk.org
> Subject: [dpdk-dev] running dpdk 2.1 on openstak causes CPU soft 
> lockup
>
> Hi,
>
> I am running DPDK 2.1.0 based app on OpenStack KVM guest.  OS of guest 
> is Ubuntu LTS 14.04 3.13 kernel.
> virtio.
>
> After upgrade to dpdk 2.1 (previous version was dpdk 1.8 and it worked 
> fine) we are seeing the following issue:
>
> [960.004535] BUG: soft lockup - CPU#3 stuck for 23s! [ip:8419]
>
> The message will be printed in an endless loop and the system won't 
> recover.
>
> Is it a known issue in dpdk 2.1? any patch I can apply in order to 
> overcome this?
>
>
> Thx
> Nissim

Do you have virtIO interfaces in your guest, with at least one (usually the 
first one, used for cloud-init) used by the kernel? If so,  even if they are in 
use by the kernel, DPDK virtIO driver will attach to them (without detaching 
the kernel), leading to either kernel crash or infinite loops. Until DPDK 1.8.0 
included, you had to explicitly bind the virtIO interfaces, via igb_uio. But 
since DPDK 2.x, all non-blacklisted interfaces are bound.

Franck
This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized to use, copy this message and/or disclose the 
content to any other person. E-mails are susceptible to alteration. Neither 
Qosmos nor any of its subsidiaries or affiliates shall be liable for the 
message if altered, changed or falsified.

Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont 
confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous 
avez re?u ce message par erreur, merci d?en informer imm?diatement son ?metteur 
par courrier ?lectronique et d?effacer ce message de votre syst?me. Dans cette 
hypoth?se, vous n??tes pas autoris? ? utiliser, copier ce message et/ou en 
divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible 
d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre de 
ce message s'il a ?t? alt?r?, d?form? ou falsifi?.

[dpdk-dev] Queries on DPDK working with XL710 intel NIC

[Nissim Nisimov]

Hi all,

I am trying to work with intel XL710 40GIG NIC but for some reason when trying 
to load it via dpdk I am getting the following error:


EAL: PCI device :21:00.1 on NUMA socket 1
EAL:   probe driver: 8086:1583 rte_i40e_pmd
EAL:   PCI memory mapped at 0x7fff939f9000
EAL:   PCI memory mapped at 0x7fffd54b8000
EAL: Error - exiting with code: 1
  Cause: Requested device :21:00.1 cannot be used

It seems that the "problematic" functions is i40e_aq_get_firmware_version() in 
the following line:
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
(gdb) p status
$3 = I40E_ERR_ADMIN_QUEUE_TIMEOUT


I did read in another mail thread (attached below) that this might be a 
firmware issue so i upgraded my NIC firmware version to latest but still not 
able to get it work:

root at lagavulin:~# ethtool -i eth24
driver: i40e
version: 1.2.37
firmware-version: f4.33.31377 a1.2 n4.42 e1932
bus-info: :21:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes


any idea why I still see the issue?

thanks!
Nissim



Hi Yan



Please tell me what version of firmware are you using? If it is too old, please 
update to at least 4.2.6.

If it is still there, check that if your firmware updating is really 
successful. You can try to run linux kernel driver to have a double check.



Regards,

Helin



From: Yan Freedland [mailto:y...@radware.com]

Sent: Thursday, March 19, 2015 12:28 AM

To: Zhang, Helin

Cc: dev at dpdk.org

Subject: [dpdk-dev] i40e_aq_get_firmware_version failure



Hi,



I am trying to start DPDK with 40G Intel NIC and get a failure at 
initialization stage in i40e_aq_get_firmware_version(). For some reason this 
function reaches TIMEOUT for more than maximum allowed times (10 times). In the 
note below I understand that several failures may be considerable but not as 
many as I have.



Should I enlarge the retries number ?

Is it a HW issue ?



Anyone who faced it or may assist please comment.



Thanks,

Yan

[dpdk-dev] Queries on DPDK working with XL710 intel NIC

[Nissim Nisimov]

Seems like the issue related to the following errors I see in dmesg:

[48459.391753] dmar: DRHD: handling fault status reg 302
[48459.392092] dmar: DMAR:[DMA Read] Request device [21:00.1] fault addr 
fbaddd000 
[48459.392092] DMAR:[fault reason 06] PTE Read access is not set

I am running on HP ProLiant DL380p Gen8. Ubuntu 3.11.0-26-generic



Is anyone encounter this kind of issue with Intel XL710 NICs (Fortville)?

Thx
Nissim

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nissim Nisimov
Sent: Thursday, March 19, 2015 7:58 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Queries on DPDK working with XL710 intel NIC

Hi all,

I am trying to work with intel XL710 40GIG NIC but for some reason when trying 
to load it via dpdk I am getting the following error:


EAL: PCI device :21:00.1 on NUMA socket 1
EAL:   probe driver: 8086:1583 rte_i40e_pmd
EAL:   PCI memory mapped at 0x7fff939f9000
EAL:   PCI memory mapped at 0x7fffd54b8000
EAL: Error - exiting with code: 1
  Cause: Requested device :21:00.1 cannot be used

It seems that the "problematic" functions is i40e_aq_get_firmware_version() in 
the following line:
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
(gdb) p status
$3 = I40E_ERR_ADMIN_QUEUE_TIMEOUT


I did read in another mail thread (attached below) that this might be a 
firmware issue so i upgraded my NIC firmware version to latest but still not 
able to get it work:

root at lagavulin:~# ethtool -i eth24
driver: i40e
version: 1.2.37
firmware-version: f4.33.31377 a1.2 n4.42 e1932
bus-info: :21:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes


any idea why I still see the issue?

thanks!
Nissim



Hi Yan



Please tell me what version of firmware are you using? If it is too old, please 
update to at least 4.2.6.

If it is still there, check that if your firmware updating is really 
successful. You can try to run linux kernel driver to have a double check.



Regards,

Helin



From: Yan Freedland [mailto:y...@radware.com<http://dpdk.org/ml/listinfo/dev>]

Sent: Thursday, March 19, 2015 12:28 AM

To: Zhang, Helin

Cc: dev at dpdk.org<http://dpdk.org/ml/listinfo/dev>

Subject: [dpdk-dev] i40e_aq_get_firmware_version failure



Hi,



I am trying to start DPDK with 40G Intel NIC and get a failure at 
initialization stage in i40e_aq_get_firmware_version(). For some reason this 
function reaches TIMEOUT for more than maximum allowed times (10 times). In the 
note below I understand that several failures may be considerable but not as 
many as I have.



Should I enlarge the retries number ?

Is it a HW issue ?



Anyone who faced it or may assist please comment.



Thanks,

Yan

[dpdk-dev] Intel fortville not working with multi-segment

[Nissim Nisimov]

Hi,



I am trying to work with Intel Fortville (XL710) NICs in Passthrough mode from 
a VM running dpdk app.


First I didn't have any TX traffic from the VM, I got dpdk patch for this issue 
and it fixed it. (http://www.dpdk.org/dev/patchwork/patch/4588/)

But now I see that when trying to run multi-segment traffic not all the packets 
reaching the VM (I tested it on bare metal as well and saw the same issue)

I don't have support for TSO in my application. Do I need to turn the TSO for 
the NIC?

Is it a known issue? any workaround for it?

Thanks,
Nissim

[dpdk-dev] Intel fortville not working with multi-segment

[Nissim Nisimov]

Hi,

can someone assist regarding this issue?

Is it a known limitation in i40e/dpdk (no support for multi-segment)?

Thx
Nissim

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nissim Nisimov
Sent: Thursday, May 07, 2015 5:44 PM
To: 'dev at dpdk.org'
Subject: [dpdk-dev] Intel fortville not working with multi-segment

Hi,



I am trying to work with Intel Fortville (XL710) NICs in Passthrough mode from 
a VM running dpdk app.


First I didn't have any TX traffic from the VM, I got dpdk patch for this issue 
and it fixed it. (http://www.dpdk.org/dev/patchwork/patch/4588/)

But now I see that when trying to run multi-segment traffic not all the packets 
reaching the VM (I tested it on bare metal as well and saw the same issue)

Is it a known issue? any workaround for it?

Thanks,
Nissim

[dpdk-dev] Intel fortville not working with multi-segment

[Nissim Nisimov]

Hi,

I am using PF pass-through and it doesn't work even with 2000 bytes of server 
response page size.
Looks like the first segment of each session is not received.

When i am changing the server response size to 1000 bytes, all works as 
expected.

I am working with dpdk 1.8 version.

Any idea why ? Is it related to i40e multi segment support?

Thx
Nissim

On May 11, 2015 5:03 AM, "Zhang, Helin"  wrote:
>
> Hi Nissim
>
> Are you using PF pass-through or VF pass-through?
> For PF pass-through, you might have already gotten the fix.
> For VF pass-through, there is

Hi Nissim

Are you using PF pass-through or VF pass-through?
For PF pass-through, you might have already gotten the fix.
For VF pass-through, there is a bug fix which is needed for supporting jumbo 
frame and multiple mbuf. http://www.dpdk.org/dev/patchwork/patch/4641/


Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov
> Sent: Monday, May 11, 2015 3:48 AM
> To: Nissim Nisimov; 'dev at dpdk.org'
> Subject: Re: [dpdk-dev] Intel fortville not working with multi-segment
>
> Hi,
>
> can someone assist regarding this issue?
>
> Is it a known limitation in i40e/dpdk (no support for multi-segment)?
>
> Thx
> Nissim
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov
> Sent: Thursday, May 07, 2015 5:44 PM
> To: 'dev at dpdk.org'
> Subject: [dpdk-dev] Intel fortville not working with multi-segment
>
> Hi,
>
>
>
> I am trying to work with Intel Fortville (XL710) NICs in Passthrough mode
> from a VM running dpdk app.
>
>
> First I didn't have any TX traffic from the VM, I got dpdk patch for this 
> issue
> and it fixed it. (http://www.dpdk.org/dev/patchwork/patch/4588/)
>
> But now I see that when trying to run multi-segment traffic not all the
> packets reaching the VM (I tested it on bare metal as well and saw the
> same issue)
>
> Is it a known issue? any workaround for it?
>
> Thanks,
> Nissim

[dpdk-dev] propose a solution for mapping same virtual address space to asymmetric processes

[Nissim Nisimov]

Hi all,

The below will try to suggest a modification to the initialization of 
Environment Abstraction Layer (AKA EAL) so it will be able to allocate memory 
zones from same virtual memory addresses even if the primary process is not 
similar to the secondary processes.

Problem:
The DPDK Primary/Secondary model requires that the exact same hugepage memory 
mappings be present in all applications.
An issue may occur when the Primary and secondary processes are not symmetric 
in such way that the code has big differences (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.


Suggested solution:
Map all related rte and uio sections somewhere 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 the above sections after huge pages section (actually uio is already 
allocated after the huge pages area)

It solved our problem when trying to work with a primary traffic distributer 
which is a very "light" process and few secondary worker processes.


Please share your thoughts on this before I will try to commit our patch for 
review

Thanks,
Nissim

[dpdk-dev] propose a solution for mapping same virtual address space to asymmetric processes

[Nissim Nisimov]

Hi Bruce,

Using "--base-virtaddr" requires knowledge on the huge pages wanted address 
going to be used and might vary on different uses of the application.

We suggest a more generic solution which wont require any previous knowledge 
and will be "bullet proof" as much as possible.

Regards,
Nissim

On Oct 13, 2015 18:49, "Richardson, Bruce"  
wrote:


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov
> Sent: Tuesday, October 13, 2015 4:40 PM
> To: 'dev at dpdk.org'
> Subject: [dpdk-dev] propose a solution for mapping same virtual address
> space to asymmetric processes
>
> Hi all,
>
> The below will try to suggest a modification to the initialization of
> Environment Abstraction Layer (AKA EAL) so it will be able to allocate
> memory zones from same virtual memory addresses even if the primary
> process is not similar to the secondary processes.
>
> Problem:
> The DPDK Primary/Secondary model requires that the exact same hugepage
> memory mappings be present in all applications.
> An issue may occur when the Primary and secondary processes are not
> symmetric in such way that the code has big differences (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.
>
>
> Suggested solution:
> Map all related rte and uio sections somewhere 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 the above sections
> after huge pages section (actually uio is already allocated after the huge
> pages area)
>
> It solved our problem when trying to work with a primary traffic
> distributer which is a very "light" process and few secondary worker
> processes.
>
>
> Please share your thoughts on this before I will try to commit our patch
> for review
>
> Thanks,
> Nissim

Hi,

out of interest, have you tried fixing the issue using the "--base-virtaddr" 
EAL flag to hint a base address to the primary process? It was put into the 
code some time ago to help solve exactly this problem.

/Bruce

[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 
---
 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_trte_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{
+ 

[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.bura...@intel.com] 
Sent: Thursday, October 15, 2015 3:33 PM
To: Nissim Nisimov; dev at 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

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

[Nissim Nisimov]

* this patch removes unnecessary call to rte_eal_memory_init() introduced in 
the first version.

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 
---
 lib/librte_eal/linuxapp/eal/eal.c | 28 +---
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 10 +++---
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 33e1067..f85eb63 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_trte_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,9 +804,12 @@ 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)
-   rte_panic("Cannot init memory\n");
+/* 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");
+   }

/* the directories are locked during eal_hugepage_info_init */
eal_hugedirs_unlock();
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_

[dpdk-dev] Intel fortville not working with multi-segment

[Nissim Nisimov]

Thx!

We will check it in our code

Nissim

-Original Message-
From: Zhang, Helin [mailto:helin.zh...@intel.com] 
Sent: Wednesday, May 27, 2015 6:54 AM
To: Nissim Nisimov
Cc: 'dev at dpdk.org'
Subject: RE: Intel fortville not working with multi-segment

Hi Nissim

Sorry for late reply!
Today I got a ready environment, and tried the latest DPDK code (on master 
branch) on my environment, it works well.
So could you help to try the latest code (R2.0 +) on your environment again, to 
see if the issue is still there or not?

Regards,
Helin

> -Original Message-
> From: Zhang, Helin
> Sent: Tuesday, May 12, 2015 4:51 PM
> To: Nissim Nisimov
> Cc: 'dev at dpdk.org'
> Subject: RE: Intel fortville not working with multi-segment
> 
> Hi Nissim
> 
> It seems that our validation guys here can reproduce it in our lab. I 
> will check that soon later, and update you later.
> Thank you very much for the good finding!
> 
> Regards,
> Helin
> 
> > -Original Message-
> > From: Nissim Nisimov [mailto:NissimN at Radware.com]
> > Sent: Monday, May 11, 2015 11:44 AM
> > To: Zhang, Helin
> > Cc: 'dev at dpdk.org'
> > Subject: RE: Intel fortville not working with multi-segment
> >
> > Hi,
> >
> > I am using PF pass-through and it doesn't work even with 2000 bytes 
> > of server response page size.
> > Looks like the first segment of each session is not received.
> >
> > When i am changing the server response size to 1000 bytes, all works 
> > as expected.
> >
> > I am working with dpdk 1.8 version.
> >
> > Any idea why ? Is it related to i40e multi segment support?
> >
> > Thx
> > Nissim
> >
> > On May 11, 2015 5:03 AM, "Zhang, Helin" 
> > wrote:
> > >
> > > Hi Nissim
> > >
> > > Are you using PF pass-through or VF pass-through?
> > > For PF pass-through, you might have already gotten the fix.
> > > For VF pass-through, there is
> >
> > Hi Nissim
> >
> > Are you using PF pass-through or VF pass-through?
> > For PF pass-through, you might have already gotten the fix.
> > For VF pass-through, there is a bug fix which is needed for 
> > supporting jumbo frame and multiple mbuf.
> > http://www.dpdk.org/dev/patchwork/patch/4641/
> >
> >
> > Regards,
> > Helin
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim
> Nisimov
> > > Sent: Monday, May 11, 2015 3:48 AM
> > > To: Nissim Nisimov; 'dev at dpdk.org'
> > > Subject: Re: [dpdk-dev] Intel fortville not working with 
> > > multi-segment
> > >
> > > Hi,
> > >
> > > can someone assist regarding this issue?
> > >
> > > Is it a known limitation in i40e/dpdk (no support for multi-segment)?
> > >
> > > Thx
> > > Nissim
> > >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim
> Nisimov
> > > Sent: Thursday, May 07, 2015 5:44 PM
> > > To: 'dev at dpdk.org'
> > > Subject: [dpdk-dev] Intel fortville not working with multi-segment
> > >
> > > Hi,
> > >
> > >
> > >
> > > I am trying to work with Intel Fortville (XL710) NICs in 
> > > Passthrough mode from a VM running dpdk app.
> > >
> > >
> > > First I didn't have any TX traffic from the VM, I got dpdk patch 
> > > for this issue and it fixed it.
> > > (http://www.dpdk.org/dev/patchwork/patch/4588/)
> > >
> > > But now I see that when trying to run multi-segment traffic not 
> > > all the packets reaching the VM (I tested it on bare metal as well 
> > > and saw the same issue)
> > >
> > > Is it a known issue? any workaround for it?
> > >
> > > Thanks,
> > > Nissim

[dpdk-dev] max MEMZONEs allowed

[Nissim Nisimov]

Hi all,

We are working on a system which requires allocating a big number of mem zones.

We are now reaching the max limit of MEMZONEs allowed (RTE_MAX_MEMZONE). 

I see today dpdk limit the above number to 2560. 
Is there any specific reason for that? can I increase it in case needed. What 
may be the side effects of such changes?


Thx
Nissim

[dpdk-dev] running dpdk 2.1 on openstak causes CPU soft lockup

[Nissim Nisimov]

Hi,

I am running DPDK 2.1.0 based app on OpenStack KVM guest.  OS of guest is 
Ubuntu LTS 14.04 3.13 kernel.
virtio.

After upgrade to dpdk 2.1 (previous version was dpdk 1.8 and it worked fine) we 
are seeing the following issue:

[960.004535] BUG: soft lockup - CPU#3 stuck for 23s! [ip:8419]

The message will be printed in an endless loop and the system won't recover.

Is it a known issue in dpdk 2.1? any patch I can apply in order to overcome 
this?


Thx
Nissim

[dpdk-dev] TSO support for Virtio_pmd

[Nissim Nisimov]

Hi all,

I see some additions in dpdk 16.04 to support TSO for vhost-user dpdk driver 
with vanilla linux virtio VM.

Does dpdk Virtio driver support TSO with the current code? if not, is there any 
plan to support it in the future?

Thanks,
Nissim