[dpdk-dev] SSSE3 instruction set not enabled ERROR - use msse4.2

[Masaru Oki]

Hi,
What is your build environment (processor)?
I got same error with AMD Phoenom II, doesn't have SSSE3 instruction.


2014-09-05 22:23 GMT+09:00 Raj Ravi :

> Hi,
> I was facing this error:
> "SSSE3 instruction set not enabled" while building dpdk.
>
> Using the following commands:
> make config  T=x86_64-native-linuxapp-gcc
> make install  T=x86_64-native-linuxapp-gcc
>
> So, again I tried like this :
> make configT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"
> make installT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"
>
> Now, the build goes through.
> Is This method correct  to follow ?
>
> Thanks
>

[dpdk-dev] SSSE3 instruction set not enabled ERROR - use msse4.2

[Raj Ravi]

cpuinfo:
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 4
model name : AMD Phenom(tm) II X4 955 Processor
stepping : 3
microcode : 0x1c8
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit
wdt hw_pstate npt lbrv svm_lock nrip_save
bogomips : 6399.94
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
===

Fedora 20  - 3.15.10 default Fedora kernel  used.

===

I have built dpdk-1.7.0 and faced this error.
I have tried building dpdk-1.7.1 , but faced the same error.


Only after adding msse4.2, this errors goes away.


Thanks



On Fri, Sep 5, 2014 at 7:10 PM, Masaru Oki  wrote:
> Hi,
> What is your build environment (processor)?
> I got same error with AMD Phoenom II, doesn't have SSSE3 instruction.
>
>
> 2014-09-05 22:23 GMT+09:00 Raj Ravi :
>>
>> Hi,
>> I was facing this error:
>> "SSSE3 instruction set not enabled" while building dpdk.
>>
>> Using the following commands:
>> make config  T=x86_64-native-linuxapp-gcc
>> make install  T=x86_64-native-linuxapp-gcc
>>
>> So, again I tried like this :
>> make configT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"
>> make installT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"
>>
>> Now, the build goes through.
>> Is This method correct  to follow ?
>>
>> Thanks
>
>

[dpdk-dev] dpdk 1.6 insmod rte_kni error

[rong wen]

Hi All,

I am a new guy to use dpdk. The kernel version is 2.6.32.

After I build the rte_kni.ko, I run insmod rte_kni.ko, error message is:

Unloading any existing DPDK KNI module
Loading DPDK KNI module
insmod: error inserting
'/home/wenrong.wr/dpdk_dev_r1-6-0/x86_64-default-linuxapp-gcc/kmod/rte_kni.ko':
-1 Unknown symbol in module
## ERROR: Could not load kmod/rte_kni.ko.

The dmesg output is:

[181831.351549] rte_kni: Unknown symbol hwmon_device_register
[181831.353671] rte_kni: Unknown symbol hwmon_device_unregister
[182558.257153] rte_kni: Unknown symbol hwmon_device_register
[182558.259288] rte_kni: Unknown symbol hwmon_device_unregister


Thank you.

Rong

[dpdk-dev] [PATCH] pcap: set in_port value in packet mbuf data when each packet is received

[Saori USAMI]

The pkt.in_port parameter in mbuf should be set with an input port id
because DPDK apps may use it to know where each packet came from.

Signed-off-by: Saori USAMI 
---
 lib/librte_pmd_pcap/rte_eth_pcap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/librte_pmd_pcap/rte_eth_pcap.c 
