From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: rte_eal_init() alternative? Date: Fri, 9 Oct 2015 11:25:36 +0300 Message-ID: <56177A00.9060201@redhat.com> References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902125650.GA10364@bricha3-MOBL3> <3003120.8bdQ5bCz5C@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: "Montorsi, Francesco" , Thomas Monjalon Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 9883E2E83 for ; Fri, 9 Oct 2015 10:25:39 +0200 (CEST) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/08/2015 05:58 PM, Montorsi, Francesco wrote: > Hi, > >> -----Original Message----- >> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] >> Sent: mercoled=C3=AC 2 settembre 2015 15:10 >> To: Montorsi, Francesco >> Cc: dev@dpdk.org; Bruce Richardson >> Subject: Re: [dpdk-dev] rte_eal_init() alternative? >> >> 2015-09-02 13:56, Bruce Richardson: >>> On Wed, Sep 02, 2015 at 12:49:40PM +0000, Montorsi, Francesco wrote: >>>> Hi all, >>>> >>>> Currently it seems that the only way to initialize EAL is using rte_= eal_init() >> function, correct? >>>> >>>> I have the problem that rte_eal_init() will call rte_panic() wheneve= r >> something fails to initialize or in other cases it will call exit(). >>>> In my application, I would rather like to attempt DPDK initializatio= n. If it >> fails I don't want to exit. >>>> Unfortunately I cannot even copy&paste the rte_eal_init() code into = my >> application (removing rte_panic and exit calls) since it uses a lot of= DPDK >> internal private functions. >>>> >>>> I think that my requirements (avoid abort/exit calls when init fails= ) is a >> basic requirement... would you accept a patch that adds an alternative >> rte_eal_init() function that just returns an error code upon failure, = instead of >> immediately exiting? >>>> >>>> Thanks for your hard work! >>>> >>>> Francesco Montorsi >>>> >>> I, for one, would welcome such a patch. I think the code is overly >>> quick in many places to panic or exit the app, when an error code wou= ld be >> more appropriate. >>> Feel free to also look at other libraries in DPDK too, if you like :-= ) >> >> Yes but please, do not create an alternative init function. >> We just need to replace panic/exit with error codes and be sure that a= pps >> and examples handle them correctly. > > To maintain compatibility with existing applications I think that > perhaps the best would be to have a core initialization function > rte_eal_init_raw() that never calls rte_panic() and returns an error > code. Then we can maintain compatibility having an rte_eal_init() > function that does call rte_panic() if rte_eal_init_raw() fails. Note that callers are already required to check rte_eal_init() return=20 code for errors, and any app failing to do so would be buggy to begin=20 with. So just turning the panics into error returns is not an=20 incompatible change. I agree with Thomas here, lets just fix rte_eal_init() to do the right=20 thing instead of adding alternatives just for the error return.=20 Especially when _raw() in the name suggests that is not the thing you'd=20 commonly want to use. > Something like the attached patch. It seems the patch missed the boat :) > Note that the attached patch exposes also a way to skip the > argv/argc configuration process by directly providing a populated > configuration structure... > Let me know what you think about it (the patch is just a draft and > needs more work). Can't comment on what I've not seen, but based on comments seen on this=20 list, having an alternative way to initialize with structures would be=20 welcomed by many. The downside is that those structures will need to be=20 exposed in the API forever which means any changes there are subject to=20 the ABI process. - Panu - > Thanks, > Francesco > > > > =09 >