[dpdk-dev] Using flow director to distrbute vlan traffic

[Viswanath Alikonda]

Hi,

I am using DPDK 1.4 and trying to distribute traffic based on (IP,vlan). I 
expect the traffic of (IP,vlan) goes to one core. The code looks like this:

struct   rte_fdir_masks fdir_masks;
struct   rte_fdir_filter fdir_filter;

memset(_masks, 0, sizeof(struct rte_fdir_masks));
fdir_masks.src_ipv4_mask = HHIP_MASK;
memset(_filter, 0, sizeof(struct rte_fdir_filter));
fdir_filter.iptype = RTE_FDIR_IPTYPE_IPV4;
fdir_masks.only_ip_flow  = 0;
rte_eth_dev_fdir_set_masks(port, _masks);
fdir_filter.l4type = RTE_FDIR_L4TYPE_NONE;
fdir_filter.ip_src.ipv4_addr = map[i].hh_lan_ip;
fdir_filter.vlan_id = map[i].vlan_id;
err = rte_eth_dev_fdir_add_signature_filter(port, _filter, 1 + 
map[i].core);

In DPDK 1.4, the vlan is stripped while filtering itself. But, I am unable to 
distribute it to the particular core. Can anyone through some light on this.

Thanks & Regards,
Viswanath

[dpdk-dev] [memnic PATCH 4/5] pmd: account statistics

[Thomas Monjalon]

11/03/2014 05:39, Hiroshi Shimamoto:
> From: Hiroshi Shimamoto 
> 
> Implement packet accounting of MEMNIC on TX/RX.
> 
> Signed-off-by: Hiroshi Shimamoto 
> Reviewed-by: Hayato Momma 

Acked and applied.

Thank you
-- 
Thomas

[dpdk-dev] [PATCH v5] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Neil Horman]

Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.

However, the code is really way more complex than it needs to be.  For
one thing, the CPUID instruction only needs %eax (leaf) and %ecx
(subleaf) as parameters, and since we are testing for bits, we might
as well list the bits explicitly.  Furthermore, we can use an array
rather than doing a switch statement inside a structure.

Reported-by: Neil Horman 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Neil Horman 

---
Change notes:
v2) Corrected build errors
Fixed cpuid_register_t reference passing
Fixed typedef name typo

v3)
* Modified feature_entry struct to drop the name field, as its unused
* Modified cpu_feature_table to use C99 initalizers
* Updated FEAT_DEF macro to include all feature_entry fields
* Modified cpuid_reg enum to start at 1 rather than zero
* Added CPUID_REG macro to drop enum value by 1 during access
* Added check on feat->reg use to detect missing entries
* Fixed a bug in rte_cpu_check_supported in which negative errors are ignored

v4)
* Fixed sanity checks to not offset feat->reg and just check !feat->reg
* Added a check for the sanity of the leaf node

v5)
* Fixed max leaf check to just return not supported rather than error
---
 lib/librte_eal/common/eal_common_cpuflags.c | 281 ++--
 1 file changed, 136 insertions(+), 145 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_cpuflags.c 
b/lib/librte_eal/common/eal_common_cpuflags.c
index 1ebf78c..f9c1840 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -59,16 +59,7 @@ enum cpu_register_t {
REG_EDX,
 };

-/**
- * Parameters for CPUID instruction
- */
-struct cpuid_parameters_t {
-   uint32_t eax;
-   uint32_t ebx;
-   uint32_t ecx;
-   uint32_t edx;
-   enum cpu_register_t return_register;
-};
+typedef uint32_t cpuid_registers_t[4];

 #define CPU_FLAG_NAME_MAX_LEN 64