b/lib/librte_pmd_pcap/rte_eth_pcap.c
index eebe768..cfd3de4 100644
--- a/lib/librte_pmd_pcap/rte_eth_pcap.c
+++ b/lib/librte_pmd_pcap/rte_eth_pcap.c
@@ -63,6 +63,7 @@ static uint64_t hz;

 struct pcap_rx_queue {
pcap_t *pcap;
+   uint8_t in_port;
struct rte_mempool *mb_pool;
volatile unsigned long rx_pkts;
volatile unsigned long err_pkts;
@@ -154,6 +155,7 @@ eth_pcap_rx(void *queue,
rte_memcpy(mbuf->pkt.data, packet, header.len);
mbuf->pkt.data_len = (uint16_t)header.len;
mbuf->pkt.pkt_len = mbuf->pkt.data_len;
+   mbuf->pkt.in_port = pcap_q->in_port;
bufs[num_rx] = mbuf;
num_rx++;
} else {
@@ -373,6 +375,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
struct pcap_rx_queue *pcap_q = >rx_queue[rx_queue_id];
pcap_q->mb_pool = mb_pool;
dev->data->rx_queues[rx_queue_id] = pcap_q;
+   pcap_q->in_port = dev->data->port_id;
return 0;
 }

-- 
1.9.1

[dpdk-dev] SSSE3 instruction set not enabled ERROR - use msse4.2

[Raj Ravi]

Hi,
I was facing this error:
"SSSE3 instruction set not enabled" while building dpdk.

Using the following commands:
make config  T=x86_64-native-linuxapp-gcc
make install  T=x86_64-native-linuxapp-gcc

So, again I tried like this :
make configT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"
make installT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"

Now, the build goes through.
Is This method correct  to follow ?

Thanks

[dpdk-dev] Are there considerations about resource recycling by the process, not by the OS?

[Tetsuya.Mukawa]

Hi Zhangkun,

Do you talk about resource management of DPDK when a process is finished?
If so, I guess DPDK doesn't care so much about freeing resources once
allocated by the process.
For example, there is no function to free a mempool.

Thanks,
Tetsuya

(2014/09/05 12:39), Zhangkun (K) wrote:
> Hi,
> Yes, the program is running as root.
> I want to know if or not the DPDK Community considers about resource 
> recycling.
>
> From: Masaru Oki [mailto:m-oki at stratosphere.co.jp]
> Date: 2014?9?5? 11:18
> To: Zhangkun (K)
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Are there considerations about resource recycling by 
> the process, not by the OS?
>
> Hi,
>
> you may try
>  $ gdb your_program
>  gdb> b rte_panic
>  gdb> run
>  stopped at rte_panic
>  gdb> bt
>
> sorry, it is not answer for your question.
> by the way, do you run the program as root?
>
>
> 2014-09-05 12:07 GMT+09:00 Zhangkun (K)  huawei.com>:
> Hi,
>I develop the program with the use of dpdk and the process is core dump 
> when the program is started.
> The process is crash in case of initing memory failed and calling rte_panic 
> function.
>  I search all rte_panic function in the dpdk, and find it so many. Therefore, 
> in case the pr ocess happen fail,
> it will abort. The resource allocated before is not released by the process, 
> but by the OS system.
> So I have a question: Are there considerations about resource recycling by 
> the process, not by the OS ?
>

[dpdk-dev] rte_lpm_add in librte_lpm

[Jan Sacha]

Hi,

I've been playing with DPDK and I got some crashes in the LPM module. As 
far as I know, this problem has not been reported yet. These crashes 
happened in DPDK 1.7.0 and 1.6.0r2 (I didn't check other versions) when 
I added new LPM routes.

In the lib/librte_lpm/rte_lpm.c file, line 399 (add_depth_small 
function), there is the following condition:

if (!lpm->tbl24[i].valid || (lpm->tbl24[i].ext_entry == 0 && 
lpm->tbl24[i].depth <= depth))

If the new route has a lower depth than an existing non-extended entry, 
this condition is not met. We then skip to line 418, where we assume the 
entry is extended and use an uninitialized index. Is this a bug?

Thanks,
Jan

[dpdk-dev] [PATCH v2 6/6] mbuf: flatten struct vlan_macip into mbuf struct

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, August 28, 2014 4:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 6/6] mbuf: flatten struct vlan_macip into
> mbuf struct
> 
> The vlan_macip structure combined a vlan tag id with l2 and l3 headers
> lengths for tracking offloads. However, this structure was only used as
> a unit by the e1000 and ixgbe drivers, not generally.
> 
> This patch removes the structure from the mbuf header and places the
> fields into the mbuf structure directly at the required point, without
> any net effect on the structure layout. This allows us to treat the vlan
> tags and header length fields as separate for future mbuf changes. The
> drivers which were written to use the combined structure still do so,
> using a driver-local definition of it.
> 
> Changes in V2:
> * None
> 
> Signed-off-by: Bruce Richardson 

After applying this patch, I see a performance degradation (around 5%) using 
testpmd with the default RX path, so this may require a v3 patch.

Thanks,
Pablo

[dpdk-dev] [PATCH v3 4/6] mbuf: remove the rte_pktmbuf structure

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, September 04, 2014 2:26 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3 4/6] mbuf: remove the rte_pktmbuf
> structure
> 
> From: Olivier Matz 
> 
> The rte_pktmbuf structure was initially included in the rte_mbuf
> structure. This was needed when there was 2 types of mbuf (ctrl and
> packet). As the control mbuf has been removed, we can merge the
> rte_pktmbuf into the rte_mbuf structure.
> 
> Advantages of doing this:
>   - the access to mbuf fields is easier (ex: m->data instead of m->pkt.data)
>   - make the structure more consistent: for instance, there was no reason
> to have the ol_flags field in rte_mbuf
>   - it will allow a deeper reorganization of the rte_mbuf structure in the
> next commits, allowing to gain several bytes in it
> 
> Signed-off-by: Olivier Matz 
> 
> Updated to work with latest code, and to include new example apps.
> 
> Changes in V2:
> * Further updates to apply to latest HEAD on master
> 
> Changes in V3:
> * Updated to compile cleanly on 1.7.1
> 
> Signed-off-by: Bruce Richardson 

