[dpdk-dev] Too verbose PMD init logs - intended or not?
Hello, I found that the following commit and post are conflicting with each other: 1) http://dpdk.org/browse/dpdk/commit/?id=23f91f32f2b119f1376488d87be2b80b078a945e 2) http://dpdk.org/ml/archives/dev/2015-April/016361.html Is there a consensus on how verbose PMD init processes should be? (i.e., Is this an intended behavior or a bug?) I'd like to see if my ports are initialized, but not what memory addresses they are attached for each ring. (Most of PMD init logs are only useful when debugging!) My configuration (.config) says CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n and my program explicitly set the debug level to INFO by calling rte_set_log_level(), but *still* the ixgbe pmd generates a lot of PMD_INIT_LOG(DEBUG, ...) messages. For workaround, I'm currently roll-backing the commit 23f91f3 manually for my build and then it becomes silent. Thanks, Joongi
[dpdk-dev] Too verbose PMD init logs - intended or not?
Thanks for quick reply. I have been using the v2.0.0 release branch, and switching to the master eliminates the issue. - Joongi On Wed, May 13, 2015 at 6:14 PM Thomas Monjalon wrote: > Hi, > > 2015-05-13 08:47, Joongi Kim: > > Hello, > > I found that the following commit and post are conflicting with each > other: > > 1) > > > http://dpdk.org/browse/dpdk/commit/?id=23f91f32f2b119f1376488d87be2b80b078a945e > > 2) http://dpdk.org/ml/archives/dev/2015-April/016361.html > > Is there a consensus on how verbose PMD init processes should be? > > (i.e., Is this an intended behavior or a bug?) > > Yes, debug logs should use the debug level. Simple :) > > > I'd like to see if my ports are initialized, but not what memory > addresses > > they are attached for each ring. (Most of PMD init logs are only useful > > when debugging!) > > > > My configuration (.config) says CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT=n and > my > > program explicitly set the debug level to INFO by calling > > rte_set_log_level(), but *still* the ixgbe pmd generates a lot of > > PMD_INIT_LOG(DEBUG, ...) messages. > > I guess you are not using the HEAD. > This commit should solve your problem: > http://dpdk.org/browse/dpdk/commit/?id=23e4bf20a16d34 > > > For workaround, I'm currently roll-backing the commit 23f91f3 manually > for > > my build and then it becomes silent. > > Please confirm it's fixed in HEAD. >
[dpdk-dev] [PATCH] mbuf & mempool: explicit typecast on function return
I already have fixed this issue at http://dpdk.org/dev/patchwork/patch/6068/
.
There is another issue related to "underlying type" for enum declarations
http://dpdk.org/dev/patchwork/patch/6067/, for C++11 compilers.
In the second patch I missed updating headers for architectures other than
x86,
so it needs to be updated before applying to the master branch.
It would be great for me to have this fixed on the master branch,
as I am manually applying above patches whenever I pull the latest codes.
Regards,
Joongi
2015? 8? 17? (?) ?? 5:15, Olivier MATZ ?? ??:
> Hi Sergey,
>
> On 08/12/2015 11:11 AM, Sergey Balabanov wrote:
> > When DPDK is being compiled in C++ project using g++ then
> > 'invalid conversion from' error appears. Added explicit
> > typecast on function return to get rid of the error.
> >
> > Signed-off-by: Sergey Balabanov
>
>
> Fixes: 7755baae8378 ("mbuf: silence warning on pointer arithmetic")
> Fixes: 6cf14ce4ce6c ("mempool: silence warning on pointer arithmetic")
>
> Acked-by: Olivier Matz
>
> Thanks
>
[dpdk-dev] [PATCH 2/2] eal: Fix compilation on C++
* Forward declaration of enum in C++ requires explicit underlying
type definitions.
* This fixes the issue at:
http://dpdk.org/ml/archives/dev/2015-April/017065.html
Signed-off-by: Joongi Kim
---
lib/librte_eal/common/include/arch/x86/rte_cpuflags.h | 4 ++--
lib/librte_eal/common/include/generic/rte_cpuflags.h | 12 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
index dd56553..df1834c 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
@@ -45,7 +45,7 @@ extern "C" {
#include "generic/rte_cpuflags.h"
-enum rte_cpu_flag_t {
+enum rte_cpu_flag_t __RTE_CPUFLAG_UNDERLYING_TYPE {
/* (EAX 01h) ECX features*/
RTE_CPUFLAG_SSE3 = 0, /**< SSE3 */
RTE_CPUFLAG_PCLMULQDQ, /**< PCLMULQDQ */
@@ -150,7 +150,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_NUMFLAGS, /**< This should always be the
last! */
};
-enum cpu_register_t {
+enum cpu_register_t __RTE_REGISTER_UNDERLYING_TYPE {
RTE_REG_EAX = 0,
RTE_REG_EBX,
RTE_REG_ECX,
diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h
b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index 61c4db1..5352cbc 100644
--- a/lib/librte_eal/common/include/generic/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h
@@ -44,15 +44,23 @@
#include
#include
+#ifdef __cplusplus
+#define __RTE_CPUFLAG_UNDERLYING_TYPE : unsigned int
+#define __RTE_REGISTER_UNDERLYING_TYPE : unsigned int
+#else
+#define __RTE_CPUFLAG_UNDERLYING_TYPE
+#define __RTE_REGISTER_UNDERLYING_TYPE
+#endif
+
/**
* Enumeration of all CPU features supported
*/
-enum rte_cpu_flag_t;
+enum rte_cpu_flag_t __RTE_CPUFLAG_UNDERLYING_TYPE;
/**
* Enumeration of CPU registers
*/
-enum cpu_register_t;
+enum cpu_register_t __RTE_REGISTER_UNDERLYING_TYPE;
typedef uint32_t cpuid_registers_t[4];
--
1.9.1
[dpdk-dev] [PATCH 1/2] lib: Fix pointer arithmetic for C++
* C++ requires explicit conversion of void pointer types to other
pointer types.
* This issue was introduced by previous commits 6cf14ce4 and 7755baae8.
Two subsequent commits 2f935c12 and 7621d6a also have the same issue,
I did not fix them because they are NOT headers potentially included
by C++ sources.
Signed-off-by: Joongi Kim
---
lib/librte_malloc/malloc_elem.h | 4 ++--
lib/librte_mbuf/rte_mbuf.h | 2 +-
lib/librte_mempool/rte_mempool.c | 2 +-
lib/librte_mempool/rte_mempool.h | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/librte_malloc/malloc_elem.h b/lib/librte_malloc/malloc_elem.h
index 9790b1a..2b18d06 100644
--- a/lib/librte_malloc/malloc_elem.h
+++ b/lib/librte_malloc/malloc_elem.h
@@ -124,10 +124,10 @@ malloc_elem_from_data(const void *data)
if (data == NULL)
return NULL;
- struct malloc_elem *elem = RTE_PTR_SUB(data, MALLOC_ELEM_HEADER_LEN);
+ struct malloc_elem *elem = (struct malloc_elem *) RTE_PTR_SUB(data,
MALLOC_ELEM_HEADER_LEN);
if (!malloc_elem_cookies_ok(elem))
return NULL;
- return elem->state != ELEM_PAD ? elem: RTE_PTR_SUB(elem, elem->pad);
+ return elem->state != ELEM_PAD ? elem: (struct malloc_elem *)
RTE_PTR_SUB(elem, elem->pad);
}
/*
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 8a2cae1..4fc770b 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -348,7 +348,7 @@ static inline uint16_t rte_pktmbuf_priv_size(struct
rte_mempool *mp);
static inline struct rte_mbuf *
rte_mbuf_from_indirect(struct rte_mbuf *mi)
{
- return RTE_PTR_SUB(mi->buf_addr, sizeof(*mi) + mi->priv_size);
+ return (struct rte_mbuf *) RTE_PTR_SUB(mi->buf_addr, sizeof(*mi) +
mi->priv_size);
}
/**
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 02699a1..e22ddb3 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -136,7 +136,7 @@ mempool_add_elem(struct rte_mempool *mp, void *obj,
uint32_t obj_idx,
obj = (char *)obj + mp->header_size;
/* set mempool ptr in header */
- hdr = RTE_PTR_SUB(obj, sizeof(*hdr));
+ hdr = (struct rte_mempool_objhdr *) RTE_PTR_SUB(obj, sizeof(*hdr));
hdr->mp = mp;
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 6d4ce9a..7c966a1 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -262,13 +262,13 @@ struct rte_mempool {
/* return the header of a mempool object (internal) */
static inline struct rte_mempool_objhdr *__mempool_get_header(void *obj)
{
- return RTE_PTR_SUB(obj, sizeof(struct rte_mempool_objhdr));
+ return (struct rte_mempool_objhdr *) RTE_PTR_SUB(obj, sizeof(struct
rte_mempool_objhdr));
}
/* return the trailer of a mempool object (internal) */
static inline struct rte_mempool_objtlr *__mempool_get_trailer(void *obj)
{
- return RTE_PTR_SUB(obj, sizeof(struct rte_mempool_objtlr));
+ return (struct rte_mempool_objtlr *) RTE_PTR_SUB(obj, sizeof(struct
rte_mempool_objtlr));
}
/**
--
1.9.1
[dpdk-dev] [PATCH 00/17] Enhance mlx5 with Mellanox OFED 3.1
My laboratory (an.kaist.ac.kr) had tried to build a native kernel driver for mlx4 a few months ago, and sent the full patch to the patchwork system: http://dpdk.org/dev/patchwork/patch/6128/ This driver supports only minimal RX/TX of packets, and many standard features such as VLAN are missing. The major technical difficulty was to make a memory region that is persistent even when the user process terminates. We have sent another patch for this: http://dpdk.org/dev/patchwork/patch/6127/ Nonetheless, we abandoned this approach, because the new mlx4 PMD based on OFED 3.0 performed almost same or better than our native driver with an almost complete feature set. Still, I believe that there are rooms to improve/optimize the native driver but we just do not have enough human resources for that. In background, we tried to publish a academic paper about an automated convertor from Linux NIC drivers to DPDK poll-mode drivers, but unfortunately this project is being hold back now. Regards, Joongi 2015? 10? 6? (?) ?? 5:54, Stephen Hemminger ?? ??: > On Mon, 5 Oct 2015 19:54:35 +0200 > Adrien Mazarguil wrote: > > > Mellanox OFED 3.1 [1] comes with improved APIs that Mellanox ConnectX-4 > > (mlx5) adapters can take advantage of, such as: > > > > - Separate post and doorbell operations on all queues. > > - Lightweight RX queues called Work Queues (WQs). > > - Low-level RSS indirection table and hash key configuration. > > > > This patchset enhances mlx5 with all of these for better performance and > > flexibility. Documentation is updated accordingly. > > Has anybody explored doing a driver without the dependency on OFED? > It is certainly possible. The Linux kernel drivers don't depend on it. > And dropping OFED would certainly be faster. >
[dpdk-dev] Is there any example application to used DPDK packet distributor library?
Hello, DPDK already provides a number of example applications: http://dpdk.org/browse/dpdk/tree/examples You may find my projects to be useful as well: https://github.com/anlab-kaist/pspgen-dpdk & https://github.com/anlab-kaist/NBA ps. DPDK is not a packet "distributor" library but more close to "packet I/O" library with a lot of utilities, as it not only does packet RX but also packet TX. (the major usage pattern is to receive, process, and then forward packets.) Regards, Joongi 2015? 9? 30? (?) ?? 2:45, ??? ?? ??: > Dear DPDK experts. > > I am Ick-Sung Choi living in South Korea. > > I have a question about DPDK? packet distributor library. > > Is there any example application to used DPDK packet distributor library? > > I am trying to experiment simple function using DPDK packet distributor > library. > > If I can study an example application of DPDK packet distributor library, > it would be very helpful for my experiment. > > I will appreciate if I can be given any example applications, advice, and > information. > > Thank you very much. > > Sincerely Yours, > > Ick-Sung Choi. > >
