[dpdk-dev] Question on using SR-IOV with dpdk apps
It seems to have detected all 4. But I do see a MAC address not valid: ? ? (scrolled up) EAL: PCI device :04:10.1 on NUMA socket 0 ? EAL: probe driver: 8086:10ed rte_ixgbevf_pmd ? EAL: PCI memory mapped at 0x7fd39743e000 ? EAL: PCI memory mapped at 0x7fd39743a000 ? PMD:The MAC address is not valid. ? The most likely cause of this error is that the VM host? has not assigned a valid MAC address to this VF device.? Please consult the DPDK Release Notes (FAQ section) for? a possible solution to this problem. ? EAL: PCI device :04:10.2 on NUMA socket 0 ? EAL: probe driver: 8086:10ed rte_ixgbevf_pmd ? EAL: PCI memory mapped at 0x7fd397436000 ? EAL: PCI memory mapped at 0x7fd397432000 ? EAL: PCI device :04:10.3 on NUMA socket 0 ? EAL: probe driver: 8086:10ed rte_ixgbevf_pmd ? EAL: PCI memory mapped at 0x7fd39742e000 ? EAL: PCI memory mapped at 0x7fd39742a000 ? PMD:The MAC address is not valid. ? The most likely cause of this error is that the VM host? has not assigned a valid MAC address to this VF device.? Please consult the DPDK Release Notes (FAQ section) for? a possible solution to this problem. On 8/4/14 12:53 PM, "Richardson, Bruce" wrote: > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Anjali Kulkarni >> Sent: Monday, August 04, 2014 12:45 PM >> To: dev at dpdk.org >> Subject: Re: [dpdk-dev] Question on using SR-IOV with dpdk apps >> >> Forgot to clarify, this is a specialized app, and the first parameter of >> each () is the dpdk port no. >> >> On 8/4/14 12:43 PM, "Anjali Kulkarni" wrote: >> >> >Hi, >> > >> >I am using SR-IOV and pass through to run a DPDK app. I am running it >>on >> >host. SR-IOV should split the NIC into multiple Vfs. I have split each >>NIC >> >into 2 Vfs. However, when I run the DPDK app, I get error initializing >>the >> >port no.2 of DPDK. >> >I am running the app with these options: >> >--rx "(0,0,0,1),(1,0,2,1), (2,0,3,1), (3,0,4,1)" --tx "(0,1), (1,1), >> >(2,1), (3,1)" >> > >> >This is for 2 physical NICs, each having 2 Vfs. The error I get is: >> > >> >Initializing NIC port 0 ...| >> >|RPIOIF DETACHED >> >|Initializing NIC port 0 RX queue 0 ... | >> >| >> >|Initializing NIC port 0 TX queue 0 ... | >> >|HOSTIF DETACHED >> >|Initializing NIC port 1 ...| >> >| >> >|Initializing NIC port 1 RX queue 0 ... | >> >| >> >|Initializing NIC port 1 TX queue 0 ... | >> >| >> >|Initializing NIC port 2 ...| >> >| >> >|PANIC in app_init_nics(): | >> >| >> >|Cannot init NIC port 2 (-22) >> > >> > >> >Can someone pls clarify how DPDK views it's port nos, i.e. Scans the >> >devices and sees each nic? I see 4 /dev/uioX devices. I assume it scans >> >for these igb_uio devices. These are present. Then why can it not >>detect >> >the other 2 NICs? >> > >> >Thanks >> >Anjali >> > > >Hi, > >For debugging issues with PCI devices not being found, can you please >include the output from the EAL on startup, especially any messages >concerning the PCI bus scan being done. > >Regards, >/Bruce
[dpdk-dev] Question on using SR-IOV with dpdk apps
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Anjali Kulkarni > Sent: Monday, August 04, 2014 12:45 PM > To: dev at dpdk.org > Subject: Re: [dpdk-dev] Question on using SR-IOV with dpdk apps > > Forgot to clarify, this is a specialized app, and the first parameter of > each () is the dpdk port no. > > On 8/4/14 12:43 PM, "Anjali Kulkarni" wrote: > > >Hi, > > > >I am using SR-IOV and pass through to run a DPDK app. I am running it on > >host. SR-IOV should split the NIC into multiple Vfs. I have split each NIC > >into 2 Vfs. However, when I run the DPDK app, I get error initializing the > >port no.2 of DPDK. > >I am running the app with these options: > >--rx "(0,0,0,1),(1,0,2,1), (2,0,3,1), (3,0,4,1)" --tx "(0,1), (1,1), > >(2,1), (3,1)" > > > >This is for 2 physical NICs, each having 2 Vfs. The error I get is: > > > >Initializing NIC port 0 ...| > >|RPIOIF DETACHED > >|Initializing NIC port 0 RX queue 0 ... | > >| > >|Initializing NIC port 0 TX queue 0 ... | > >|HOSTIF DETACHED > >|Initializing NIC port 1 ...| > >| > >|Initializing NIC port 1 RX queue 0 ... | > >| > >|Initializing NIC port 1 TX queue 0 ... | > >| > >|Initializing NIC port 2 ...| > >| > >|PANIC in app_init_nics(): | > >| > >|Cannot init NIC port 2 (-22) > > > > > >Can someone pls clarify how DPDK views it's port nos, i.e. Scans the > >devices and sees each nic? I see 4 /dev/uioX devices. I assume it scans > >for these igb_uio devices. These are present. Then why can it not detect > >the other 2 NICs? > > > >Thanks > >Anjali > > Hi, For debugging issues with PCI devices not being found, can you please include the output from the EAL on startup, especially any messages concerning the PCI bus scan being done. Regards, /Bruce
[dpdk-dev] Question on using SR-IOV with dpdk apps
Hi, I am using SR-IOV and pass through to run a DPDK app. I am running it on host. SR-IOV should split the NIC into multiple Vfs. I have split each NIC into 2 Vfs. However, when I run the DPDK app, I get error initializing the port no.2 of DPDK. I am running the app with these options: --rx "(0,0,0,1),(1,0,2,1), (2,0,3,1), (3,0,4,1)" --tx "(0,1), (1,1), (2,1), (3,1)" This is for 2 physical NICs, each having 2 Vfs. The error I get is: Initializing NIC port 0 ...| |RPIOIF DETACHED |Initializing NIC port 0 RX queue 0 ... | | |Initializing NIC port 0 TX queue 0 ... | |HOSTIF DETACHED |Initializing NIC port 1 ...| | |Initializing NIC port 1 RX queue 0 ... | | |Initializing NIC port 1 TX queue 0 ... | | |Initializing NIC port 2 ...| | |PANIC in app_init_nics(): | | |Cannot init NIC port 2 (-22) Can someone pls clarify how DPDK views it's port nos, i.e. Scans the devices and sees each nic? I see 4 /dev/uioX devices. I assume it scans for these igb_uio devices. These are present. Then why can it not detect the other 2 NICs? Thanks Anjali
[dpdk-dev] [PATCH] acl: If build does not support sse4.2, emulate missing instructions with C code
The ACL library makes extensive use of some SSE4.2 instructions, which means the
default build can't compile this library. Work around the problem by testing
the __SSE42__ definition in the acl_vects.h file and defining the macros there
as intrinsics or c-level equivalants. Note this is a minimal patch, adjusting
only the definitions that are currently used in the ACL library.
Only compile tested so far, but I wanted to post it for early review so that
others could aid in unit testing.
Signed-off-by: Neil Horman
CC: Thomas Monjalon
CC: "Konstantin Ananyev"
CC: Bruce Richardson
---
lib/librte_acl/acl_bld.c | 3 +-
lib/librte_acl/acl_vect.h | 102 --
2 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/lib/librte_acl/acl_bld.c b/lib/librte_acl/acl_bld.c
index 873447b..de974a4 100644
--- a/lib/librte_acl/acl_bld.c
+++ b/lib/librte_acl/acl_bld.c
@@ -31,7 +31,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include
#include
#include "tb_mem.h"
#include "acl.h"
@@ -1481,7 +1480,7 @@ acl_calc_wildness(struct rte_acl_build_rule *head,
switch (rule->config->defs[n].type) {
case RTE_ACL_FIELD_TYPE_BITMASK:
wild = (size -
- _mm_popcnt_u32(fld->mask_range.u8)) /
+
__builtin_popcountl(fld->mask_range.u8)) /
size;
break;
diff --git a/lib/librte_acl/acl_vect.h b/lib/librte_acl/acl_vect.h
index d813600..e5f391b 100644
--- a/lib/librte_acl/acl_vect.h
+++ b/lib/librte_acl/acl_vect.h
@@ -34,6 +34,10 @@
#ifndef _RTE_ACL_VECT_H_
#define _RTE_ACL_VECT_H_
+#ifdef __SSE4_1__
+#include
+#endif
+
/**
* @file
*
@@ -44,12 +48,12 @@
extern "C" {
#endif
+
#defineMM_ADD16(a, b) _mm_add_epi16(a, b)
#defineMM_ADD32(a, b) _mm_add_epi32(a, b)
#defineMM_ALIGNR8(a, b, c) _mm_alignr_epi8(a, b, c)
#defineMM_AND(a, b)_mm_and_si128(a, b)
#define MM_ANDNOT(a, b)_mm_andnot_si128(a, b)
-#define MM_BLENDV8(a, b, c)_mm_blendv_epi8(a, b, c)
#define MM_CMPEQ16(a, b) _mm_cmpeq_epi16(a, b)
#define MM_CMPEQ32(a, b) _mm_cmpeq_epi32(a, b)
#defineMM_CMPEQ8(a, b) _mm_cmpeq_epi8(a, b)
@@ -59,7 +63,6 @@ extern "C" {
#defineMM_CVT32(a) _mm_cvtsi128_si32(a)
#define MM_CVTU32(a) _mm_cvtsi32_si128(a)
#defineMM_INSERT16(a, c, b)_mm_insert_epi16(a, c, b)
-#defineMM_INSERT32(a, c, b)_mm_insert_epi32(a, c, b)
#defineMM_LOAD(a) _mm_load_si128(a)
#defineMM_LOADH_PI(a, b) _mm_loadh_pi(a, b)
#defineMM_LOADU(a) _mm_loadu_si128(a)
@@ -82,7 +85,6 @@ extern "C" {
#defineMM_SRL32(a, b) _mm_srli_epi32(a, b)
#defineMM_STORE(a, b) _mm_store_si128(a, b)
#defineMM_STOREU(a, b) _mm_storeu_si128(a, b)
-#defineMM_TESTZ(a, b) _mm_testz_si128(a, b)
#defineMM_XOR(a, b)_mm_xor_si128(a, b)
#defineMM_SET16(a, b, c, d, e, f, g, h)\
@@ -93,6 +95,100 @@ extern "C" {
_mm_set_epi8(c0, c1, c2, c3, c4, c5, c6, c7,\
c8, c9, cA, cB, cC, cD, cE, cF)
+
+#ifndef __SSE4_1__
+static inline xmm_t pblendvb(xmm_t dst, xmm_t src, xmm_t mask)
+{
+ unsigned char tmpd[16], tmps[16], tmpm[16];
+ int i;
+
+ MM_STOREU((xmm_t *), dst);
+ MM_STOREU((xmm_t *), src);
+ MM_STOREU((xmm_t *), mask);
+
+ for (i = 0; i < 16; i++)
+ if (mask[i] & 0x8)
+ dst[i] = src[i];
+
+ dst = MM_LOADU((xmm_t *));
+
+ return dst;
+}
+
+#define MM_BLENDV8(a, b, c)pblendvb(a, b, c)
+
+
+static inline int ptestz(xmm_t a, xmm_t b)
+{
+ unsigned long long tmpa[2], tmpb[2];
+
+ MM_STOREU((xmm_t *), a);
+ MM_STOREU((xmm_t *), b);
+
+ if (tmpa[0] & tmpb[0])
+ return 1;
+ if (tmpa[1] & tmpb[1])
+ return 1;
+
+ return 0;
+}
+
+#defineMM_TESTZ(a, b) ptestz(a, b)
+
+static inline xmm_t pinsrd(xmm_t dst, int32_t val, char off)
+{
+ unsigned long long tmpa[2];
+ unsigned long long mask;
+ int32_t tmp;
+
+ MM_STOREU((xmm_t *), dst);
+
+ /*
+* Inserting a dword is a bit odd as it can cross a word boundary
+*/
+
+ if (off > 32) {
+ /*
+* If the offset is more than 32, then part of the
+* inserted word will appear in the upper half of the xmm
+* register. Grab the part of the value that crosses the 64
bit
+* boundary.
+*/
+ tmp = val >> (off - 32);
+
+ /*
+* Mask off the least
[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id
Hi, > Subject: Re: [dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master > lcore id > > 2014-07-23 08:53, Hiroshi Shimamoto: > > 2014-07-23 09:50, Thomas Monjalon: > > > 2014-07-22 23:40, Hiroshi Shimamoto: > > > > does anyone have interest in this functionality? > > > > > > > > I think this is important and useful. > > > > Since we should care about core assignment to get high performance > > > > and the master lcore thread is special in DPDK, we will want to > > > > assign the master to the target core. > > > > For example, with hyperthreading I'd like to make a pair of packet > > > > processing threads into one physical core and separate the master > > > > thread which does some management. > > > > > > Thank you for showing your interest. > > > Does it mean you carefully reviewed this patch? In this case, I'd > > > appreciate > > > a note "Reviewed-by:". > > > > Not yet deeply, wait a bit, we're testing this patch in our application. > > Will report if it works fine. Sorry a delay, I had confirmed the functionality. I'm fine to add Reviewed-by: Hiroshi Shimamoto thanks, Hiroshi > > > > By the way, we should add the same code into the BSD code, right? > > Right. > I'd prefer to reduce the duplicated footprint and have more common code > between BSD and Linux. But waiting this enhancement, we have to maintain > the duplicated code for BSD. > > -- > Thomas