Acked-by Pablo de Lara 

[dpdk-dev] [PATCH v2 5/6] mbuf: rename in_port to just port

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, August 28, 2014 4:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 5/6] mbuf: rename in_port to just port
> 
> In some cases we may want to tag a packet for a particular destination
> or output port, so rename the "in_port" field in the mbuf to just "port"
> so that it can be re-used for this purpose if an application needs it.
> 
> Changes in V2:
> * Further updates to apply to latest HEAD on master
> 
> Signed-off-by: Bruce Richardson 

Acked-by Pablo de Lara 

[dpdk-dev] [PATCH v2 4/6] mbuf: remove the rte_pktmbuf structure

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, August 28, 2014 4:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 4/6] mbuf: remove the rte_pktmbuf
> structure
> 
> From: Olivier Matz 
> 
> The rte_pktmbuf structure was initially included in the rte_mbuf
> structure. This was needed when there was 2 types of mbuf (ctrl and
> packet). As the control mbuf has been removed, we can merge the
> rte_pktmbuf into the rte_mbuf structure.
> 
> Advantages of doing this:
>   - the access to mbuf fields is easier (ex: m->data instead of m->pkt.data)
>   - make the structure more consistent: for instance, there was no reason
> to have the ol_flags field in rte_mbuf
>   - it will allow a deeper reorganization of the rte_mbuf structure in the
> next commits, allowing to gain several bytes in it
> 
> Signed-off-by: Olivier Matz 
> 
> Updated to work with latest code, and to include new example apps.
> 
> Changes in V2:
> * Further updates to apply to latest HEAD on master
> 
> Signed-off-by: Bruce Richardson 

Acked-by Pablo de Lara 

