[dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)

2014-02-18 Thread Periklis Akritidis
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

[dpdk-dev] rte_eal_init independent from main(int argc, char** argv)

2014-02-18 Thread Periklis Akritidis
Hi Hamid, I do something similar and works fine. My compiler warning flags are more pedantic, so I have to ensure those strings are not const literals, but that doesn?t matter. I would appreciate an init that takes a struct with options too. On 18 Feb, 2014, at 8:57 pm, Hamid Ramazani wrote:

[dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)

2014-02-18 Thread Benson, Bryan
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 functio

[dpdk-dev] rte_eal_init independent from main(int argc, char** argv)

2014-02-18 Thread Hamid Ramazani
actually I've used: char* argv[] = {"./build/l2fwd","-c","ff","-n","4", NULL}; (NULL at the end of the list). Thanks. On 2/18/14, Hamid Ramazani wrote: > Hi, > I'm in need of running an open() function, that is part another program. > open() does many things, the very first of them is rte_eal_i

[dpdk-dev] rte_eal_init independent from main(int argc, char** argv)

2014-02-18 Thread Hamid Ramazani
Hi, I'm in need of running an open() function, that is part another program. open() does many things, the very first of them is rte_eal_init(argv, argc) I should not receive argc, and argv from main function of the program, but rather I should produce it myself. What I've done inside open() functi

[dpdk-dev] Receive queue full

2014-02-18 Thread François-Frédéric Ozog
Hi, I am bumping into a similar problem than the one explained here (https://www.mail-archive.com/e1000-devel at lists.sourceforge.net/msg07684.htm l): At some point in time, a receive queue gets "FULL" i.e. tail==head (reading the NIC registers) and the thread associated to that queue cannot retr

[dpdk-dev] Question on DPDK multi-process support

2014-02-18 Thread Mauro Annarumma
Hi Bruce, just for dispel any doubt: if there is one primary process and N secondary processes, and each process uses only one logical core (they have a coremask equal to 0x01, 0x02, 0x04, ), I can run at the same time at most "my CPU logical cores - 1" secondary processes. Is it right?

[dpdk-dev] Question on DPDK multi-process support

2014-02-18 Thread Richardson, Bruce
If you disable mempool caches, you may be able to run more processes than you have cores, but other issues with duplicate core id's might arise, and your application performance will suffer as the memory pools will be very significantly slower. However, there is no requirement that the lcore_id

[dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)

2014-02-18 Thread Mario Gianni
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 b