26/06/2018 12:53, Anatoly Burakov:
> From: Jianfeng Tan <jianfeng....@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....@intel.com>
> Signed-off-by: Anatoly Burakov <anatoly.bura...@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?