[dpdk-dev] [PATCH v2 3/6] mbuf: remove rte_ctrlmbuf

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, August 28, 2014 4:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 3/6] mbuf: remove rte_ctrlmbuf
> 
> From: Olivier Matz 
> 
> The initial role of rte_ctrlmbuf is to carry generic messages (data
> pointer + data length) but it's not used by the DPDK or it applications.
> Keeping it implies:
>   - loosing 1 byte in the rte_mbuf structure
>   - having some dead code rte_mbuf.[ch]
> 
> This patch removes this feature. Thanks to it, it is now possible to
> simplify the rte_mbuf structure by merging the rte_pktmbuf structure
> in it. This is done in next commit.
> 
> Signed-off-by: Olivier Matz 
> 
> * Updated patch to HEAD.
> * Modified patch to retain the old function names for ctrl mbufs as
>   macros. This helps with app compatibility, and allows the concept
>   of a control mbuf to be reintroduced via a single-bit flag in
>   a future change.
> * Updated the packet framework ip_pipeline example application to
>   work following this change.
> 
> Changes in v2:
> * Fixed whitespace errors introduced by this patch flagged by checkpatch
> 
> Signed-off-by: Bruce Richardson 

Acked-by Pablo de Lara 

[dpdk-dev] [PATCH v2 2/6] mbuf: rename RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, August 28, 2014 4:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 2/6] mbuf: rename
> RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT
> 
> From: Olivier Matz 
> 
> It seems that RTE_MBUF_SCATTER_GATHER is not the proper name for the
> feature it provides. "Scatter gather" means that data is stored using
> several buffers. RTE_MBUF_REFCNT seems to be a better name for that
> feature as it provides a reference counter for mbufs.
> 
> The macro RTE_MBUF_SCATTER_GATHER is poisoned to ensure this
> modification is seen by drivers or applications using it.
> 
> Changes in V2:
> * None
> 
> Signed-off-by: Olivier Matz 
> Signed-off-by: Bruce Richardson 

Acked-by Pablo de Lara 

[dpdk-dev] [PATCH v2 1/6] ixgbe: put only non-zero initializer in definition

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, August 28, 2014 4:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 1/6] ixgbe: put only non-zero initializer in
> definition
> 
> Since all unspecified fields in an initializer are assumed to be zero we
> can simplify the empty mbuf definition in the vector driver to only use
> the fields that are non-zero, i.e. just nb_segs = 1. This makes things
> shorter and means that the structure doesn't need as many updates for
> other fields being renamed or moved.
> 
> The variable itself is never modified and only used by a single function
> so it can be made const and local to the using function.
> 
> Changes in v2:
> * None
> 
> Signed-off-by: Bruce Richardson 

Acked-by Pablo de Lara 

[dpdk-dev] SSSE3 instruction set not enabled ERROR - use msse4.2

[Thomas Monjalon]

Hi,

2014-09-05 18:53, Raj Ravi:
> I was facing this error:
> "SSSE3 instruction set not enabled" while building dpdk.

It should not happen with last version (1.7.1).

> Using the following commands:
> make config  T=x86_64-native-linuxapp-gcc
> make install  T=x86_64-native-linuxapp-gcc

Please precise which DPDK version was it and what is your CPU
(/proc/cpuinfo could help).

Thanks
-- 
Thomas

[dpdk-dev] dpdk 1.6 insmod rte_kni error

[Zhou, Danny]

Have you insmod hwmon.ko on your system? Also, you may want to build the DPDK 
on your system as KNI kernel module depends on local kernel source code. 

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of rong wen
> Sent: Friday, September 05, 2014 7:35 PM
> To: dev
> Subject: [dpdk-dev] dpdk 1.6 insmod rte_kni error
> 
> Hi All,
> 
> I am a new guy to use dpdk. The kernel version is 2.6.32.
> 
> After I build the rte_kni.ko, I run insmod rte_kni.ko, error message is:
> 
> Unloading any existing DPDK KNI module
> Loading DPDK KNI module
> insmod: error inserting
> '/home/wenrong.wr/dpdk_dev_r1-6-0/x86_64-default-linuxapp-gcc/kmod/rte_kni.ko':
> -1 Unknown symbol in module
> ## ERROR: Could not load kmod/rte_kni.ko.
> 
> The dmesg output is:
> 
> [181831.351549] rte_kni: Unknown symbol hwmon_device_register
> [181831.353671] rte_kni: Unknown symbol hwmon_device_unregister
> [182558.257153] rte_kni: Unknown symbol hwmon_device_register
> [182558.259288] rte_kni: Unknown symbol hwmon_device_unregister
> 
> 
> Thank you.
> 
> Rong

