[dpdk-dev] ISSUE IN rte_bitmap
Hi , i am facing a issue regarding with the maximum amount of bits that the
rte_bitmap allows.
Example :
bmp_mem_size = rte_bitmap_get_memory_footprint(4000);
OK
(bmp_mem_size==2101312 (size in bytes aligned). Around 2MB)
but if i do this:
bmp_mem_size = rte_bitmap_get_memory_footprint(4294967292); (MAX uint32_t).
(bmp_mem_size == 64).
obviously this is wrong , besides the validation problem inside the
function rte_bitmap_get_memory_footprint, the main problem is that the
rte_bitmap api uses word size (4 bytes ints) for calculations of the max
bitmap size and ,of course, make them turn around.
In the rte_sched code there is a similar issue. In theory (By doc) the qos
scheduler can handle a configuration like this:
struct rte_sched_port_hierarchy {
uint32_t queue:2;/**< Queue ID (0 .. 3) */
uint32_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
uint32_t pipe:20; /**< Pipe ID */ (Compile time configuration) 1M
subscribers
uint32_t subport:6; /**< Subport ID */ 32 subport
uint32_t color:2; /**< Color */
};
If one try to make a struct rte_sched_port* with that configuration (4095
MAX pipe profiles) , the api fails because when the function
rte_sched_port_config() tries to initialize the maximum memory use for that
configuration previously calling rte_sched_port_get_array_base() , that
function generates invalid total size, because the total memory size needed
is beyond 4Gb , bigger than unsigned int max limit. (Again here the code is
using uint32_t data for size calculation).
I know maybe the case use of qos scheduler is not intend for that huge
configuration but looking at the code there is no limitation except for the
4 bytes RSS struct rte_sched_port_hierarchy bit fields .
[dpdk-dev] [PATCH] qos_meter: Fix compilation with APP_MODE_FWD
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ian Stokes > Sent: Tuesday, August 18, 2015 8:55 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] qos_meter: Fix compilation with APP_MODE_FWD > > The qos_meter sample app will fail to compile if APP_MODE is set to > APP_MODE_FWD. This patch changes the variable name 'color' in main.h to > the expected variable name 'input_color' to allow compilation with > APP_MODE_FWD. > > Signed-off-by: Ian Stokes Acked-by: John McNamara
[dpdk-dev] [PATCH 3/3] app/test: enable test_red to build on non x86 platform
Signed-off-by: Jerin Jacob
---
app/test/test_red.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/app/test/test_red.c b/app/test/test_red.c
index 262df72..813c508 100644
--- a/app/test/test_red.c
+++ b/app/test/test_red.c
@@ -146,6 +146,7 @@ static void rdtsc_prof_init(struct rdtsc_prof *p, const
char *name)
static inline void rdtsc_prof_start(struct rdtsc_prof *p)
{
+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686) ||
defined(RTE_ARCH_X86_X32)
#ifdef __PIC__
asm volatile (
"mov %%ebx, %%edi\n"
@@ -155,6 +156,7 @@ static inline void rdtsc_prof_start(struct rdtsc_prof *p)
#else
asm( "cpuid" : : : "%eax", "%ebx", "%ecx", "%edx" );
#endif
+#endif
p->clk_start = rte_rdtsc();
}
--
2.1.0
[dpdk-dev] [PATCH 2/3] app/test: test_sched: fix needless build dependency on CONFIG_RTE_ARCH_X86_64
Signed-off-by: Jerin Jacob --- app/test/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/test/Makefile b/app/test/Makefile index e7f148f..43429b9 100644 --- a/app/test/Makefile +++ b/app/test/Makefile @@ -115,7 +115,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_lib.c ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) SRCS-y += test_red.c -SRCS-$(CONFIG_RTE_ARCH_X86_64) += test_sched.c +SRCS-y += test_sched.c endif SRCS-$(CONFIG_RTE_LIBRTE_METER) += test_meter.c -- 2.1.0
[dpdk-dev] [PATCH 1/3] sched: remove unused inclusion of tmmintrin.h
SSSE3 intrinsics not used in rte_bitmap.h
Signed-off-by: Jerin Jacob
---
lib/librte_sched/rte_bitmap.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/librte_sched/rte_bitmap.h b/lib/librte_sched/rte_bitmap.h
index 216a344..3d911e4 100644
--- a/lib/librte_sched/rte_bitmap.h
+++ b/lib/librte_sched/rte_bitmap.h
@@ -73,9 +73,6 @@ extern "C" {
#ifndef RTE_BITMAP_OPTIMIZATIONS
#define RTE_BITMAP_OPTIMIZATIONS1
#endif
-#if RTE_BITMAP_OPTIMIZATIONS
-#include
-#endif
/* Slab */
#define RTE_BITMAP_SLAB_BIT_SIZE 64
--
2.1.0
[dpdk-dev] [PATCH 0/3] fix build issues with librte_sched, test_red on non x86 platform
This patch set enable librte_sched, app/test/test_sched and app/test/test_red to build on non x86 platform Jerin Jacob (3): sched: remove unused inclusion of tmmintrin.h app/test: test_sched: fix needless build dependency on CONFIG_RTE_ARCH_X86_64 app/test: enable test_red to build on non x86 platform app/test/Makefile | 2 +- app/test/test_red.c | 2 ++ lib/librte_sched/rte_bitmap.h | 3 --- 3 files changed, 3 insertions(+), 4 deletions(-) -- 2.1.0
[dpdk-dev] [PATCH] qos_meter: Fix compilation with APP_MODE_FWD
The qos_meter sample app will fail to compile if APP_MODE is set to APP_MODE_FWD. This patch changes the variable name 'color' in main.h to the expected variable name 'input_color' to allow compilation with APP_MODE_FWD. Signed-off-by: Ian Stokes --- examples/qos_meter/main.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/examples/qos_meter/main.h b/examples/qos_meter/main.h index 530bf69..08fbcb9 100644 --- a/examples/qos_meter/main.h +++ b/examples/qos_meter/main.h @@ -50,7 +50,7 @@ enum policer_action policer_table[e_RTE_METER_COLORS][e_RTE_METER_COLORS] = #if APP_MODE == APP_MODE_FWD -#define FUNC_METER(a,b,c,d) color, flow_id=flow_id, pkt_len=pkt_len, time=time +#define FUNC_METER(a,b,c,d) input_color, flow_id=flow_id, pkt_len=pkt_len, time=time #define FUNC_CONFIG(a,b) #define PARAMS app_srtcm_params #define FLOW_METER int -- 1.7.4.1
[dpdk-dev] Industry's Tiny and Powerful Wireless LAN Controller - Running On Intel NUC D34010WYKH - Built on DPDK
On 8/18/15 12:50 PM, Stephen Hemminger wrote: > On Tue, 18 Aug 2015 13:33:00 +0530 > Venkateswara Rao Thummala wrote: > >> Hi, >> >> We are happy to announce that, we have Just launched the Industry's Tiny >> and Powerful Wireless LAN Controller - running on Intel NUC D34010WYKH. >> >> - Built on High Performance Virtual Data Plane, which is built using DPDK >> - Supports wide range of Third Party Access Points >> >> Please visit our Website www.onehopnetworks.com for more details. >> >> Regards >> Venkat >> Founder & Chief Architect >> OneHop Networks Pvt Ltd >> [www.onehopnetworks.com] > Congratulations. Do you plan to contribute code to help DPDK advance? +1 > > > > -- > Thomas F Herbert Red Hat
[dpdk-dev] flow_director_filter error!!
Hello: Using dpdk-2.0.0 and i540 - I am using the testpmd app to test-drive the flow-director filter settings. After I start the testpmd app, I am flusing the flow_director_filter settings and get the following error - testpmd> flush_flow_director 0 PMD: ixgbe_fdir_flush(): Failed to re-initialize FD table. flow director table flushing error: (Too many open files in system) Any clues or directions? Thanks -Navneet
[dpdk-dev] [PATCH] ring: add function to free a ring
When creating a ring, a memzone is created to allocate it in memory,
but the ring could not be freed, as memzones could not be.
Since memzones can be freed now, then rings can be as well,
taking into account if they were initialized using pre-allocated memory
(in which case, memory should be freed externally) or using rte_memzone_reserve
(with rte_ring_create), freeing the memory with rte_memzone_free.
Signed-off-by: Pablo de Lara
---
lib/librte_ring/rte_ring.c | 43
lib/librte_ring/rte_ring.h | 7 ++
lib/librte_ring/rte_ring_version.map | 7 ++
3 files changed, 57 insertions(+)
diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
index c9e59d4..83ce6d3 100644
--- a/lib/librte_ring/rte_ring.c
+++ b/lib/librte_ring/rte_ring.c
@@ -208,6 +208,49 @@ rte_ring_create(const char *name, unsigned count, int
socket_id,
return r;
}
+/* free the ring */
+void
+rte_ring_free(struct rte_ring *r)
+{
+ struct rte_ring_list *ring_list = NULL;
+ char mz_name[RTE_MEMZONE_NAMESIZE];
+ struct rte_tailq_entry *te;
+ const struct rte_memzone *mz;
+
+ if (r == NULL)
+ return;
+
+ snprintf(mz_name, sizeof(mz_name), "%s%s", RTE_RING_MZ_PREFIX, r->name);
+ mz = rte_memzone_lookup(mz_name);
+
+ /*
+* Free ring memory if it was allocated with rte_memzone_reserve,
+* otherwise it should be freed externally
+*/
+ if (rte_memzone_free(mz) != 0)
+ return;
+
+ ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
+ rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK);
+
+ /* find out tailq entry */
+ TAILQ_FOREACH(te, ring_list, next) {
+ if (te->data == (void *) r)
+ break;
+ }
+
+ if (te == NULL) {
+ rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
+ return;
+ }
+
+ TAILQ_REMOVE(ring_list, te, next);
+
+ rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
+
+ rte_free(te);
+}
+
/*
* change the high water mark. If *count* is 0, water marking is
* disabled
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af6..e75566f 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -300,6 +300,13 @@ int rte_ring_init(struct rte_ring *r, const char *name,
unsigned count,
*/
struct rte_ring *rte_ring_create(const char *name, unsigned count,
int socket_id, unsigned flags);
+/**
+ * De-allocate all memory used by the ring.
+ *
+ * @param r
+ * Ring to free
+ */
+void rte_ring_free(struct rte_ring *r);
/**
* Change the high water mark.
diff --git a/lib/librte_ring/rte_ring_version.map
b/lib/librte_ring/rte_ring_version.map
index 982fdd1..5474b98 100644
--- a/lib/librte_ring/rte_ring_version.map
+++ b/lib/librte_ring/rte_ring_version.map
@@ -11,3 +11,10 @@ DPDK_2.0 {
local: *;
};
+
+DPDK_2.2 {
+ global:
+
+ rte_ring_free;
+
+} DPDK_2.0;
--
2.4.2
[dpdk-dev] Industry's Tiny and Powerful Wireless LAN Controller - Running On Intel NUC D34010WYKH - Built on DPDK
Hi, We are happy to announce that, we have Just launched the Industry's Tiny and Powerful Wireless LAN Controller - running on Intel NUC D34010WYKH. - Built on High Performance Virtual Data Plane, which is built using DPDK - Supports wide range of Third Party Access Points Please visit our Website www.onehopnetworks.com for more details. Regards Venkat Founder & Chief Architect OneHop Networks Pvt Ltd [www.onehopnetworks.com]
[dpdk-dev] [PATCH] eal/linux: fix rte_epoll_wait
Function rte_epoll_wait should return when underlying call
to epoll_wait times out.
Signed-off-by: Robert Sanford
---
lib/librte_eal/linuxapp/eal/eal_interrupts.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index 3f87875..25cae6a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -1012,6 +1012,9 @@ rte_epoll_wait(int epfd, struct rte_epoll_event *events,
strerror(errno));
rc = -1;
break;
+ } else {
+ /* rc == 0, epoll_wait timed out */
+ break;
}
}
--
1.7.1
[dpdk-dev] [PATCH] doc: fix for vhost sample parameter
This commit removes the dev-index, so update the doc for this change: 17b8320a3e11e146868906d0082b6e402d5f2255 "vhost: remove index parameter" Signed-off-by: Changchun Ouyang --- doc/guides/sample_app_ug/vhost.rst| 18 -- lib/librte_vhost/libvirt/qemu-wrap.py | 10 +- 2 files changed, 13 insertions(+), 15 deletions(-) diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index 730b9da..2ec2843 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -386,7 +386,7 @@ Running the Sample Code .. code-block:: console -user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge -- -p 0x1 --dev-basename usvhost --dev-index 1 +user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge -- -p 0x1 --dev-basename usvhost vhost user: a socket file named usvhost will be created under current directory. Use its path as the socket path in guest's qemu commandline. @@ -401,19 +401,17 @@ Running the Sample Code Parameters ~~ -**Basename and Index.** +**Basename.** vhost cuse uses a Linux* character device to communicate with QEMU. -The basename and the index are used to generate the character devices name. - -/dev/- +The basename is used to generate the character devices name. -The index parameter is provided for a situation where multiple instances of the virtual switch is required. +/dev/ -For compatibility with the QEMU wrapper script, a base name of "usvhost" and an index of "1" should be used: +For compatibility with the QEMU wrapper script, a base name of "usvhost" should be used: .. code-block:: console -user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge -- -p 0x1 --dev-basename usvhost --dev-index 1 +user at target:~$ ./build/app/vhost-switch -c f -n 4 --huge-dir / mnt/huge -- -p 0x1 --dev-basename usvhost **vm2vm.** The vm2vm parameter disable/set mode of packet switching between guests in the host. @@ -678,11 +676,11 @@ To call the QEMU wrapper automatically from libvirt, the following configuration emul_path = "/usr/local/bin/qemu-system-x86_64" * Configure the "us_vhost_path" variable to point to the DPDK vhost-net sample code's character devices name. -DPDK vhost-net sample code's character device will be in the format "/dev/-". +DPDK vhost-net sample code's character device will be in the format "/dev/". .. code-block:: xml -us_vhost_path = "/dev/usvhost-1" +us_vhost_path = "/dev/usvhost" Common Issues ~ diff --git a/lib/librte_vhost/libvirt/qemu-wrap.py b/lib/librte_vhost/libvirt/qemu-wrap.py index 5096011..cd77c3a 100755 --- a/lib/librte_vhost/libvirt/qemu-wrap.py +++ b/lib/librte_vhost/libvirt/qemu-wrap.py @@ -75,7 +75,7 @@ #"/dev/random", "/dev/urandom", #"/dev/ptmx", "/dev/kvm", "/dev/kqemu", #"/dev/rtc", "/dev/hpet", "/dev/net/tun", -#"/dev/-", +#"/dev/", #] # # 4.b) Disable SELinux or set to permissive mode @@ -129,13 +129,13 @@ emul_path = "/usr/local/bin/qemu-system-x86_64" #Path to userspace vhost device file -# This filename should match the --dev-basename --dev-index parameters of +# This filename should match the --dev-basename parameters of # the command used to launch the userspace vhost sample application e.g. # if the sample app lauch command is: -#./build/vhost-switch . --dev-basename usvhost --dev-index 1 +#./build/vhost-switch . --dev-basename usvhost # then this variable should be set to: -# us_vhost_path = "/dev/usvhost-1" -us_vhost_path = "/dev/usvhost-1" +# us_vhost_path = "/dev/usvhost" +us_vhost_path = "/dev/usvhost" #List of additional user defined emulation options. These options will #be added to all Qemu calls -- 1.8.4.2
[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Singh, Jasvinder > Sent: Monday, August 17, 2015 7:14 PM > To: Yeddula, Avinash; Richardson, Bruce > Cc: dev at dpdk.org; Bly, Mike > Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > Hi, > > > -Original Message- > > From: Yeddula, Avinash [mailto:ayeddula at ciena.com] > > Sent: Monday, August 17, 2015 5:35 PM > > To: Singh, Jasvinder; Richardson, Bruce > > Cc: dev at dpdk.org; Bly, Mike > > Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > > > + Mike ( My team mate) > > Hi Jasvinder, It's not a bidirectional packet flow. The pipeline looks > something > > like this. > > > > Ingress port-Table 1 Table-2 - Mac_Table - Table4 > > Egress > > port. > > > > Before the frame goes reaches table 4, we do 2 lookups at the mac table. > > 1. src lookup ( To learn the MAC on the bridge) 2. dst lookup ( Flooding if > dst > > MAC look up fails else Unicast/forward if dst lookup success). > > > > Here are the keys we are using. > > Src lookup key - Src MAC (src MAC in the frame) + Bridge ID ( Bridge on > > which it arrived). > > Dst lookup key - Dst MAC (dst MAC in the frame) + Bridge ID ( Bridge on > > which it arrived) > > > > There is as such no mechanism to support double lookup on the same table > for the packet. However, alternative approach could be-first perform > destination lookup and invoke action handler ( in both table hit & miss > case). > In action handler, Src MAC + bridge ID key can be added to the table > (rte_pipeline_table_entry_add) . If a new entry is successfully added to the > hash for the specified key, or there is already an entry in the hash for the > specified key, then the position of the entry is returned. In this way, table > entries will be updated with incoming packets. > Yes, the two lookups are really one lookup and one add/update operation. > > > Thanks > > -Avinash > > > > -Original Message- > > From: Singh, Jasvinder [mailto:jasvinder.singh at intel.com] > > Sent: Monday, August 17, 2015 7:00 AM > > To: Richardson, Bruce; Yeddula, Avinash > > Cc: dev at dpdk.org > > Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > > > > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce > Richardson > > > Sent: Friday, August 14, 2015 10:25 AM > > > To: Yeddula, Avinash > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > > > > > On Thu, Aug 13, 2015 at 05:37:21PM -0400, Yeddula, Avinash wrote: > > > > Any comments on this question ? > > > > > > > > Thanks > > > > -Avinash > > > > > > > > -Original Message- > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, > > > > Avinash > > > > Sent: Wednesday, August 12, 2015 3:04 PM > > > > To: dev at dpdk.org > > > > Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table. > > > > > > > > Hello All, > > > > > > > > I'm using DPDK extendable hash tables. This question is with respect > > > > to the > > > lookup aspect of the hash table. > > > > I see that there is just one "t->key_offset" that is pre-defined for > > > > the hash > > > table. I also understand that the frame needs to carry the "lookup_key > > > / keys" in the meta data. > > > > > > > > Here is my question: How to support more than one lookup with > > > > different > > > keys on the same frame on the same table. > > > > Use case: Src mac lookup and dst mac lookup on the same mac table. > > > > > > > > Thanks > > > > -Avinash > > > > > > Just to confirm: this is using the extensible bucket hash in the > > > rte_table library of packet framework, rather than the standalone > > > rte_hash library, right? > > > > > > /Bruce > > > > Could you share detail on the two different keys used for lookups. In case > > if > > you are considering bidirectional packet flow between the source and > > destination, symmetric hash can be used- > > http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf > > > > Jasvinder
[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Venkateswara Rao > Thummala > Sent: Monday, August 17, 2015 7:06 PM > To: Yeddula, Avinash > Cc: dev at dpdk.org; Bly, Mike > Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > Hi Avinash, > > I think, you can use the same table by just updating the packet meta data > based on the Look UP. > In the first lookup, you can populate the meta data [key offset] with the > source MAC and in the second lookup, you can populate the same meta data > with the destination lookup. I think this should work. > > Thanks > Venkat > OneHop Networks Yes, should work, although probably this approach is not really required by the specific use-case. The two lookups in the same table are really one lookup and one add/update operation. > > On 17 August 2015 at 22:05, Yeddula, Avinash wrote: > > > + Mike ( My team mate) > > Hi Jasvinder, It's not a bidirectional packet flow. The pipeline looks > > something like this. > > > > Ingress port-Table 1 Table-2 - Mac_Table - Table4 > > Egress port. > > > > Before the frame goes reaches table 4, we do 2 lookups at the mac table. > > 1. src lookup ( To learn the MAC on the bridge) > > 2. dst lookup ( Flooding if dst MAC look up fails else Unicast/forward if > > dst lookup success). > > > > Here are the keys we are using. > > Src lookup key - Src MAC (src MAC in the frame) + Bridge ID ( Bridge on > > which it arrived). > > Dst lookup key - Dst MAC (dst MAC in the frame) + Bridge ID ( Bridge on > > which it arrived) > > > > > > Thanks > > -Avinash > > > > -Original Message- > > From: Singh, Jasvinder [mailto:jasvinder.singh at intel.com] > > Sent: Monday, August 17, 2015 7:00 AM > > To: Richardson, Bruce; Yeddula, Avinash > > Cc: dev at dpdk.org > > Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > > > > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce > Richardson > > > Sent: Friday, August 14, 2015 10:25 AM > > > To: Yeddula, Avinash > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > > > > > On Thu, Aug 13, 2015 at 05:37:21PM -0400, Yeddula, Avinash wrote: > > > > Any comments on this question ? > > > > > > > > Thanks > > > > -Avinash > > > > > > > > -Original Message- > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, > > > > Avinash > > > > Sent: Wednesday, August 12, 2015 3:04 PM > > > > To: dev at dpdk.org > > > > Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table. > > > > > > > > Hello All, > > > > > > > > I'm using DPDK extendable hash tables. This question is with respect > > > > to the > > > lookup aspect of the hash table. > > > > I see that there is just one "t->key_offset" that is pre-defined for > > > > the hash > > > table. I also understand that the frame needs to carry the "lookup_key > > > / keys" in the meta data. > > > > > > > > Here is my question: How to support more than one lookup with > > > > different > > > keys on the same frame on the same table. > > > > Use case: Src mac lookup and dst mac lookup on the same mac table. > > > > > > > > Thanks > > > > -Avinash > > > > > > Just to confirm: this is using the extensible bucket hash in the > > > rte_table library of packet framework, rather than the standalone > > > rte_hash library, right? > > > > > > /Bruce > > > > Could you share detail on the two different keys used for lookups. In case > > if you are considering bidirectional packet flow between the source and > > destination, symmetric hash can be used- > > http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf > > > > Jasvinder > >
[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, Avinash > Sent: Thursday, August 13, 2015 10:37 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. > > Any comments on this question ? > > Thanks > -Avinash > Sorry for my delay, Avinash, I was out of office for a few days. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, Avinash > Sent: Wednesday, August 12, 2015 3:04 PM > To: dev at dpdk.org > Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table. > > Hello All, > > I'm using DPDK extendable hash tables. This question is with respect to the > lookup aspect of the hash table. > I see that there is just one "t->key_offset" that is pre-defined for the hash > table. Just to avoid any confusion here implied by "pre-defined" statement, the key offset is definitely not hardcoded at build time; the key offset is configurable per each hash table instance when the hash table instance is initialized. Once set up for a particular hash table instance, it cannot be changed for that instance. Different hash table instances can have different values for this parameter. > I also understand that the frame needs to carry the "lookup_key / keys" in > the meta data. > > Here is my question: How to support more than one lookup with different > keys on the same frame on the same table. I agree with Venkat that one way of doing this is to do additional work of extracting the lookup key from the packet (which can have different format, depending on the point in the processing pipeline) and placing it at a fixed offset within the packet meta-data. This work can be done by: - the action handler defined for the input ports of the same pipeline that current table is part of - the action handler of a table in the same pipeline (located before the current table) - an action handler (of input port/output port/table) from a different pipeline instance (located before the current pipeline in the processing chain) I also agree with Mike Bly this is not the best way of doing things, and I don't think you actually need it, based on your use-case. Please see below for my suggestion. > Use case: Src mac lookup and dst mac lookup on the same mac table. Your use-case looks like classical L2 bridging. My understanding is: - you need to lookup the MAC destination in the MAC forwarding table: on lookup hit, unicast forward the frame on the port read from the hit table entry; on lookup hit, broadcast/flood the frame on all ports. - you also need to learn the MAC source, i.e. make sure you add the MAC source to the same MAC forwarding table to make the association of MAC address and the port where it is located for future lookups. As Jasvinder is pointing out, you do not really need to do a lookup of the MAC source in the table, what you need is to add the MAC source to the table. So one suggestion is to: - have a single lookup operation in the MAC forwarding table (based on MAC destination) - have the table action handler (or the input port action handler, or the output port action handler) to perform the add operation to the MAC forwarding table (add the MAC source as a new key to the table); the add operation is really an add/update, meaning that when the key is already present in the table, only the data associated with the key (i.e. the port where to forward the frame) is modified, which can be handy to pick up automatically the corner case of one station being moved from port A to port B (so one MAC address that previously showed up as being sourced on port A is not sourced by port B) You can also optimize things a bit to reduce the rate of add operations to the table, so you don't need to perform an add operation per frame: -have single lookup operation to table 1( MAC forwarding table), using the MAC destination as the lookup key -have single lookup operation to table 2 (MAC learning cache table, which can be a small LRU-based table used to record the most frequently MAC addresses encountered lately), using the MAC source as the lookup key: only add the current MAC source to table 1 (MAC forwarding table) on lookup miss in table 2 I am sure that other people have even better ideas for optimizations. > > Thanks > -Avinash
[dpdk-dev] Industry's Tiny and Powerful Wireless LAN Controller - Running On Intel NUC D34010WYKH - Built on DPDK
On Tue, 18 Aug 2015 13:33:00 +0530 Venkateswara Rao Thummala wrote: > Hi, > > We are happy to announce that, we have Just launched the Industry's Tiny > and Powerful Wireless LAN Controller - running on Intel NUC D34010WYKH. > > - Built on High Performance Virtual Data Plane, which is built using DPDK > - Supports wide range of Third Party Access Points > > Please visit our Website www.onehopnetworks.com for more details. > > Regards > Venkat > Founder & Chief Architect > OneHop Networks Pvt Ltd > [www.onehopnetworks.com] Congratulations. Do you plan to contribute code to help DPDK advance?
[dpdk-dev] ieee1588fwd.c implementation
Hi, alright, I'll look it up. Thanks for your help. Kind regards, Stefan. Am 17.08.2015 um 16:21 schrieb Mcnamara, John: >> -Original Message- >> From: Stefan Binna [mailto:stefan.binna at salzburgresearch.at] >> Sent: Monday, August 17, 2015 1:48 AM >> To: Mcnamara, John; dev at dpdk.org >> Subject: Re: [dpdk-dev] ieee1588fwd.c implementation >> >> Hi, >> >> I'm using the Intel NIC 82547L. >> Furthermore I'm using DPDK-2.0.0, the last stable download from the >> official homepage. >> >> Is there any method to "measure" the time the NIC takes to process the >> packet from the input port (e.g. port 0) to the output port (port 1)? >> Should be around 8 to 40 microseconds depending on the packet size? > > Hi Stefan, > > The RX/TX callbacks sample application looks closer to what you are looking > for: > > "The RX/TX Callbacks sample application is a packet forwarding application > that demonstrates the use of user defined callbacks on received and > transmitted > packets. The application performs a simple latency check, using callbacks, > to determine the time packets spend within the application". > > http://dpdk.org/doc/guides/sample_app_ug/rxtx_callbacks.html > > http://dpdk.org/browse/dpdk/tree/examples/rxtx_callbacks/main.c > > John.
[dpdk-dev] [PATCH v2]doc:Add performance test guide about how to get DPDK high perf on Intel platform
Thomas Could you review the v2 performance doc and apply if no issues? Thanks. Thanks Qian -Original Message- From: Xu, Qian Q Sent: Thursday, August 13, 2015 11:20 AM To: dev at dpdk.org Cc: Xu, Qian Q Subject: [dpdk-dev][PATCH v2]doc:Add performance test guide about how to get DPDK high perf on Intel platform v2 changes: 1. Create a svg picture. 2. Add part about how to check memory channel by dmidecode -t memory. 3. Add the command about how to check PCIe slot's speed. 4. Some doc updates according to the comments. Add a new guide doc under guides folder. This document is a step-by-step guide about how to get high performance with DPDK on Intel's platform and NICs. It is designed for users who are not familiar with DPDK but would like to measure the best performance. It contains step-by-step instructions to set the platform and NICs to its best performance. The document will add more sections with the DPDK features' increment. Signed-off-by: Qian Xu diff --git a/doc/guides/perf_test_guide/img/intel_perf_test_setup.svg b/doc/guides/perf_test_guide/img/intel_perf_test_setup.svg new file mode 100644 index 000..40bb189 --- /dev/null +++ b/doc/guides/perf_test_guide/img/intel_perf_test_setup.svg @@ -0,0 +1,467 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + width="744.09448819" + height="1052.3622047" + id="svg2" + version="1.1" + inkscape:version="0.48.5 r10040" + sodipodi:docname="perf_test_setup.svg"> + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + + + + +Flow1DEST MAC=Port0's MACDEST IP=2.1.1.1SRC IP: Random + +0 +1 + +X +X +Flow2DEST MAC=Port1's MACDEST IP=1.1.1.1SRC IP: Random + + + + +Ixia + + + +A +B + + + + + + +40G Ethernet +XL710 +IA PlatformSocket1 +Port0 --> Port1Port1 --> Port0 +XL710 +40G Ethernet + + diff --git a/doc/guides/perf_test_guide/index.rst b/doc/guides/perf_test_guide/index.rst new file mode 100644 index 000..25c8ee9 --- /dev/null +++ b/doc/guides/perf_test_guide/index.rst @@ -0,0 +1,47 @@ +.. BSD LICENSE +Copyright(c) 2010-2015 Intel Corporation. All rights reserved. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +* Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +* Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. +* Neither the name of Intel Corporation nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +Performance test guide on Intel's Platform +== + +|today| + +Contents + +.. toctree:: +:maxdepth: 2 +:numbered: + +intro +perf_test_intel_platform_nic + + + + diff --git a/doc/guides/perf_test_guide/intro.rst b/doc/guides/perf_test_guide/intro.rst new file mode 100644 index 000..471d15e --- /dev/null +++ b/doc/guides/perf_test_guide/intro.rst @@ -0,0 +1,40 @@ +.. BSD LICENSE +Copyright(c) 2010-2015 Intel Corporation. All rights reserved. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +* Redistr
