netdev - Re: net/mlx4: Mellanox driver update 01-01-2014

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1393175180.6823.56.camel@deadeye.wl.decadent.org.uk>
Date:	Sun, 23 Feb 2014 17:06:20 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Amir Vadai <amirv@...lanox.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	yevgenyp@...lanox.com, ogerlitz@...lanox.com, yuvala@...lanox.com
Subject: Re: net/mlx4: Mellanox driver update 01-01-2014

On Sun, 2014-02-23 at 11:01 +0200, Amir Vadai wrote:
> On 22/02/14 01:33 +0000, Ben Hutchings wrote:
[...]
> > So this sort of policy not only shouldn't be implemented in specific
> > drivers, but also ought to be configurable.
> > 
> > Ben.
> 
> Hi,
> 
> The idea here is to prefer a local node than a remote one - and not to
> *always* use local nodes - kind of best effort approach.
> The patch is relevant when number of rings is smaller (or bigger) than
> number of CPU's - in this case the idea is to try to put the majority
> of rx queues on the local node, and not to spread it evenly on the
> numa nodes.
> So, for Intel architecture you will get better performance in average,
> and on other architectures, things will stay the same.
> 
> Therefore, I don't think it is needed to have a tunable for that.
> 
> If a user wants to use a more aggressive mode: to handle all incoming
> traffic only by local nodes, he'll be able to do it by changing number
> of rx channels to number of local cores - so we actually have the
> tunable you had in mind.

Right, that does sound pretty good as a default.  And I accept that it
would be reasonable to implement that initially without a tunable beyond
total number of IRQs.

I would like to have a central mechanism for this that would allow the
administrator to set a policy of spreading IRQs across all threads,
cores, packages, local cores, etc.  (The out-of-tree version of sfc has
such options.)  If you add the mechanism and default that you've
proposed, then someone (maybe me) can get round to the configurable
policy later.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)