[dpdk-dev] Question about ASLR

[Matt Laswell]

Hey Folks,

A colleague noticed warnings in section 23.3 of the programmer's guide
about the use of address space layout randomization with multiprocess DPDK
applications.  And, upon inspection, it appears that ASLR is enabled on our
target systems.  We've never seen a problem that we could trace back to
ASLR, and we've never see a warning during EAL memory initialiization,
either, which is strange.

Given the choice, we would prefer to keep ASLR for security reasons.  Given
that in our problem domain:
   - We are running a multiprocess DPDK application
   - We run only one DPDK application, which is a single compiled binary
   - We have exactly one process running per logical core
   - We're OK with interrupts coming just to the primary
   - We handle interaction from our control plane via a separate shared
memory space

Is it OK in this circumstance to leave ASLR enabled?  I think it probably
is, but would love to hear reasons why not and/or pitfalls that we need to
avoid.

Thanks in advance.

--
Matt Laswell
*infinite io*

[dpdk-dev] SSSE3 instruction set not enabled ERROR - use msse4.2

[Neil Horman]

On Fri, Sep 05, 2014 at 08:32:56PM +0530, Raj Ravi wrote:
> 
> cpuinfo:
> cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 16
> model : 4
> model name : AMD Phenom(tm) II X4 955 Processor
> stepping : 3
> microcode : 0x1c8
> cpu MHz : 800.000
> cache size : 512 KB
> physical id : 0
> siblings : 4
> core id : 0
> cpu cores : 4
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl
> nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm
> extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit
> wdt hw_pstate npt lbrv svm_lock nrip_save
> bogomips : 6399.94
> TLB size : 1024 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 48 bits physical, 48 bits virtual
> power management: ts ttp tm stc 100mhzsteps hwpstate
> ===
> 
> Fedora 20  - 3.15.10 default Fedora kernel  used.
> 
> ===
> 
> I have built dpdk-1.7.0 and faced this error.
> I have tried building dpdk-1.7.1 , but faced the same error.
> 
> 
> Only after adding msse4.2, this errors goes away.
> 

As Thomas said, it won't happen with 1.7.1, but the real question is, what do
you want to run this on. enabling sse4.2 in the compiler makes the error go
away, but it will cause run time failure if you try to run the built binary on a
system that doesn't support sse4.2.

Neil

> 
> Thanks
> 
> 
> 
> On Fri, Sep 5, 2014 at 7:10 PM, Masaru Oki  
> wrote:
> > Hi,
> > What is your build environment (processor)?
> > I got same error with AMD Phoenom II, doesn't have SSSE3 instruction.
> >
> >
> > 2014-09-05 22:23 GMT+09:00 Raj Ravi :
> >>
> >> Hi,
> >> I was facing this error:
> >> "SSSE3 instruction set not enabled" while building dpdk.
> >>
> >> Using the following commands:
> >> make config  T=x86_64-native-linuxapp-gcc
> >> make install  T=x86_64-native-linuxapp-gcc
> >>
> >> So, again I tried like this :
> >> make configT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"
> >> make installT=x86_64-native-linuxapp-gcc   EXTRA_CFLAGS="-msse4.2"
> >>
> >> Now, the build goes through.
> >> Is This method correct  to follow ?
> >>
> >> Thanks
> >
> >
> 

[dpdk-dev] Are there considerations about resource recycling by the process, not by the OS?

[Masaru Oki]

Hi,

you may try
 $ gdb your_program
 gdb> b rte_panic
 gdb> run
 stopped at rte_panic
 gdb> bt

