rte_pktmbuf_alloc() is returning same address on two consecutive calls
Hi Team,
In my dpdk application, I am facing an issue where rte_pktmbuf_alloc() is
returning same address for two consecutive calls in a single thread context.
Following is the code snippet,
int Func(struct rte_mbuf *mblk)
{
struct rte_mbuf *tmpbuf = nullptr;;
struct rte_mbuf *copybuf = nullptr;
char *nextPtr = NULL;
tmpbuf = rte_pktmbuf_alloc(mbuf_pool);
nextPtr = rte_pktmbuf_append(tmpbuf, IPV4_HDR_LEN);
//update some info on nextptr
copybuf = rte_pktmbuf_copy(mblk, mbuf_pool, 0, pkt_len);
return 0;
}
With the above snippet, 'tmpbuf' and 'copybuf' which are getting allocated from
same pool (mbuf_pool), pointing to same address, Due to this tmpbuf which gets
allocated first, and further populated, is getting over written inside
rte_pktmbuf_copy() call which is not expected .
When I further debug , rte_pktmbuf_copy() is internally using
rte_pktmbuf_alloc() to get the free buffer from mbuf_pool and copy the data
from mblk.
Please let us know if there is any known issue with rte_pktmbuf_alloc(), and
why it may be giving same address on two consecutive calls.
Regards,
Nagendra
Queries on DPDK Trace Library usage
Hi Team / Jerin,
I am trying to use DPDK Trace Library functionality in my DPDK application.
I've successfully observed the trace files being generated by invoking
rte_trace_save(), particularly when utilizing the EAL option '--trace=.*'
I found following statement in the programmer guide,
The trace memory will be allocated through an internal function
__rte_trace_mem_per_thread_alloc(). The trace memory will be allocated per
thread to enable lock less trace-emit function.
For non lcore threads, the trace memory is allocated on the first trace
emission.
For lcore threads, if trace points are enabled through a EAL option, the trace
memory is allocated when the threads are known of DPDK (rte_eal_init for EAL
lcores, rte_thread_register for non-EAL lcores). Otherwise, when trace points
are enabled later in the life of the application, the behavior is the same as
non lcore threads and the trace memory is allocated on the first trace emission.
I attempted to enable trace points at runtime using the
'rte_trace_regexp("lib.mempool.*", true)' API, though I'm unsure if this is the
correct approach. While the call appears to succeed, I'm puzzled by the absence
of any trace files being generated even after invoking rte_trace_save().
When adding a new trace point in my application code as per the documentation,
I used rte_trace_regexp("myapp.trace.test", true) to enable it. However, I
encountered a failure when attempting to look up the API.
Apr 22 09:53:07.486 [USDP] [DPDK] EAL: rte_trace_regexp():207 NAG1:inside
rte_trace_regexp
Apr 22 09:53:07.486 [USDP] [DPDK] EAL: rte_trace_regexp():212 NAG2:inside
rte_trace_regexp
Apr 22 09:53:07.486 [USDP] [DPDK] EAL: rte_trace_regexp():231 NAG4:inside
rte_trace_regexp
Apr 22 09:53:07.486 [USDP] ***NAG***: DPDK-TRACE:rte_trace_regexp failed
I have the following queries,
1. How to enable/disable the trace files runtime in a dpdk application?
2. How to trigger new trace points added in the application code?
Regards,
Nagendra
RE: [External] : Re: rte_pktmbuf_alloc() is returning same address on two consecutive calls
Hi Stephen/Team,
Thanks for the inputs, After debugging deep into the code get to know that, in
my application code I am trying to do double free of same mbuf in certain
condition.
in my case, I didn't enable RTE_DEBUG_MBUF macro, so rte_alloc or free api's
not performing rte_mbuf_sanity_check(), as a result the same mbuf address is
getting added twice to the cache list.
I don't want to enable the MBUF DEBUG flag for my application and run (as is
cause performance impact). I am trying to find out minimal check that is enough
to avoid the double free of buffer, I checked the ref_cnt of the mbuf just
before freeing it second time, its given as '1', Is this expected?
Please, suggest is there any minimal checking that will help to avoid double
free.
Regards,
Nagendra
-Original Message-
From: Stephen Hemminger
Sent: Thursday, February 23, 2023 11:31 PM
To: NAGENDRA BALAGANI
Cc: dev@dpdk.org; Kapil Kumar Jain ; Ramakamesh
Duvvuri
Subject: [External] : Re: rte_pktmbuf_alloc() is returning same address on two
consecutive calls
On Thu, 23 Feb 2023 14:54:13 +
NAGENDRA BALAGANI wrote:
> Hi Team,
>
> In my dpdk application, I am facing an issue where rte_pktmbuf_alloc() is
> returning same address for two consecutive calls in a single thread context.
>
> Following is the code snippet,
>
> int Func(struct rte_mbuf *mblk)
> {
> struct rte_mbuf *tmpbuf = nullptr;;
> struct rte_mbuf *copybuf = nullptr;
> char *nextPtr = NULL;
>
> tmpbuf = rte_pktmbuf_alloc(mbuf_pool);
>
> nextPtr = rte_pktmbuf_append(tmpbuf, IPV4_HDR_LEN);
> //update some info on nextptr
>
> copybuf = rte_pktmbuf_copy(mblk, mbuf_pool, 0, pkt_len);
>
>
> return 0;
> }
>
> With the above snippet, 'tmpbuf' and 'copybuf' which are getting allocated
> from same pool (mbuf_pool), pointing to same address, Due to this tmpbuf
> which gets allocated first, and further populated, is getting over written
> inside rte_pktmbuf_copy() call which is not expected .
> When I further debug , rte_pktmbuf_copy() is internally using
> rte_pktmbuf_alloc() to get the free buffer from mbuf_pool and copy the data
> from mblk.
>
> Please let us know if there is any known issue with rte_pktmbuf_alloc(), and
> why it may be giving same address on two consecutive calls.
>
> Regards,
> Nagendra
>
Most likely your mbuf pool has gotten corrupted before you get to that code.
Try building with the config options for POOL and MBUF debug.
