Re: [dpdk-dev] [RFC 00/23] Refactor eal_init to remove panic() calls

2017-01-25 Thread Aaron Conole
Thomas Monjalon writes: > Hi Aaron, > > 2016-12-30 10:25, Aaron Conole: >> In many cases, it's enough to simply let the application know that the >> call to initialize DPDK has failed. A complete halt can then be >> decided by the application based on error returned (and the app could >> even at

Re: [dpdk-dev] [RFC 00/23] Refactor eal_init to remove panic() calls

2017-01-03 Thread Aaron Conole
Thomas Monjalon writes: > Hi Aaron, > > 2016-12-30 10:25, Aaron Conole: >> In many cases, it's enough to simply let the application know that the >> call to initialize DPDK has failed. A complete halt can then be >> decided by the application based on error returned (and the app could >> even at

Re: [dpdk-dev] [RFC 00/23] Refactor eal_init to remove panic() calls

2017-01-02 Thread Thomas Monjalon
Hi Aaron, 2016-12-30 10:25, Aaron Conole: > In many cases, it's enough to simply let the application know that the > call to initialize DPDK has failed. A complete halt can then be > decided by the application based on error returned (and the app could > even attempt a possible re-attempt after s

[dpdk-dev] [RFC 00/23] Refactor eal_init to remove panic() calls

2016-12-30 Thread Aaron Conole
In many cases, it's enough to simply let the application know that the call to initialize DPDK has failed. A complete halt can then be decided by the application based on error returned (and the app could even attempt a possible re-attempt after some corrective action by the user or application).