@@ -76,109 +67,111 @@ struct cpuid_parameters_t {
  * Struct to hold a processor feature entry
  */
 struct feature_entry {
-   enum rte_cpu_flag_t feature;/**< feature name */
+   uint32_t leaf;  /**< cpuid leaf */
+   uint32_t subleaf;   /**< cpuid subleaf */
+   uint32_t reg;   /**< cpuid register */
+   uint32_t bit;   /**< cpuid register bit */
char name[CPU_FLAG_NAME_MAX_LEN];   /**< String for printing */
-   struct cpuid_parameters_t params;   /**< cpuid parameters */
-   uint32_t feature_mask;  /**< bitmask for feature */
 };

-#define FEAT_DEF(f) RTE_CPUFLAG_##f, #f
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+   [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },

 /**
  * An array that holds feature entries
  */
 static const struct feature_entry cpu_feature_table[] = {
-   {FEAT_DEF(SSE3),  {0x1, 0, 0, 0, REG_ECX}, 0x0001},
-   {FEAT_DEF(PCLMULQDQ), {0x1, 0, 0, 0, REG_ECX}, 0x0002},
-   {FEAT_DEF(DTES64),{0x1, 0, 0, 0, REG_ECX}, 0x0004},
-   {FEAT_DEF(MONITOR),   {0x1, 0, 0, 0, REG_ECX}, 0x0008},
-   {FEAT_DEF(DS_CPL),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
-   {FEAT_DEF(VMX),   {0x1, 0, 0, 0, REG_ECX}, 0x0020},
-   {FEAT_DEF(SMX),   {0x1, 0, 0, 0, REG_ECX}, 0x0040},
-   {FEAT_DEF(EIST),  {0x1, 0, 0, 0, REG_ECX}, 0x0080},
-   {FEAT_DEF(TM2),   {0x1, 0, 0, 0, REG_ECX}, 0x0100},
-   {FEAT_DEF(SSSE3), {0x1, 0, 0, 0, REG_ECX}, 0x0200},
-   {FEAT_DEF(CNXT_ID),   {0x1, 0, 0, 0, REG_ECX}, 0x0400},
-   {FEAT_DEF(FMA),   {0x1, 0, 0, 0, REG_ECX}, 0x1000},
-   {FEAT_DEF(CMPXCHG16B),{0x1, 0, 0, 0, REG_ECX}, 0x2000},
-   {FEAT_DEF(XTPR),  {0x1, 0, 0, 0, REG_ECX}, 0x4000},
-   {FEAT_DEF(PDCM),  {0x1, 0, 0, 0, REG_ECX}, 0x8000},
-   {FEAT_DEF(PCID),  {0x1, 0, 0, 0, REG_ECX}, 0x0002},
-   {FEAT_DEF(DCA),   {0x1, 0, 0, 0, REG_ECX}, 0x0004},
-   {FEAT_DEF(SSE4_1),{0x1, 0, 0, 0, REG_ECX}, 0x0008},
-   {FEAT_DEF(SSE4_2),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
-   {FEAT_DEF(X2APIC),{0x1, 0, 0, 0, REG_ECX}, 0x0020},
-   {FEAT_DEF(MOVBE), {0x1, 0, 0, 0, REG_ECX}, 0x0040},
-   {FEAT_DEF(POPCNT),{0x1, 0, 0, 0, REG_ECX}, 0x0080},
-   {FEAT_DEF(TSC_DEADLINE),  {0x1, 0, 0, 0, REG_ECX}, 0x0100},
-   {FEAT_DEF(AES),   {0x1, 0, 0, 0, REG_ECX}, 0x0200},
-   {FEAT_DEF(XSAVE), {0x1, 0, 0, 0, REG_ECX}, 0x0400},
-   {FEAT_DEF(OSXSAVE),   

[dpdk-dev] FreeBSD and NICs

[Fred Pedrisa]

Hi,



I have these settings in /boot/loader.conf



hw.contigmem.num_buffers=2

hw.contigmem.buffer_size=1073741824

hw.nic_uio.bdfs="3:0:0,3:0:1,4:0:0,4:0:1"

contigmem_load="YES"

nic_uio_load="YES"



However, the DPDK is taking all the available NIC Ports (8) from my system,
when I wanted it to use just 4 of them.



nic_uio0:  port 0xd020-0xd03f mem
0xf7e2-0xf7e3,0xf7c0-0xf7df,0xf7e44000-0xf7e47fff irq 18 at
device 0.0 on pci3

nic_uio1:  port 0xd000-0xd01f mem
0xf7e0-0xf7e1,0xf7a0-0xf7bf,0xf7e4-0xf7e43fff irq 19 at
device 0.1 on pci3

nic_uio2:  port 0xc020-0xc03f mem
0xf782-0xf783,0xf760-0xf77f,0xf7844000-0xf7847fff irq 16 at
device 0.0 on pci4

nic_uio3:  port 0xc000-0xc01f mem
0xf780-0xf781,0xf740-0xf75f,0xf784-0xf7843fff irq 17 at
device 0.1 on pci4

nic_uio4:  port 0xb020-0xb03f mem
0xf722-0xf723,0xf700-0xf71f,0xf7244000-0xf7247fff irq 18 at
device 0.0 on pci7

nic_uio5:  port 0xb000-0xb01f mem
0xf720-0xf721,0xf6e0-0xf6ff,0xf724-0xf7243fff irq 19 at
device 0.1 on pci7

nic_uio6:  port 0xa020-0xa03f mem
0xf6c2-0xf6c3,0xf6a0-0xf6bf,0xf6c44000-0xf6c47fff irq 16 at
device 0.0 on pci8

nic_uio7:  port 0xa000-0xa01f mem
0xf6c0-0xf6c1,0xf680-0xf69f,0xf6c4-0xf6c43fff irq 17 at
device 0.1 on pci8

dev.nic_uio.0.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.0.%driver: nic_uio

dev.nic_uio.0.%location: slot=0 function=0

dev.nic_uio.0.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.0.%parent: pci3

dev.nic_uio.1.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.1.%driver: nic_uio

dev.nic_uio.1.%location: slot=0 function=1

dev.nic_uio.1.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.1.%parent: pci3

dev.nic_uio.2.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.2.%driver: nic_uio

dev.nic_uio.2.%location: slot=0 function=0

dev.nic_uio.2.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.2.%parent: pci4

dev.nic_uio.3.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.3.%driver: nic_uio

dev.nic_uio.3.%location: slot=0 function=1

dev.nic_uio.3.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.3.%parent: pci4

dev.nic_uio.4.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.4.%driver: nic_uio

dev.nic_uio.4.%location: slot=0 function=0

dev.nic_uio.4.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.4.%parent: pci7

dev.nic_uio.5.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.5.%driver: nic_uio

dev.nic_uio.5.%location: slot=0 function=1

dev.nic_uio.5.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.5.%parent: pci7

dev.nic_uio.6.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.6.%driver: nic_uio

dev.nic_uio.6.%location: slot=0 function=0

dev.nic_uio.6.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.6.%parent: pci8

dev.nic_uio.7.%desc: Intel(R) DPDK PCI Device

dev.nic_uio.7.%driver: nic_uio

dev.nic_uio.7.%location: slot=0 function=1

dev.nic_uio.7.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086
subdevice=0x145a class=0x02

dev.nic_uio.7.%parent: pci8



What am I doing wrong in this case ?



I noticed that if we use : sysctl -a the variable : hw.nic_uio.bdfs is not
present there, is this some red flag ?



Sincerely,



Fred

[dpdk-dev] Using flow director to distrbute vlan traffic

[Richardson, Bruce]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Viswanath Alikonda
> Sent: Tuesday, March 25, 2014 11:55 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Using flow director to distrbute vlan traffic
> 
> Hi,
> 
> I am using DPDK 1.4 and trying to distribute traffic based on (IP,vlan). I 
> expect the traffic of (IP,vlan) goes to one core. The code looks like this:

Can't know for sure what the specific issue is in this case, but a general 
point to watch out for with the flow director APIs is byte ordering - check 
that the parameters are specified in network byte order where appropriate, e.g. 
vlan tag. [See cmd_pkt_filter_parsed()  function inside the testpmd app to see 
how the parameters to the flow director filter need to be set.]

/Bruce

[dpdk-dev] [PATCH v5] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[H. Peter Anvin]

On 03/25/2014 12:52 PM, Neil Horman wrote:
> Neil Horman reported that on x86-64 the upper half of %rbx would get
> clobbered when the code was compiled PIC or PIE, because the
> i386-specific code to preserve %ebx was incorrectly compiled.
> 
> However, the code is really way more complex than it needs to be.  For
> one thing, the CPUID instruction only needs %eax (leaf) and %ecx
> (subleaf) as parameters, and since we are testing for bits, we might
> as well list the bits explicitly.  Furthermore, we can use an array
> rather than doing a switch statement inside a structure.
> 
> Reported-by: Neil Horman 
> Signed-off-by: H. Peter Anvin 
> Signed-off-by: Neil Horman 
> 

Looks good to me.

Reviewed-by: H. Peter Anvin 

-hpa

[dpdk-dev] Choosing NIC Ports to be used

[Fred Pedrisa]

Hi,



I've added : hw.nic_uio.bdfs="3:0:0,3:0:1,4:0:0,4:0:1" to my
/boot/loader.conf in FreeBSD



However, once the nic_uio is loaded, it takes all the ports to itself, how
can I solve this ?

[dpdk-dev] [PATCH v4] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Neil Horman]

Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.

However, the code is really way more complex than it needs to be.  For
one thing, the CPUID instruction only needs %eax (leaf) and %ecx
(subleaf) as parameters, and since we are testing for bits, we might
as well list the bits explicitly.  Furthermore, we can use an array
rather than doing a switch statement inside a structure.

Reported-by: Neil Horman 
Signed-off-by: H. Peter Anvin 

---
Change notes:
v2) Corrected build errors
Fixed cpuid_register_t reference passing
Fixed typedef name typo

v3)
* Modified feature_entry struct to drop the name field, as its unused
* Modified cpu_feature_table to use C99 initalizers
* Updated FEAT_DEF macro to include all feature_entry fields
* Modified cpuid_reg enum to start at 1 rather than zero
* Added CPUID_REG macro to drop enum value by 1 during access
* Added check on feat->reg use to detect missing entries
* Fixed a bug in rte_cpu_check_supported in which negative errors are ignored

v4)
* Fixed sanity checks to not offset feat->reg and just check !feat->reg
* Added a check for the sanity of the leaf node
---
 lib/librte_eal/common/eal_common_cpuflags.c | 287 ++--
 1 file changed, 141 insertions(+), 146 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_cpuflags.c 
b/lib/librte_eal/common/eal_common_cpuflags.c
index 1ebf78c..b61e271 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -54,21 +54,12 @@
  */
 enum cpu_register_t {
REG_EAX = 0,
-   REG_EBX,
REG_ECX,
REG_EDX,
+   REG_EBX,
 };

-/**
- * Parameters for CPUID instruction
- */
-struct cpuid_parameters_t {
-   uint32_t eax;
-   uint32_t ebx;
-   uint32_t ecx;
-   uint32_t edx;
-   enum cpu_register_t return_register;
-};
+typedef uint32_t cpuid_registers_t[4];

 #define CPU_FLAG_NAME_MAX_LEN 64

@@ -76,109 +67,111 @@ struct cpuid_parameters_t {
  * Struct to hold a processor feature entry
  */
 struct feature_entry {
-   enum rte_cpu_flag_t feature;/**< feature name */
+   uint32_t leaf;  /**< cpuid leaf */
+   uint32_t subleaf;   /**< cpuid subleaf */
+   uint32_t reg;   /**< cpuid register */
+   uint32_t bit;   /**< cpuid register bit */
char name[CPU_FLAG_NAME_MAX_LEN];   /**< String for printing */
-   struct cpuid_parameters_t params;   /**< cpuid parameters */
-   uint32_t feature_mask;  /**< bitmask for feature */
 };

-#define FEAT_DEF(f) RTE_CPUFLAG_##f, #f
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+   [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },

 /**
  * An array that holds feature entries
  */
 static const struct feature_entry cpu_feature_table[] = {
-   {FEAT_DEF(SSE3),  {0x1, 0, 0, 0, REG_ECX}, 0x0001},
-   {FEAT_DEF(PCLMULQDQ), {0x1, 0, 0, 0, REG_ECX}, 0x0002},
-   {FEAT_DEF(DTES64),{0x1, 0, 0, 0, REG_ECX}, 0x0004},
-   {FEAT_DEF(MONITOR),   {0x1, 0, 0, 0, REG_ECX}, 0x0008},
-   {FEAT_DEF(DS_CPL),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
-   {FEAT_DEF(VMX),   {0x1, 0, 0, 0, REG_ECX}, 0x0020},
-   {FEAT_DEF(SMX),   {0x1, 0, 0, 0, REG_ECX}, 0x0040},
-   {FEAT_DEF(EIST),  {0x1, 0, 0, 0, REG_ECX}, 0x0080},
-   {FEAT_DEF(TM2),   {0x1, 0, 0, 0, REG_ECX}, 0x0100},
-   {FEAT_DEF(SSSE3), {0x1, 0, 0, 0, REG_ECX}, 0x0200},
-   {FEAT_DEF(CNXT_ID),   {0x1, 0, 0, 0, REG_ECX}, 0x0400},
-   {FEAT_DEF(FMA),   {0x1, 0, 0, 0, REG_ECX}, 0x1000},
-   {FEAT_DEF(CMPXCHG16B),{0x1, 0, 0, 0, REG_ECX}, 0x2000},
-   {FEAT_DEF(XTPR),  {0x1, 0, 0, 0, REG_ECX}, 0x4000},
-   {FEAT_DEF(PDCM),  {0x1, 0, 0, 0, REG_ECX}, 0x8000},
-   {FEAT_DEF(PCID),  {0x1, 0, 0, 0, REG_ECX}, 0x0002},
-   {FEAT_DEF(DCA),   {0x1, 0, 0, 0, REG_ECX}, 0x0004},
-   {FEAT_DEF(SSE4_1),{0x1, 0, 0, 0, REG_ECX}, 0x0008},
-   {FEAT_DEF(SSE4_2),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
-   {FEAT_DEF(X2APIC),{0x1, 0, 0, 0, REG_ECX}, 0x0020},
-   {FEAT_DEF(MOVBE), {0x1, 0, 0, 0, REG_ECX}, 0x0040},
-   {FEAT_DEF(POPCNT),{0x1, 0, 0, 0, REG_ECX}, 0x0080},
-   {FEAT_DEF(TSC_DEADLINE),  {0x1, 0, 0, 0, REG_ECX}, 0x0100},
-   {FEAT_DEF(AES),   {0x1, 0, 0, 0, REG_ECX}, 0x0200},
-   {FEAT_DEF(XSAVE), {0x1, 0, 0, 0, REG_ECX}, 0x0400},
-   {FEAT_DEF(OSXSAVE),   {0x1, 0, 0, 0, REG_ECX}, 

[dpdk-dev] Question regarding multi-segment packet forwarding

[Jain, Neeraj 3. (NSN - IN/Bangalore)]

Hi,
I have a question regarding sending of multi-segment packets. I have modified 
the l2fwd sample application to send a multi-segment packet on tx queue 
whenever the application receives any packet on Rx queue. Pseudo-code is as 
below

Function l2fwd_simple_forward(.)
{
Allocate new mbuf with "rte_pktmbuf_alloc"
Copy Ethernet, IP and UDP Headers into this new mbuf
Remove the Ethernet, ip and udp header from the beginning of received mbuf by 
calling rte_pktmbuf_adj api
Join the received buffer with new mbuf as follows:
{
new_mbuf->pkt.next = mbuf
/* accumulate number of segments and total length. */
new_mbuf ->pkt.nb_segs = new_mbuf->pkt.nb_segs + mbuf->pkt.nb_segs;
new_mbuf ->pkt.pkt_len += mbuf->pkt.pkt_len;

/* reset pkt_len and nb_segs for chained fragment. */
mbuf->pkt.pkt_len = mbuf->pkt.data_len;
mbuf->pkt.nb_segs = 1;
}
}


When I call rte_pktmbuf_dump on the new_mbuf, it shows both the segments. Also 
l2fwd_send_packet (which eventually calls rte_eth_tx_burst) returns 1 
indicating that packet was sent successfully. But I do not receive any packet 
on the other end.
However, instead of multi-segment packet, if I try sending only the new_mbuf 
that was created, then the packet is sent successfully.

So, Can you please advice if I am correct in the way multi-segment packets are 
created or if I am missing something here. Thanks


~Neeraj

[dpdk-dev] [PATCH v4] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[H. Peter Anvin]

On 03/25/2014 10:03 AM, Neil Horman wrote:
>  int
>  rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
>  {
> - int value;
> + const struct feature_entry *feat;
> + cpuid_registers_t regs;
> + static uint32_t max_leaf = 0;
> +
> + if (!max_leaf) {
> + /* Get the max input leaf for this processor */
> + rte_cpu_get_features(0, 0, regs);
> + max_leaf = regs[REG_EAX];
> + }
>  
>   if (feature >= RTE_CPUFLAG_NUMFLAGS)
>   /* Flag does not match anything in the feature tables */
>   return -ENOENT;
>  
> - /* get value of the register containing the desired feature */
> - value = rte_cpu_get_features(cpu_feature_table[feature].params);
> + feat = _feature_table[feature];
> +
> + if (!feat->leaf)
> + /* This entry in the table wasn't filled out! */
> + return -EFAULT;

> + if (feat->leaf > max_leaf)
> + return -EINVAL;

This doesn't quite work.  The max_leaf is per CPUID "group", i.e. the
8000 CPUID leaves have a different limit than  leaves.  So I
would just do this as:

rte_cpu_get_features(feat->leaf & 0x, 0, regs);
if (((regs[REG_EAX] ^ feat->leaf) & 0x) ||
regs[REG_EAX] < feat->leaf)
return 0;

Returning 0 is the right thing, because this is a legitimate instance of
"this feature is not supported."

The first part is a sanity check that the CPUID leaf group is supported
at all; the second part is the actual limit check.

-hpa

[dpdk-dev] [PATCH v4] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Chris Wright]

* Neil Horman (nhorman at tuxdriver.com) wrote:

(given the format, I'd expect a From hpa here)

> Neil Horman reported that on x86-64 the upper half of %rbx would get
> clobbered when the code was compiled PIC or PIE, because the
> i386-specific code to preserve %ebx was incorrectly compiled.
> 
> However, the code is really way more complex than it needs to be.  For
> one thing, the CPUID instruction only needs %eax (leaf) and %ecx
> (subleaf) as parameters, and since we are testing for bits, we might
> as well list the bits explicitly.  Furthermore, we can use an array
> rather than doing a switch statement inside a structure.
> 
> Reported-by: Neil Horman 
> Signed-off-by: H. Peter Anvin 

And an S-o-B by you

(sorry for the otherwise content free nitpick)

[dpdk-dev] writing app on other that C language

[Vasiliy Tolstov]

Is that possible to write app not in C , but for example on Go ?
Where i can find some docs about api ?

-- 
Vasiliy Tolstov,
e-mail: v.tolstov at selfip.ru
jabber: vase at selfip.ru

[dpdk-dev] [memnic PATCH 3/5] pmd: implement stats of MEMNIC

[Hiroshi Shimamoto]

Hi,

> Subject: Re: [dpdk-dev] [memnic PATCH 3/5] pmd: implement stats of MEMNIC
> 
> Hi,
> 
> 11/03/2014 05:38, Hiroshi Shimamoto:
> > From: Hiroshi Shimamoto 
> >
> > Implement missing feature to account statistics.
> > This patch adds just an infrastructure.
> >
> > Signed-off-by: Hiroshi Shimamoto 
> > Reviewed-by: Hayato Momma 
> 
> [...]
> 
> > @@ -51,6 +51,7 @@ struct memnic_adapter {
> > int up_idx, down_idx;
> > struct rte_mempool *mp;
> > struct ether_addr mac_addr;
> > +   struct rte_eth_stats stats[RTE_MAX_LCORE];
> >  };
> 
> Could you make a comment to explain why you allocate a structure per core?
> It is easier to read when locking strategy is described.

sure, could you please see the new one?

> 
> > +   for (i = 0; i < RTE_MAX_LCORE; i++) {
> > +   struct rte_eth_stats *st = >stats[i];
> > +
> > +   memset(st, 0, sizeof(*st));
> > +   }
> 
> Could you use only one memset for the array?
> 

Yep, it's reasonable.

The below is the updated patch.
Is it okay for you?

thanks,
Hiroshi

==

From: Hiroshi Shimamoto 
Subject: [PATCH v2] pmd: Implement stats of MEMNIC

Implement missing feature to account statistics.
This patch adds just an infrastructure.

Allocating per core stats area to avoid locking.

Signed-off-by: Hiroshi Shimamoto 
Reviewed-by: Hayato Momma 
---
 pmd/pmd_memnic.c | 45 ++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/pmd/pmd_memnic.c b/pmd/pmd_memnic.c
index bf5fc2e..facaf54 100644
--- a/pmd/pmd_memnic.c
+++ b/pmd/pmd_memnic.c
@@ -51,6 +51,12 @@ struct memnic_adapter {
int up_idx, down_idx;
struct rte_mempool *mp;
struct ether_addr mac_addr;
+   /*
+* Allocate per core stats to avoid lock for accounting.
+* Incrementing stats doesn't require lock, because only one thread
+* is running on per core.
+*/
+   struct rte_eth_stats stats[RTE_MAX_LCORE];
 };

 static inline struct memnic_adapter *get_adapter(const struct rte_eth_dev *dev)
@@ -126,13 +132,46 @@ static void memnic_dev_infos_get(struct rte_eth_dev *dev,
dev_info->max_mac_addrs = 1;
 }

-static void memnic_dev_stats_get(__rte_unused struct rte_eth_dev *dev,
-__rte_unused struct rte_eth_stats *stats)
+static void memnic_dev_stats_get(struct rte_eth_dev *dev,
+struct rte_eth_stats *stats)
 {
+   struct memnic_adapter *adapter = get_adapter(dev);
+   int i;
+
+   memset(stats, 0, sizeof(*stats));
+   for (i = 0; i < RTE_MAX_LCORE; i++) {
+   struct rte_eth_stats *st = >stats[i];
+
+   stats->ipackets += st->ipackets;
+   stats->opackets += st->opackets;
+   stats->ibytes += st->ibytes;
+   stats->obytes += st->obytes;
+   stats->ierrors += st->ierrors;
+   stats->oerrors += st->oerrors;
+   stats->imcasts += st->imcasts;
+   stats->rx_nombuf += st->rx_nombuf;
+   stats->fdirmatch += st->fdirmatch;
+   stats->fdirmiss += st->fdirmiss;
+
+   /* no multiqueue support now */
+   stats->q_ipackets[0] = st->q_ipackets[0];
+   stats->q_opackets[0] = st->q_opackets[0];
+   stats->q_ibytes[0] = st->q_ibytes[0];
+   stats->q_obytes[0] = st->q_obytes[0];
+   stats->q_errors[0] = st->q_errors[0];
+
+   stats->ilbpackets += st->ilbpackets;
+   stats->olbpackets += st->olbpackets;
+   stats->ilbbytes += st->ilbbytes;
+   stats->olbbytes += st->olbbytes;
+   }
 }

-static void memnic_dev_stats_reset(__rte_unused struct rte_eth_dev *dev)
+static void memnic_dev_stats_reset(struct rte_eth_dev *dev)
 {
+   struct memnic_adapter *adapter = get_adapter(dev);
+
+   memset(adapter->stats, 0, sizeof(adapter->stats));
 }

 static int memnic_dev_link_update(struct rte_eth_dev *dev,
-- 
1.8.4

[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Neil Horman]

On Mon, Mar 24, 2014 at 01:47:55PM -0700, H. Peter Anvin wrote:
> On 03/24/2014 12:52 PM, Neil Horman wrote:
> >>
> > To add an extra sanity check in rte_get_flag_enabled.  If we were moving to 
> > the
> > use of C99 initalizers, I wanted something to catch the possibility that we 
> > skip
> > a flag by accident (i.e. leave a zero initalized hole in the array).  
> > Except 0
> > from my read is a valid value for all the fields of the array.  So I bumped 
> > up
> > the cpuid register enum by one and wrapped it in a macro.  That way we can 
> > test
> > for !feat->reg as an indicator that we're requesting feature support for a 
> > flag
> > thats not listed in the array.
> 
> It actually isn't: there aren't any flags in CPUID leaf 0, so since the
> code only looks for bits it'd be perfectly okay to reject leaf 0.
> 
> Another thing that I noted is that the code doesn't actually check that
> any particular leaf is valid (by checking the maximum leaf number in
> CPUID leaf 0x:EAX).  Especially for the leaf 7 features this
> could result in false positives, which obviously would be disastrous.
> 
Thanks, I'll improve this checking today.

>   -hpa
> 
> 
> 

[dpdk-dev] RES: Latest git version (Compiling Bugs)

[Fred Pedrisa]

I?ve switched back to 1.6.0-0r0 and it is working fine, the problem seems to
be happening only with the new version.



De: Antonio Neto [mailto:netoftc at hotmail.com] 
Enviada em: ter?a-feira, 25 de mar?o de 2014 02:11
Para: Fr3DBr -
Assunto: RE: [dpdk-dev] Latest git version (Compiling Bugs)



Hello, Im having the same problem too using FreeBSD 9.2



> From: fredhps10 at hotmail.com
> To: dev at dpdk.org
> Date: Tue, 25 Mar 2014 02:10:27 -0300
> Subject: [dpdk-dev] Latest git version (Compiling Bugs)
> 
> Hi, Guys.
> 
> 
> 
> I am using the latest version on git, and there are problems compiling the
> sources under FreeBSD 9.2, is this expected ?
> 
> 
> 
> Sincerely,
> 
> 
> 
> Fred Pedrisa
> 

[dpdk-dev] Latest git version (Compiling Bugs)

[Fred Pedrisa]

Hi, Guys.



I am using the latest version on git, and there are problems compiling the
sources under FreeBSD 9.2, is this expected ?



Sincerely,



Fred Pedrisa

[dpdk-dev] [PATCH 09/11] device-args: replace use-device eal option by pci-whitelist and vdev

[Thomas Monjalon]

Hi,

04/03/2014 13:14, Richardson, Bruce:
> 04/03/2014 14:09, Olivier MATZ:
> > My initial concern was that --use-device has 2 different significations,
> > depending on the format of arguments:
> >- instanciate a virtual driver if it looks like a vdev name
> >- add a PCI device to the whitelist if it looks like a pci address
> > I also find strange that instanciating a virtual device changes the PCI
> > mode to whitelist, even if it could be fixed by adding a specific argument
> > for that.
>
> [BR] I agree that having the mode change silently like that was probably not
> the best design. I therefore, agree that a flag should be used to switch
> from normal to whitelist mode, I just think that thereafter the devices of
> whatever type should all be enumerated using a common flag parameter.

I think we should split this in 2 functions because they have totally 
different meaning:
- create a virtual device and instantiate a driver
- whitelist a physical device for driver probing
Using the same option for vdev and whitelist would be even more confusing in 
case of blacklist because drivers would probe explicitly listed vdevs and PCI 
devs which are not blacklisted.

-- 
Thomas