From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mukawa@igel.co.jp>
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com
 [209.85.192.169]) by dpdk.org (Postfix) with ESMTP id 3E5DC38EB
 for <dev@dpdk.org>; Tue,  9 Sep 2014 06:56:09 +0200 (CEST)
Received: by mail-pd0-f169.google.com with SMTP id fp1so2636935pdb.0
 for <dev@dpdk.org>; Mon, 08 Sep 2014 22:01:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
 :subject:content-type:content-transfer-encoding;
 bh=P4yrZP4TE10I36+BeZAhR/BV8duZq81e6dAbnjxPpu0=;
 b=H/MMZJ9R3ap23hbC0WeN4tM/N+7qYxQn/r5ylf0JHn+kQBkg3ZKnQ0/MQSHenxdMPE
 xuSixtm3XqgI3NIvaUhPTw/gNub6mrtfjq24yES7rVYEmT2A3TQxR9IcYhKa9kTUgQFA
 F1DhNmvIUtDxns4Zfas9hfOaUozyAAdRt2WguKivCHnL2iRNuePotqL1CWTVotE0H7CP
 ghjK3YdVlqHZXVHfyO2K3dgTC8g13WfGPWyfPCEdxvQPRuuMDbg6R+6f0/1UghJ0oSUN
 UagkWIMp0zOyYw1/uAdwEsIKxUwY0K/m3PPxRKTSRxHWHQNOmJigfGg/hM0BYenfQ7MW
 fKkg==
X-Gm-Message-State: ALoCoQmGLjhiCKx5iLrJQ06cHQOQnfV1pEg/v56XfrSSrNplvK2wqtnWO9F+VEyenXoC38YgS+3d
X-Received: by 10.66.66.163 with SMTP id g3mr10886384pat.150.1410238870809;
 Mon, 08 Sep 2014 22:01:10 -0700 (PDT)
Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132])
 by mx.google.com with ESMTPSA id ve13sm11021223pac.6.2014.09.08.22.01.09
 for <dev@dpdk.org>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 08 Sep 2014 22:01:10 -0700 (PDT)
Message-ID: <540E8995.1000008@igel.co.jp>
Date: Tue, 09 Sep 2014 14:01:09 +0900
From: Tetsuya Mukawa <mukawa@igel.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dev@dpdk.org" <dev@dpdk.org>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Subject: [dpdk-dev] initialization order in rte_eal_init()
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 04:56:09 -0000

Hi,

I have a question about initialization order in rte_eal_init()
It seems some lcore related functions are called between
rte_eal_dev_init(PMD_INIT_PRE_PCI_PROBE) and rte_eal_pci_probe().
Is there any reason to do so?

int
rte_eal_init(int argc, char **argv)
{

(snip)

if (rte_eal_dev_init(PMD_INIT_PRE_PCI_PROBE) < 0)
rte_panic("Cannot init pmd devices\n");

RTE_LCORE_FOREACH_SLAVE(i) {

/*
* create communication pipes between master thread
* and children
*/
if (pipe(lcore_config[i].pipe_master2slave) < 0)
rte_panic("Cannot create pipe\n");
if (pipe(lcore_config[i].pipe_slave2master) < 0)
rte_panic("Cannot create pipe\n");

lcore_config[i].state = WAIT;

/* create a thread for each lcore */
ret = pthread_create(&lcore_config[i].thread_id, NULL,
eal_thread_loop, NULL);
if (ret != 0)
rte_panic("Cannot create thread\n");
}

/*
* Launch a dummy function on all slave lcores, so that master lcore
* knows they are all ready when this function returns.
*/
rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
rte_eal_mp_wait_lcore();

/* Probe & Initialize PCI devices */
if (rte_eal_pci_probe())
rte_panic("Cannot probe PCI\n");

/* Initialize any outstanding devices */
if (rte_eal_dev_init(PMD_INIT_POST_PCI_PROBE) < 0)
rte_panic("Cannot init pmd devices\n");

return fctret;
}

Thanks,
Tetsuya