Thanks Muthurajan.

We were testing with core 0-7 to DPDK and 8-15 to Linux SIP processes. The core 
numbers are based on the Linux /etc/cpuinfo. These processes don't have direct 
coupling with DPDK. They may share some memory with the DPDK via IPC.

What was the reason that it is recommended to use the physical core only for 
DPDK? Based on your comment below, sounds like that restriction should be 
removed.


Thanks,
-Jane


-----Original Message-----
From: Jayakumar, Muthurajan [mailto:muthurajan.jayaku...@intel.com] 
Sent: Sunday, March 02, 2014 7:49 PM
To: Jane Shen; dev at dpdk.org
Subject: RE: Physical core vs. hyper threaded core

Jane, 
Great. You are correct. Have tried enabling hyperthreading and it works. 

For example, if we want to have the functionality partitioning such that Rx + 
Packet Processing + Tx = all of these three functions can be done in  2 cores  
- By positioning Rx in one lcore and by positioning Packet processing and Tx in 
the sibling hyperthread lcore of the same physical core, you get tight coupling 
because L1 cache and L2 cache are shared between the hyperthreaded cores 
belonging to same physical core.   

Curious to know - in your configuration, the SIP based signaling threads - 

Option A) are they sharing sibling of DPDK threads?

Option B) Or all DPDK threads are tightly coupled with sibling threads and SIP 
based signaling threads are on separate cores?

If  it is Option B) more tight coupling within the DPDK threads and less 
interference from signaling threads. 

Thanks, 


-----Original Message-----
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jane Shen
Sent: Sunday, March 02, 2014 4:56 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Physical core vs. hyper threaded core

Hi,

I understand that DPDK should use the physical core. But here is what we tested:

-          Enable HT

-          Assign 8 cores of the CPU (an 8-core Sandybridge CPU) to DPDK.

Surprisingly enough, we noticed that the remaining 8 cores (b/c there are total 
of 16 cores after HT) can still handle other Linux processes which are SIP 
based signaling transactions.

Anybody can shed some light on how this worked? Is there anybody tried similar 
thing? What has been your experience?

Thanks,
-Jane

Reply via email to