From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <anatoly.burakov@intel.com>
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151])
 by dpdk.org (Postfix) with ESMTP id 6E83D1B4E3
 for <dev@dpdk.org>; Fri, 13 Jul 2018 09:41:43 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 13 Jul 2018 00:41:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.51,347,1526367600"; d="scan'208";a="64400472"
Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.0.191])
 ([10.252.0.191])
 by FMSMGA003.fm.intel.com with ESMTP; 13 Jul 2018 00:41:37 -0700
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Jianfeng Tan <jianfeng.tan@intel.com>,
 Bruce Richardson <bruce.richardson@intel.com>, konstantin.ananyev@intel.com,
 qi.z.zhang@intel.com, stephen@networkplumber.org, olivier.matz@6wind.com,
 david.marchand@6wind.com, ferruh.yigit@intel.com
References: <cover.1530009564.git.anatoly.burakov@intel.com>
 <5f6bc60bf193daf4eb07f4484c52878bb1b751de.1530009564.git.anatoly.burakov@intel.com>
 <5431396.k1M6VaMcRs@xps>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <162242b3-388d-93c9-9046-e4ed76e49ae2@intel.com>
Date: Fri, 13 Jul 2018 08:41:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5431396.k1M6VaMcRs@xps>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v2 5/7] eal: bring forward init of interrupt
 handling
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>
X-List-Received-Date: Fri, 13 Jul 2018 07:41:44 -0000

On 12-Jul-18 11:36 PM, Thomas Monjalon wrote:
> 26/06/2018 12:53, Anatoly Burakov:
>> From: Jianfeng Tan <jianfeng.tan@intel.com>
>>
>> Next commit will make asynchronous IPC requests rely on alarm API,
>> which in turn relies on interrupts to work. Therefore, move the EAL
>> interrupt initialization before IPC initialization to avoid breaking
>> IPC in the next commit.
>>
>> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> ---
>> --- a/lib/librte_eal/linuxapp/eal/eal.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal.c
>> @@ -839,6 +839,11 @@ rte_eal_init(int argc, char **argv)
>>   
>>   	rte_config_init();
>>   
>> +	if (rte_eal_intr_init() < 0) {
>> +		rte_eal_init_alert("Cannot init interrupt-handling thread\n");
>> +		return -1;
>> +	}
>> +
>>   	/* Put mp channel init before bus scan so that we can init the vdev
>>   	 * bus through mp channel in the secondary process before the bus scan.
>>   	 */
>> @@ -968,11 +973,6 @@ rte_eal_init(int argc, char **argv)
>>   		rte_config.master_lcore, (int)thread_id, cpuset,
>>   		ret == 0 ? "" : "...");
>>   
>> -	if (rte_eal_intr_init() < 0) {
>> -		rte_eal_init_alert("Cannot init interrupt-handling thread\n");
>> -		return -1;
>> -	}
>> -
>>   	RTE_LCORE_FOREACH_SLAVE(i) {
> 
> I am almost sure it will bring regressions.
> 
> Please think again about the consequences of initializing interrupt thread
> before affinity setting, memory init, device init.
> 
> Opinions / ideas from anyone?
> 

Since interrupt thread is no longer relying on rte_malloc, i do not 
expect there to be any consequences for memory.

I also do not expect any consequences due to moving intr init before 
setting CPU thread affinity, because first of all interrupt thread is 
*already* run before setting thread affinity of the lcores (but after 
setting thread affinity of the master), and it picks its own affinity 
based on parsed coremask anyway, which is already parsed at a point 
where i'm moving it to. Affinities will be set similarly to how they 
were set before, because lcore information is already parsed.

As for device init, that is debatable. The only consequence i can think 
of is if device interrupts happen right after enabling the intr handler 
for that device and this causes some kind of issue or a race. But, we 
already support device hotplug which essentially causes the same 
situation to happen (interrupt handler initialized before bus 
scan/probe), so i'm not really convinced this could have any negative 
consequences either.

-- 
Thanks,
Anatoly