[dpdk-dev] L2FWD Sample Application stops receiving packets after sometime
Hi Neeraj, I am glad your usecase works. Please do let me know what is the maximum throughput you are able to achieve with vmxnet3 (assuming your underlying physical NIC is 10 Gig), it will be interesting to see the performance. Regards -Prashant -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jain, Neeraj 3. (NSN - IN/Bangalore) Sent: Thursday, March 20, 2014 5:00 PM To: dev at dpdk.org Subject: Re: [dpdk-dev] L2FWD Sample Application stops receiving packets after sometime Found the Problem. Few packet buffers were not being freed which lead to slow leak of mbufs. ~Neeraj -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of ext Jain, Neeraj 3. (NSN - IN/Bangalore) Sent: Thursday, March 20, 2014 2:42 PM To: dev at dpdk.org Subject: [dpdk-dev] L2FWD Sample Application stops receiving packets after sometime Hi, I am currently running few trials with DPDK sample application for one of my project requirements. Below are the system details under which the sample application (L2 Forward) is being run. Platform: Linux 2.6.32-358.17.1.el6.x86_64 VMWare: ESXI 5.1 Driver: vmxnet3-usermap L2 FWD program is being run with a load of ~100K packets per second on RX queue. The sample application successfully forwards the packets to other end for some time. However, after around 1 hour run, I see that rte_eth_rx_burst returns 0 packets received, though the load generator continuously sends packet to the L2 FWD program. The statistics reported by the sample application also shows the "Packets received:" value stops incrementing. I also used "rte_eth_stats_get" api to check if any packets are being received on the interface. This api shows the packets are being received at the interface, however rte_eth_rx_burst does not pick these packets. Can you please help me as to why this behavior is seen. Also, please let me know if you need further details. Thanks ~Neeraj === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===
[dpdk-dev] Which vmxnet3 pmd is to be used in dpdk 1.6.x?
Hi Stephen, I believe the 1.6.0r2 is baking. It would be great if you could enhance the vmxnet3 driver on the above with multi-segment support. Any serious usecase ends up using multi-segment, so would be great if r2 can capture it. Regards -Prashant -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Prashant Upadhyaya Sent: Tuesday, March 11, 2014 10:57 AM To: Stephen Hemminger Cc: dev at dpdk.org Subject: Re: [dpdk-dev] Which vmxnet3 pmd is to be used in dpdk 1.6.x? Hi Stephen, This is great news ! I can wait for a formal release of DPDK with your driver. Please let me know when is the release expected. I will happily migrate to that. Regards -Prashant -Original Message- From: Stephen Hemminger [mailto:step...@networkplumber.org] Sent: Monday, March 10, 2014 9:21 PM To: Prashant Upadhyaya Cc: Srinivasan J; dev at dpdk.org Subject: Re: [dpdk-dev] Which vmxnet3 pmd is to be used in dpdk 1.6.x? On Mon, 10 Mar 2014 13:30:48 +0530 Prashant Upadhyaya wrote: > Hi Srini, > > Thanks, I could also make it work, thanks to your cue ! > > Now then, this multi-segment not being supported in vmxnet3 driver is a big > party-pooper for me. Unfortunately in my usecase, I do indeed make heavy use > of multisegment buffers for sending out the data, so my usecase has failed > and I will have to fix that. > > Also, can you please adivse how much is the max data rates you have been able > to achieve with one vmxnet3 10G port. > > Thanks a lot for the advice once again. > > Regards > -Prashant I am integrating our driver with the 1.6.1 DPDK driver. We support multi-segment, if you want I will backport that feature first. === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. === === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===
[dpdk-dev] [PATCH] igb_uio: don't bind vmxnet3 and virtio devices if disabled
05/03/2014 16:16, David Marchand : > When not using vmxnet3-uio and virtio-uio PMDs, prevent igb_uio from binding > these devices. This way, vmxnet3 and virtio PMDs won't fail to initialize > because of a device silently bound to igb_uio. > > Signed-off-by: David Marchand Acked and applied for version 1.6.0r2. Thank you -- Thomas
[dpdk-dev] [PATCH] vmxnet3: rename library
In order to distinguish clearly this implementation from the extension vmxnet3-usermap, it is renamed to reflect its usage of uio framework. Signed-off-by: Thomas Monjalon --- lib/librte_pmd_vmxnet3/Makefile | 2 +- mk/rte.app.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/librte_pmd_vmxnet3/Makefile b/lib/librte_pmd_vmxnet3/Makefile index 0569e11..1f0f8e0 100644 --- a/lib/librte_pmd_vmxnet3/Makefile +++ b/lib/librte_pmd_vmxnet3/Makefile @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk # # library name # -LIB = librte_pmd_vmxnet3.a +LIB = librte_pmd_vmxnet3_uio.a CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) diff --git a/mk/rte.app.mk b/mk/rte.app.mk index b691526..9c70ce0 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -83,7 +83,7 @@ LDLIBS += -lrte_pmd_virtio_uio endif ifeq ($(CONFIG_RTE_LIBRTE_VMXNET3_PMD),y) -LDLIBS += -lrte_pmd_vmxnet3 +LDLIBS += -lrte_pmd_vmxnet3_uio endif ifeq ($(CONFIG_RTE_LIBRTE_TIMER),y) -- 1.9.0
[dpdk-dev] [PATCH] vmxnet3: rename library
On 03/21/2014 01:59 PM, Thomas Monjalon wrote: > In order to distinguish clearly this implementation from the extension > vmxnet3-usermap, it is renamed to reflect its usage of uio framework. > > Signed-off-by: Thomas Monjalon LGTM Acked-by: Thomas Graf
[dpdk-dev] [PATCH] pci: fix igb_uio mapping for virtio_uio and vmxnet3_uio
Since commit 10ed994 (pci: use igb_uio mapping only when needed),
the flag RTE_PCI_DRV_NEED_IGB_UIO must be set even if RTE_EAL_UNBIND_PORTS
is disabled.
It was not the case for virtio_uio and vmxnet3_uio so the uio resources were
not mapped.
Reported-by: Daniel Kan
Signed-off-by: Thomas Monjalon
---
lib/librte_pmd_virtio/virtio_ethdev.c | 2 --
lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 1cd921b..f107161 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -474,9 +474,7 @@ static struct eth_driver rte_virtio_pmd = {
{
.name = "rte_virtio_pmd",
.id_table = pci_id_virtio_map,
-#ifdef RTE_EAL_UNBIND_PORTS
.drv_flags = RTE_PCI_DRV_NEED_IGB_UIO,
-#endif
},
.eth_dev_init = eth_virtio_dev_init,
.dev_private_size = sizeof(struct virtio_adapter),
diff --git a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
index 6757aa2..8259cfe 100644
--- a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c
@@ -267,9 +267,7 @@ static struct eth_driver rte_vmxnet3_pmd = {
{
.name = "rte_vmxnet3_pmd",
.id_table = pci_id_vmxnet3_map,
-#ifdef RTE_EAL_UNBIND_PORTS
.drv_flags = RTE_PCI_DRV_NEED_IGB_UIO,
-#endif
},
.eth_dev_init = eth_vmxnet3_dev_init,
.dev_private_size = sizeof(struct vmxnet3_adapter),
--
1.9.0
[dpdk-dev] On vmxnet-pmd crash in DPDK 1.6.0r1
10/03/2014 23:29, Daniel Kan :
> virtio-pmd has the same pattern. I wonder if vmxnet3-pmd just blindly copied
> the same paradigm.
>
> 473 static struct eth_driver rte_virtio_pmd = {
> 474 {
> 475 .name = "rte_virtio_pmd",
> 476 .id_table = pci_id_virtio_map,
> 477 #ifdef RTE_EAL_UNBIND_PORTS
> 478 .drv_flags = RTE_PCI_DRV_NEED_IGB_UIO,
> 479 #endif
[...]
> > 266 static struct eth_driver rte_vmxnet3_pmd = {
> > 267 {
> > 268 .name = "rte_vmxnet3_pmd",
> > 269 .id_table = pci_id_vmxnet3_map,
> > 270 #ifdef RTE_EAL_UNBIND_PORTS
> > 271 .drv_flags = RTE_PCI_DRV_NEED_IGB_UIO,
> > 272 #endif
It was the old way of configuring UIO PMD before this patch:
pci: use igb_uio mapping only when needed
http://dpdk.org/browse/dpdk/commit/?id=10ed99419b12b8
The goal of this patch was to fix usage of the extensions virtio-net-pmd and
vmxnet3-usermap.
You can see in this patch that em/igb/ixgbe drivers are updated accordingly.
Then virtio_uio and vmxnet3_uio were released without this patch in mind. So
they were broken.
> > lib/librte_eal/linuxapp/eal/eal_pci.c
> > 1039 #ifdef RTE_EAL_UNBIND_PORTS
> > 1040 if (dr->drv_flags & RTE_PCI_DRV_NEED_IGB_UIO) {
> > 1041 /* unbind driver and load uio resources for Intel NICs */
> > 1042 if (pci_switch_module(dr, dev, 1, IGB_UIO_NAME) < 0)
> > ...
> > 1050 #else
> > 1051 if (dr->drv_flags & RTE_PCI_DRV_NEED_IGB_UIO)
> > 1052 /* just map resources for Intel NICs */
> > 1053 if (pci_uio_map_resource(dev) < 0)
> > 1054 return -1;
> > 1055 #endif
> >
> > If RTE_EAL_UNBIND_PORTS is defined, pci_switch_module will call
> > pci_uio_map_resource.
> >
> > I then looked at the bsdapp?s version, it simply has:
> > lib/librte_eal/bsdapp/eal/eal_pci.c
> > 479 /* just map the NIC resources */
> > 480 if (pci_uio_map_resource(dev) < 0)
> > 481 return -1;
> >
> > I don?t know the history behind why .drv_flags = RTE_PCI_DRV_NEED_IGB_UIO
> > only for RTE_EAL_UNBIND_PORTS. Can we just ensure pci_uio_map_resource is
> > called in linux just like bsd version? One way is to ensure drv_flags is
> > always set to RTE_PCI_DRV_NEED_IGB_UIO, but I don?t know if this fix will
> > break other parts.
I've just sent another patch to update and fix virtio_uio and vmxnet3_uio:
http://dpdk.org/ml/archives/dev/2014-March/001647.html
Feel free to ack it.
Thanks for reporting
--
Thomas
[dpdk-dev] [PATCH] vmxnet3: rename library
21/03/2014 14:41, Thomas Graf : > On 03/21/2014 01:59 PM, Thomas Monjalon wrote: > > In order to distinguish clearly this implementation from the extension > > vmxnet3-usermap, it is renamed to reflect its usage of uio framework. > > > > Signed-off-by: Thomas Monjalon > > LGTM > > Acked-by: Thomas Graf Applied for version 1.6.0r2. Thank you -- Thomas
[dpdk-dev] [PATCH] pci: fix igb_uio mapping for virtio_uio and vmxnet3_uio
21/03/2014 14:50, Thomas Monjalon : > Since commit 10ed994 (pci: use igb_uio mapping only when needed), > the flag RTE_PCI_DRV_NEED_IGB_UIO must be set even if RTE_EAL_UNBIND_PORTS > is disabled. > It was not the case for virtio_uio and vmxnet3_uio so the uio resources were > not mapped. > > Reported-by: Daniel Kan > Signed-off-by: Thomas Monjalon Merged with Daniel Kan's patch. -- Thomas
[dpdk-dev] [PATCH] vmxnet3: fixed segfault when initializing vmxnet3 pmd on linux platform
12/03/2014 13:19, Daniel Kan : > The vmxnet3 PCI hardware resources were never memory mapped when > RE_EAL_UNBIND_PORTS is not defined. Specifically, pci_dev->mem_resource is > not mapped. The fix is to always set drv_flags with RTE_PCI_DRV_NEED_IGU > for vmxnet3. This ensures pci_uio_map_resource() is called. > > Signed-off-by: Daniel Kan I forgot your patch when I've sent this one: http://dpdk.org/ml/archives/dev/2014-March/001647.html I've merged them and applied for 1.6.0r2: http://dpdk.org/browse/dpdk/commit/?id=18f02ff759 Thank you -- Thomas
[dpdk-dev] [PATCH v2] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
From: "H. Peter Anvin"
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
Tested-by: Neil Horman
---
Change notes:
v2) Corrected build errors
Fixed cpuid_register_t reference passing
Fixed typedef name typo
---
lib/librte_eal/common/eal_common_cpuflags.c | 274 +---
1 file changed, 123 insertions(+), 151 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c
b/lib/librte_eal/common/eal_common_cpuflags.c
index 1ebf78c..438d9c5 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
@@ -78,8 +69,10 @@ struct cpuid_parameters_t {
struct feature_entry {
enum rte_cpu_flag_t feature;/**< feature name */
char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
- struct cpuid_parameters_t params; /**< cpuid parameters */
- uint32_t feature_mask; /**< bitmask for feature */
+ uint32_t leaf; /**< cpuid leaf */
+ uint32_t subleaf; /**< cpuid subleaf */
+ uint32_t reg; /**< cpuid register */
+ uint32_t bit; /**< cpuid register bit */
};
#define FEAT_DEF(f) RTE_CPUFLAG_##f, #f
@@ -88,97 +81,97 @@ struct feature_entry {
* 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}, 0x0800},
- {FEAT_DEF(AVX), {0x1, 0, 0, 0, REG_ECX}, 0x1000},
- {FEAT_DEF(F16C), {0x1, 0, 0, 0, REG_ECX}, 0x2000},
- {FEAT_DEF(RDRAND),{0x1, 0, 0, 0, REG_ECX}, 0x4000},
-
- {FEAT_DEF(FPU), {0x1, 0, 0, 0, REG_EDX}, 0x0001},
- {FEAT_DEF(VME), {0x1, 0, 0, 0, REG_EDX}, 0x0002},
- {FEAT_DEF(DE),{0x1, 0, 0, 0, REG_EDX}, 0x0004},
- {FEAT_DEF(PSE), {0x1, 0, 0, 0, REG_EDX}, 0x0008},
- {FEAT_DEF(TSC), {0x1, 0, 0, 0, REG_EDX}, 0x0010},
- {FEAT_DEF(MS
[dpdk-dev] [memnic PATCH v2] linux: fix build with kernel 3.3
18/03/2014 23:04, Hiroshi Shimamoto : > > Remove unused dev_ops functions. > > > > The API of some functions (memnic_vlan_rx_add_vid, > > memnic_vlan_rx_kill_vid) changed starting from 3.3 kernel. Instead of > > using a #ifdef to handle the compilation on any kernel, we can just > > remove these functions as they are not needed. > > > > Signed-off-by: Olivier Matz > > Acked-by: Hiroshi Shimamoto Applied. Thank you -- Thomas
[dpdk-dev] [memnic PATCH] pmd: enable compiler optimization
19/03/2014 10:19, Hiroshi Shimamoto : > Hi, > > this makes sense. > > > Subject: [dpdk-dev] [memnic PATCH] pmd: enable compiler optimization > > > > Add -O3 in flags, it was missing in initial Makefile. > > > > Signed-off-by: Olivier Matz > > Acked-by: Hiroshi Shimamoto Applied. Thank you -- Thomas
[dpdk-dev] [PATCH v2] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
On 03/21/2014 07:49 AM, Neil Horman wrote: > From: "H. Peter Anvin" > > 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 > Tested-by: Neil Horman > Thank you for dealing with this! On the subject of my other email... are C99 initializers acceptable in dpdk? If so, I think making that change, too, would be a good idea. -hpa
[dpdk-dev] [PATCH v2] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
On Fri, Mar 21, 2014 at 08:03:34AM -0700, H. Peter Anvin wrote: > On 03/21/2014 07:49 AM, Neil Horman wrote: > > From: "H. Peter Anvin" > > > > 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 > > Tested-by: Neil Horman > > > > Thank you for dealing with this! > > On the subject of my other email... are C99 initializers acceptable in > dpdk? If so, I think making that change, too, would be a good idea. > I'll have to defer this to others, I'm not sure what the accepted initalization method is. I'm guessing their fine, as both icc and gcc allow them and those are the supported compilers for dpdk, but I'd like to hear someone in the maintainership comment. Best Neil > -hpa > > >
[dpdk-dev] [memnic PATCH 2/5] pmd: check frame length from host
11/03/2014 05:38, Hiroshi Shimamoto: > Drop packets which have invalid length. > > Normally this must not happen while vSwitch works fine, however > it's better to put a sentinel to prevent memory corruption. > > Signed-off-by: Hiroshi Shimamoto > Reviewed-by: Hayato Momma Acked and applied with title "pmd: check received frame length" Thank you -- Thomas
