From: "Mario Gianni" <m.gianni-Gbsd49wXnelWk0Htik3J/w@public.gmane.org>
To: "Benson,
Bryan"
<bmbenson-vV1OtcyAfmbQT0dZR+AlfA@public.gmane.org>,"Periklis
Akritidis" <akritid-wlH+TjtWvpzuufBYgWm87A@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org
Subject: Re: problem with rte_pktmbuf_prepend (possible bug?)
Date: Wed, 19 Feb 2014 09:04:33 -0500 [thread overview]
Message-ID: <20140219140433.259460@gmx.com> (raw)
This is my init function:
pktmbuf_pool[socketid] = rte_mempool_create(
name,
APP_DEFAULT_MEMPOOL_BUFFERS,
APP_DEFAULT_MBUF_SIZE,
APP_DEFAULT_MEMPOOL_CACHE_SIZE,
sizeof(struct rte_pktmbuf_pool_private),
rte_pktmbuf_pool_init, NULL,
rte_pktmbuf_init, NULL,
socketid,
0);
I copied it from a sample code.
Anyway it seems to me that mbuf_free does not reset the *data pointer, actually I have partially resolved by prepending manually the data without moving the * data pointer at all albeit it's not a very clean solution.
Could this be a bug in the DPDK mbuf_free() function?
----- Original Message -----
From: Benson, Bryan
Sent: 02/18/14 06:16 PM
To: Periklis Akritidis, Mario Gianni
Subject: RE: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)
Whoa, be careful, we used a custom init function and had a nasty bug because we assumed it was called on mbuf_free as well. The rte_pktmbuf_init function pointer passed into mempool create is only used at pool initialization time, not when an mbuf is freed - A reference to the obj_initi function is not stored anywhere for future use during mbuf_free. Some of the fields are reset when the NIC has completed the send of the mbufs, but it does not use a custom function ptr. Thanks, Bryan Benson ________________________________________ From: dev [dev-bounces-VfR2kkLFssw@public.gmane.org] on behalf of Periklis Akritidis [akritid-wlH+TjtWvpzuufBYgWm87A@public.gmane.org] Sent: Tuesday, February 18, 2014 6:19 AM To: Mario Gianni Cc: dev-VfR2kkLFssw@public.gmane.org Subject: Re: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) Hi Mario, Are you passing rte_pktmbuf_init as the obj_init argument to rte_mempool_create? It is called when the mbuf if freed and it will reset the fields. I vaguely remember I had the same issue at some point and resolved it somehow. This comes to mind. Cheers, Periklis On 18 Feb, 2014, at 6:27 pm, Mario Gianni <m.gianni-Gbsd49wXnelWk0Htik3J/w@public.gmane.org> wrote: > Hi all, I'm experimenting some code with DPDK v1.5.0 and I have the following problem: > > I have a thread that receives packets from NIC, once I received a packet I want to prepend some data to it and I try to do so through the function rte_pktmbuf_prepend() > then the packet is enqueued in a ring buffer where it will be used by a client thread before being dropped through the function rte_pktmbuf_free() called by the client thread. > > Now, if I try to send packets to this program I have the following behaviour: > In a first time it seems to work correctly, then after a certain number of received packets (approximately the same number as the number of mbufs present in the mempool) if I call the rte_pktmbuf_headroom it returns that the headroom is shrinking more than the expected, until after a certain number of packets the headroom goes to zero. > > It seems like that when I call the rte_pktmbuf_free() function it doesn't reset the data position inside the mbuf, so when I call for a second time the mbuf the headroom continues to shrink until it finishes. > > > Do you have any idea of this strange behaviour?Could it be a bug in the prepend/free function? > > > Thank you, > > Mario
next reply other threads:[~2014-02-19 14:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-19 14:04 Mario Gianni [this message]
[not found] ` <20140219140433.259460-KK0ffGbhmjU@public.gmane.org>
2014-02-19 17:32 ` problem with rte_pktmbuf_prepend (possible bug?) Ananyev, Konstantin
-- strict thread matches above, loose matches on Subject: below --
2014-02-18 10:27 Mario Gianni
[not found] ` <20140218102749.270040-KK0ffGbhmjU@public.gmane.org>
2014-02-18 14:19 ` Periklis Akritidis
[not found] ` <78841534-98AB-4845-9FAF-CAC975D15D3A-wlH+TjtWvpzuufBYgWm87A@public.gmane.org>
2014-02-18 17:16 ` Benson, Bryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140219140433.259460@gmx.com \
--to=m.gianni-gbsd49wxnelwk0htik3j/w@public.gmane.org \
--cc=akritid-wlH+TjtWvpzuufBYgWm87A@public.gmane.org \
--cc=bmbenson-vV1OtcyAfmbQT0dZR+AlfA@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.