netdev - Re: [RFC][NET_SCHED] explict hold dev tx lock

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]

Date:	Mon, 17 Sep 2007 09:03:58 -0400
From:	jamal <hadi@...erus.ca>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	David Miller <davem@...emloft.net>, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org, kaber@...sh.net, dada1@...mosbay.com
Subject: Re: [RFC][NET_SCHED] explict hold dev tx lock

On Mon, 2007-17-09 at 14:27 +0400, Evgeniy Polyakov wrote:

> 
> How many cpu collisions you are seeing?

On 4 CPUs which were always transmitting very few - there was contention
in the range of 100 per million attempts.
Note: it doesnt matter that 4 cpus were busy, this lock is contended at
max (for all NAPI drivers i poked into) between two CPUs.

> Did I understand you right, that you replaced trylock with lock and
> thus removed collision handling and got better results?

Yes, a small one with the 4 CPUs and no irq binding. Note that in the
test cases i run, the contention for queue lock was high (since all CPUs
were busy processing traffic). 
I think as the the number of CPUs go up, this will become more
prominent. The choice is between contending for queue lock or this lock.
One lock is contended by max of two cpus, the other by N cpus. As N goes
up, you want to have more mercy on the one that is contended by N cpus.
Did that make sense?

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html