From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 0142FA0096
for <public@inbox.dpdk.org>; Mon, 3 Jun 2019 16:05:59 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 1FEC41B964;
Mon, 3 Jun 2019 16:05:59 +0200 (CEST)
Received: from mail-it1-f194.google.com (mail-it1-f194.google.com
[209.85.166.194]) by dpdk.org (Postfix) with ESMTP id C68F71B95C
for <dev@dpdk.org>; Mon, 3 Jun 2019 16:05:57 +0200 (CEST)
Received: by mail-it1-f194.google.com with SMTP id l21so5690789ita.2
for <dev@dpdk.org>; Mon, 03 Jun 2019 07:05:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=qwilt-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=sMuHYA+WdYNembP3yK+jVtVPk0B4Zx7Yu4aGOmY14OM=;
b=LoG1n0uV7QK93p8vqxc+pgfH5FBwPlfwok/L0VvFxVg9M1Y1jlqUJ0VGsy9tCUVDsS
qlNbmAhbRqySiMZ4sc5OjNiFG/HChs5zrIqtCwfrk6Ja1IXREYrcTXPYnWgAaugZjja6
bc/kfVKL+01YfAdiMIuLjlt5dzEF+4Fi1mC9xrqxBUZUhHQHvMfoK0p5oFbZJMR8qb3L
eYHEIeuCqiWTRRU4GS83Qh+fUMRt8UcfXVT2z7vsD9sMMknST91jYU86tC41Z9ru36hw
0E8QHErK5AXEStPNCVgrgiQo8CDh9Ht5a8B8MQKAfx5T39glZ8zqyqidyFZFMwox6AQJ
KriA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=sMuHYA+WdYNembP3yK+jVtVPk0B4Zx7Yu4aGOmY14OM=;
b=Q/GNZaFE3AmJIeChdjIGMcdltsB9+3fYZMMIPYN8tiHD+3s2iS7Zl3d8Lzn+WgYTwP
KCQo9a8E5BNBL3RsWSNX30M9Y6uJC5Ryvp4GfDtab4BWxpEAQ7/nZN1qj3tpPqlAJ9h2
MaERfph2bVHEquynrcbYWmnxRIZYrs1X00HX2NjENyTfkbbDD/BIoK0w6vJiO6moN4la
FSR1Hrekp+GDiGlas/9kYuLv+mRARV7IxyAheVqzQD18ms2OKoXpwQOw7dULJlbLe4M+
mZCmhXTsO03aBqRbvnd3I5yDBruKPkLPUDNf+63rpF8nMAdRJrpfDqLyZoS4ieg8FlJn
cQFA==
X-Gm-Message-State: APjAAAWNEj+WtCBKjetTK/tJK71dUUrcQtHgVcGm4Wm493CawEwcAMae
E9SX08aEUIbt1EvRKsswOSUE+rh0e80ni4aCLCFNOg==
X-Google-Smtp-Source: APXvYqzMc0S18Npa1NrvatTfhJIolIW9k1x3WGNZqPuNfgFi6IT+6oBc2BrrZdJdhxMEwV9UT9SXo9nyCvfRdgNteks=
X-Received: by 2002:a24:618e:: with SMTP id
s136mr15858006itc.106.1559570757034;
Mon, 03 Jun 2019 07:05:57 -0700 (PDT)
MIME-Version: 1.0
References: <1559535816-23542-1-git-send-email-arnon@qwilt.com>
<1559546368-32263-1-git-send-email-arnon@qwilt.com>
<CAJFAV8wizeLGi6q4C=MRf1OKPW6v3rH-5+mLps+vFV5Mt_JVtg@mail.gmail.com>
In-Reply-To: <CAJFAV8wizeLGi6q4C=MRf1OKPW6v3rH-5+mLps+vFV5Mt_JVtg@mail.gmail.com>
From: Arnon Warshavsky <arnon@qwilt.com>
Date: Mon, 3 Jun 2019 17:05:45 +0300
Message-ID: <CAKy9EB2S8vOK18hNRx7Tpexsp_bakTWTschMCKctY6TZ9rugaA@mail.gmail.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
Stephen Hemminger <stephen@networkplumber.org>, "Burakov,
Anatoly" <anatoly.burakov@intel.com>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [dpdk-dev] [PATCH v3] eal: remove non-thread panic calls from
init sequence
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Hi
>
> The part below can go after a --- marker, this is more a comment for the
> work in progress rather than something to put in this patch commitlog.
>
Ack
>
> The calls for launching core messaging threads were left in tact
>> in all 3 eal implementations.
>>
>
> For these I will submit a patch suggesting a callback registration,
>> allowing the user to register a context to be called
>> in case of a panic that takes place outside the init sequence.
>>
>
> Not sure I understand what you want to do, but at least this patch is a
> first step.
>
Promise to be less vague in the actual patch :)
>
>
>> + RTE_LOG(ERR, EAL, "Cannot open '%s' for
>> rte_mem_config\n",
>> + pathname);
>>
>
> Fix indent please, and in subsequent uses of RTE_LOG in this patch.
>
Ack
>
>
>> When we close this fd, we need to reset the variable pointing to it to -1
> or subsequent call would reuse an incorrect mem_cfg_fd.
> The problem is general in both linux and freebsd eal.c but something is
> still not clear to me in how we are supposed to keep this fd opened or not
> in normal successfull init case.
>
In this case we are on the way out from the process in the shortest way out
so no subsequent calls expected , but I agree for the sake of good order.
Will zero those
>
> + if (rte_eal_config_create() < 0) {
>>
> + RTE_LOG(ERR, EAL, "Failed to create config\n");
>>
>
> All error paths in rte_eal_config_create() have a log.
> Adding one more here won't help and we have another one coming with the
> rte_eal_init_alert later.
>
> This comment goes for linux changes as well.
>
Agree. Will fix that
thanks
/Arnon