sorry, it is not answer for your question.
by the way, do you run the program as root?



2014-09-05 12:07 GMT+09:00 Zhangkun (K) :

> Hi,
>I develop the program with the use of dpdk and the process is core dump
> when the program is started.
> The process is crash in case of initing memory failed and calling
> rte_panic function.
>  I search all rte_panic function in the dpdk, and find it so many.
> Therefore, in case the pr ocess happen fail,
> it will abort. The resource allocated before is not released by the
> process, but by the OS system.
> So I have a question: Are there considerations about resource recycling by
> the process, not by the OS ?
>

[dpdk-dev] Are there considerations about resource recycling by the process, not by the OS?

[Richardson, Bruce]

Can you perhaps send on the log and the traceback from the panic call. From the 
error message we may be able to tell you why your process is failing.

/Bruce

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhangkun (K)
> Sent: Friday, September 05, 2014 4:40 AM
> To: Masaru Oki
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Are there considerations about resource recycling by 
> the
> process, not by the OS?
> 
> Hi,
> Yes, the program is running as root.
> I want to know if or not the DPDK Community considers about resource
> recycling.
> 
> From: Masaru Oki [mailto:m-oki at stratosphere.co.jp]
> Date: 2014?9?5? 11:18
> To: Zhangkun (K)
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Are there considerations about resource recycling by 
> the
> process, not by the OS?
> 
> Hi,
> 
> you may try
>  $ gdb your_program
>  gdb> b rte_panic
>  gdb> run
>  stopped at rte_panic
>  gdb> bt
> 
> sorry, it is not answer for your question.
> by the way, do you run the program as root?
> 
> 
> 2014-09-05 12:07 GMT+09:00 Zhangkun (K)
> mailto:zhang.zhangkun at huawei.com>>:
> Hi,
>I develop the program with the use of dpdk and the process is core dump 
> when
> the program is started.
> The process is crash in case of initing memory failed and calling rte_panic
> function.
>  I search all rte_panic function in the dpdk, and find it so many. Therefore, 
> in
> case the pr ocess happen fail,
> it will abort. The resource allocated before is not released by the process, 
> but by
> the OS system.
> So I have a question: Are there considerations about resource recycling by the
> process, not by the OS ?

[dpdk-dev] Are there considerations about resource recycling by the process, not by the OS?

[Zhangkun (K)]

Hi,
Yes, the program is running as root.
I want to know if or not the DPDK Community considers about resource 
recycling.

From: Masaru Oki [mailto:m-...@stratosphere.co.jp]
Date: 2014?9?5? 11:18
To: Zhangkun (K)
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Are there considerations about resource recycling by 
the process, not by the OS?

Hi,

you may try
 $ gdb your_program
 gdb> b rte_panic
 gdb> run
 stopped at rte_panic
 gdb> bt

sorry, it is not answer for your question.
by the way, do you run the program as root?


2014-09-05 12:07 GMT+09:00 Zhangkun (K) mailto:zhang.zhangkun at huawei.com>>:
Hi,
   I develop the program with the use of dpdk and the process is core dump when 
the program is started.
The process is crash in case of initing memory failed and calling rte_panic 
function.
 I search all rte_panic function in the dpdk, and find it so many. Therefore, 
in case the pr ocess happen fail,
it will abort. The resource allocated before is not released by the process, 
but by the OS system.
So I have a question: Are there considerations about resource recycling by the 
process, not by the OS ?

[dpdk-dev] Are there considerations about resource recycling by the process, not by the OS?

[Zhangkun (K)]

Hi,
   I develop the program with the use of dpdk and the process is core dump when 
the program is started.
The process is crash in case of initing memory failed and calling rte_panic 
function.
 I search all rte_panic function in the dpdk, and find it so many. Therefore, 
in case the pr ocess happen fail,
it will abort. The resource allocated before is not released by the process, 
but by the OS system.
So I have a question: Are there considerations about resource recycling by the 
process, not by the OS ?