lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220718145717.27c2db1b@kernel.org>
Date:   Mon, 18 Jul 2022 14:57:17 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tariq Toukan <ttoukan.linux@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Tariq Toukan <tariqt@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        Saeed Mahameed <saeedm@...dia.com>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        Gal Pressman <gal@...dia.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next V2 2/2] net/mlx5e: Improve remote NUMA
 preferences used for the IRQ affinity hints

On Mon, 18 Jul 2022 22:49:21 +0300 Tariq Toukan wrote:
> >> @@ -830,8 +887,7 @@ static int comp_irqs_request(struct mlx5_core_dev *dev)
> >>   		ret = -ENOMEM;
> >>   		goto free_irqs;
> >>   	}
> >> -	for (i = 0; i < ncomp_eqs; i++)
> >> -		cpus[i] = cpumask_local_spread(i, dev->priv.numa_node);
> >> +	mlx5_set_eqs_cpus(dev, cpus, ncomp_eqs);  
> > 
> > So you change this for mlx5, what about the other users of
> > cpumask_local_spread() ?  
> 
> I took a look at the different netdev users.
> While some users have similar use case to ours (affinity hints), many 
> others use cpumask_local_spread in other flows (XPS setting, ring 
> allocations, etc..).
> 
> Moving them to use the newly exposed API needs some deeper dive into 
> their code, especially due to the possible undesired side-effects.
> 
> I prefer not to include these changes in my series for now, but probably 
> contribute it in a followup work.

I'd be great if you could pick any other driver and start creating 
the right APIs for it and mlx5. "Probably contribute followup work"
does not inspire confidence. And yes, I am being picky, I'm holding 
a grudge against mlx5 for not using netif_get_num_default_rss_queues().

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