[dpdk-dev,4/9] eal/linux: move back interrupt thread init before setting affinity

Message ID 1454076516-21591-5-git-send-email-david.marchand@6wind.com (mailing list archive)
State Changes Requested, archived
Headers

Commit Message

David Marchand Jan. 29, 2016, 2:08 p.m. UTC
  Now that virtio pci driver is initialized in a constructor, we only need to
move the interrupt thread init after loading the plugins.
This way, chelsio driver should be happy again [1].

[1] http://dpdk.org/ml/archives/dev/2015-November/028289.html

Signed-off-by: David Marchand <david.marchand@6wind.com>
---
 lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
  

Comments

Rahul Lakkireddy Feb. 2, 2016, 7:02 a.m. UTC | #1
Hi David,

On Friday, January 01/29/16, 2016 at 15:08:31 +0100, David Marchand wrote:
> Now that virtio pci driver is initialized in a constructor, we only need to
> move the interrupt thread init after loading the plugins.
> This way, chelsio driver should be happy again [1].
> 
> [1] http://dpdk.org/ml/archives/dev/2015-November/028289.html
> 
> Signed-off-by: David Marchand <david.marchand@6wind.com>
> ---
>  lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
> index 635ec36..62241ee 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -823,6 +823,9 @@ rte_eal_init(int argc, char **argv)
>  	if (eal_plugins_init() < 0)
>  		rte_panic("Cannot init plugins\n");
>  
> +	if (rte_eal_intr_init() < 0)
> +		rte_panic("Cannot init interrupt-handling thread\n");
> +
>  	eal_thread_init_master(rte_config.master_lcore);
>  
>  	ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
> @@ -834,9 +837,6 @@ rte_eal_init(int argc, char **argv)
>  	if (rte_eal_dev_init() < 0)
>  		rte_panic("Cannot init pmd devices\n");
>  
> -	if (rte_eal_intr_init() < 0)
> -		rte_panic("Cannot init interrupt-handling thread\n");
> -
>  	RTE_LCORE_FOREACH_SLAVE(i) {
>  
>  		/*
> -- 
> 1.9.1
> 

Thank you for this patch.  I've tested it and it does improve the perf.
back when there is a queue on master lcore in l3fwd app.

Thanks,
Rahul
  
David Marchand Feb. 2, 2016, 7:13 a.m. UTC | #2
Hello Rahul,

On Tue, Feb 2, 2016 at 8:02 AM, Rahul Lakkireddy
<rahul.lakkireddy@chelsio.com> wrote:
> On Friday, January 01/29/16, 2016 at 15:08:31 +0100, David Marchand wrote:
>> Now that virtio pci driver is initialized in a constructor, we only need to
>> move the interrupt thread init after loading the plugins.
>> This way, chelsio driver should be happy again [1].
>
> Thank you for this patch.  I've tested it and it does improve the perf.
> back when there is a queue on master lcore in l3fwd app.

Did you test the whole series ? or just this specific patch ?

Anyway, great, but this is still too fragile.

As discussed in the same thread as the problem you reported, there is
some work over there to be done so that interrupts are "distributed"
in a more flexible way.
Did someone look at this ?
Plans to work on this ? (post 2.3, I suppose)
  
Rahul Lakkireddy Feb. 2, 2016, 7:43 a.m. UTC | #3
Hi David,

On Monday, February 02/01/16, 2016 at 23:13:55 -0800, David Marchand wrote:
> Hello Rahul,
> 
> On Tue, Feb 2, 2016 at 8:02 AM, Rahul Lakkireddy
> <rahul.lakkireddy@chelsio.com> wrote:
> > On Friday, January 01/29/16, 2016 at 15:08:31 +0100, David Marchand wrote:
> >> Now that virtio pci driver is initialized in a constructor, we only need to
> >> move the interrupt thread init after loading the plugins.
> >> This way, chelsio driver should be happy again [1].
> >
> > Thank you for this patch.  I've tested it and it does improve the perf.
> > back when there is a queue on master lcore in l3fwd app.
> 
> Did you test the whole series ? or just this specific patch ?
> 

I've tested only this particular patch, not the whole series.

> Anyway, great, but this is still too fragile.
> 
> As discussed in the same thread as the problem you reported, there is
> some work over there to be done so that interrupts are "distributed"
> in a more flexible way.
> Did someone look at this ?
> Plans to work on this ? (post 2.3, I suppose)
> 
> 
> -- 
> David Marchand

Thanks,
Rahul
  

Patch

diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..62241ee 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -823,6 +823,9 @@  rte_eal_init(int argc, char **argv)
 	if (eal_plugins_init() < 0)
 		rte_panic("Cannot init plugins\n");
 
+	if (rte_eal_intr_init() < 0)
+		rte_panic("Cannot init interrupt-handling thread\n");
+
 	eal_thread_init_master(rte_config.master_lcore);
 
 	ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
@@ -834,9 +837,6 @@  rte_eal_init(int argc, char **argv)
 	if (rte_eal_dev_init() < 0)
 		rte_panic("Cannot init pmd devices\n");
 
-	if (rte_eal_intr_init() < 0)
-		rte_panic("Cannot init interrupt-handling thread\n");
-
 	RTE_LCORE_FOREACH_SLAVE(i) {
 
 		/*