From: Panu Matilainen <pmatilai@redhat.com>
To: "Montorsi, Francesco" <fmontorsi@empirix.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: rte_eal_init() alternative?
Date: Fri, 9 Oct 2015 14:12:00 +0300 [thread overview]
Message-ID: <5617A100.5040502@redhat.com> (raw)
In-Reply-To: <786931fdd268483eb6623389603dfbb6@bilemail1.empirix.com>
On 10/09/2015 01:13 PM, Montorsi, Francesco wrote:
>>> It seems the patch missed the boat :)
>>
>> Correct, sorry. I'm attaching it now.
> Ok, for some reason the email client is removing the attachment... I'm copying and pasting it:
> (the points marked as TODO are functions that still contain rte_panic() calls...)
I actually did receive the attachment from the previous mail, but
inlined patches are far better for commenting purposes.
> + */
> +struct internal_config;
> +int rte_eal_init_raw(const char* logid, struct internal_config *cfg);
Like the name indicates, struct internal_config is internal to
librte_eal, you'd need to "export" the eal_internal_cfg.h header for
this to be useful to users outside librte_eal itself. But I'd say
there's a reason why its internal...
> - if (rte_eal_pci_init() < 0)
> - rte_panic("Cannot init PCI\n");
> + if (rte_eal_pci_init() < 0) {
> + RTE_LOG (ERR, EAL, "Cannot init PCI\n");
> + return -1;
> + }
>
> #ifdef RTE_LIBRTE_IVSHMEM
> - if (rte_eal_ivshmem_init() < 0)
> - rte_panic("Cannot init IVSHMEM\n");
> + if (rte_eal_ivshmem_init() < 0) {
> + RTE_LOG (ERR, EAL, "Cannot init IVSHMEM\n");
> + return -1;
> + }
> #endif
>
> - if (rte_eal_memory_init() < 0)
> - rte_panic("Cannot init memory\n");
> + if (rte_eal_memory_init() < 0) {
> + RTE_LOG (ERR, EAL, "Cannot init memory\n");
> + return -1;
> + }
[...]
Something like that, sure. The big question with this conversion is what
to do with already allocated/initialized resources in case of failure,
which I'd guess is the reason rte_panic() is there - to avoid having to
deal with all that.
Getting to a point where all or even most inialization can be undone in
case of failure is likely going to be a long road, I think many
subsystems dont even have a shutdown function. To beging with, EAL
itself doesn't have one :)
Anyway, one has to start someplace. But in order to make the cleanup
eventually possible, I'd suggest using a common point of exit instead of
a dozen returns, ie something in spirit of
{
[...]
if (rte_eal_pci_init() < 0) {
RTE_LOG (ERR, EAL, "Cannot init PCI\n");
goto err;
}
if (rte_eal_memory_init() < 0)
RTE_LOG (ERR, EAL, "Cannot init memory\n");
goto err;
}
[...]
return 0;
err:
/* TODO: undo all initialization work */
return -1;
}
- Panu -
next prev parent reply other threads:[~2015-10-09 11:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 12:49 rte_eal_init() alternative? Montorsi, Francesco
2015-09-02 12:56 ` Bruce Richardson
2015-09-02 13:10 ` Thomas Monjalon
2015-09-02 18:17 ` Don Provan
2015-09-02 19:00 ` Stephen Hemminger
2015-09-02 20:50 ` Marc Sune
2015-09-02 21:08 ` Thomas Monjalon
2015-09-02 22:01 ` Wiles, Keith
2015-09-08 18:01 ` Don Provan
2015-09-11 17:15 ` Wiles, Keith
2015-10-08 14:58 ` Montorsi, Francesco
2015-10-09 8:25 ` Panu Matilainen
2015-10-09 10:03 ` Montorsi, Francesco
2015-10-09 10:13 ` Montorsi, Francesco
2015-10-09 11:12 ` Panu Matilainen [this message]
2015-10-09 10:40 ` Panu Matilainen
2015-10-09 16:03 ` Thomas F Herbert
2015-09-02 14:08 ` Jay Rolette
2015-09-02 19:23 ` Zoltan Kiss
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=5617A100.5040502@redhat.com \
--to=pmatilai@redhat.com \
--cc=dev@dpdk.org \
--cc=fmontorsi@empirix.com \
--cc=thomas.monjalon@6wind.com \
/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.