[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: struct rte_fdir_masks fdir_masks; struct rte_fdir_filter fdir_filter; memset(&fdir_masks, 0, sizeof(struct rte_fdir_masks)); fdir_masks.src_ipv4_mask = HHIP_MASK; memset(&fdir_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, &fdir_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, &fdir_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
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] [memnic PATCH 3/5] pmd: implement stats of MEMNIC
25/03/2014 08:23, Hiroshi Shimamoto: > The below is the updated patch. > Is it okay for you? Yes, I acked and applied it. Thank you -- Thomas
[dpdk-dev] [PATCH v5] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
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
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
> -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
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
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 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
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
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 = &cpu_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
* 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
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
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 = &adapter->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 = &adapter->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
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)
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)
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
