[dpdk-dev] Issues on FDIR and multi-processes

[dpdk-dev] Issues on FDIR and multi-processes

[Mauro Annarumma]

Hi everyone,
we are working with Flow DIRector on a multiprocess application. This application consists of N secondary processes, each one receiving packets directly from its own queue on the NIC. It works fine when each secondary process runs on a different CPU core; instead, if we try to run two secondary processes on the same CPU core, these processes aren't able to read from their respectively queue.

Moreover we observe that one process initially receives same packet; then all the processes no longer receive anything.

Do you have any suggestion about these strange behaviour? Is it a DPDK limitation or a FDIR limitation?

Best regards.

Mauro
 		 	   		  

Re: [dpdk-dev] Issues on FDIR and multi-processes

[Richardson, Bruce]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Mauro Annarumma
> Sent: Wednesday, April 02, 2014 4:02 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] Issues on FDIR and multi-processes
> 
> Hi everyone,
> we are working with Flow DIRector on a multiprocess application. This application consists of N secondary processes, 
> each one receiving packets directly from its own queue on the NIC. It works fine when each secondary process runs on
> a different CPU core; instead, if we try to run two secondary processes on the same CPU core, these processes aren't 
> able to read from their respectively queue.

Running two co-operating Intel DPDK processes on the same lcore is not a supported configuration of Intel DPDK multiprocess. [Please see section 20.3 of the Intel DPDK Programmer's Guide document, which lists out some limitations of multi-process support]. Basically, each process in a multiprocess configuration is equivalent to a thread in a normal application deployment, so just as having two threads on the same core causes problems with mempools and other objects which use an "lcore_id" value unique in each thread to work correctly, so running two processes on the same lcore can cause exactly the same issues. 
If you really do want to use this model and have multiple threads on the same lcore, at minimum you need to ensure that each thread/process has a unique lcore_id value <= RTE_MAX_LCORE.

/Bruce

[dpdk-dev] FW: Issues on FDIR and multi-processes

[Mauro Annarumma]

Hi Bruce,
thanks for the reply; I'm trying to do what you suggest, in particular I set the value of the lcore_id variable with this instruction:

RTE_PER_LCORE(_lcore_id) = temp_lcore_id;

where temp_lcore_id is a unique id strictly less then RTE_MAX_LCORE; the instruction is placed just after the "rte_eal_init" call in my main function.

   I still have the same problem whit the secondary processes. Do you think there could be other issues with the secondary-processes on the some core? Did I do something wrong   in the _lcore_id setting?
Regards.

Mauro 


> From: bruce.richardson@intel.com
> To: mauroannarumma@hotmail.it; dev@dpdk.org
> Subject: RE: [dpdk-dev] Issues on FDIR and multi-processes
> Date: Wed, 2 Apr 2014 15:33:09 +0000
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Mauro Annarumma
> > Sent: Wednesday, April 02, 2014 4:02 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] Issues on FDIR and multi-processes
> > 
> > Hi everyone,
> > we are working with Flow DIRector on a multiprocess application. This application consists of N secondary processes, 
> > each one receiving packets directly from its own queue on the NIC. It works fine when each secondary process runs on
> > a different CPU core; instead, if we try to run two secondary processes on the same CPU core, these processes aren't 
> > able to read from their respectively queue.
> 
> Running two co-operating Intel DPDK processes on the same lcore is not a supported configuration of Intel DPDK multiprocess. [Please see section 20.3 of the Intel DPDK Programmer's Guide document, which lists out some limitations of multi-process support]. Basically, each process in a multiprocess configuration is equivalent to a thread in a normal application deployment, so just as having two threads on the same core causes problems with mempools and other objects which use an "lcore_id" value unique in each thread to work correctly, so running two processes on the same lcore can cause exactly the same issues. 
> If you really do want to use this model and have multiple threads on the same lcore, at minimum you need to ensure that each thread/process has a unique lcore_id value <= RTE_MAX_LCORE.
> 
> /Bruce