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] [day] [month] [year] [list]
Date:	Wed, 13 Apr 2016 06:40:36 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Brenden Blanco <bblanco@...mgrid.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org, tom@...bertland.com,
	alexei.starovoitov@...il.com, ogerlitz@...lanox.com,
	daniel@...earbox.net, brouer@...hat.com, eric.dumazet@...il.com,
	ecree@...arflare.com, john.fastabend@...il.com, tgraf@...g.ch,
	johannes@...solutions.net, eranlinuxmellanox@...il.com,
	lorenzo@...gle.com
Subject: Re: [RFC PATCH v2 5/5] Add sample for adding simple drop program to
 link

On 16-04-10 02:38 PM, Brenden Blanco wrote:

>> I always go for the lowest hanging fruit.
> Which to me is the 60% time spent above the driver level as shown above.
[..]
>> It seemed it was the driver path in your case. When we removed
>> the driver overhead (as demoed at the tc workshop in netdev11) we saw
>> __netif_receive_skb_core() at the top of the profile.
>> So in this case seems it was mlx4_en_process_rx_cq() - thats why i
>> was saying the bottleneck is the driver.
> I wouldn't call it a bottleneck when the time spent is additive,
> aka run-to-completion.


The driver is a bottleneck regardless. It is probably the DMA interfaces 
and lots of cacheline misses. So the first thing to
fix is whats at the top of the profile if you wanb
The fact you are dropping earlier is in itself an improvement
as long as you dont try to be too fancy.

> Of course the second perf report is on the same machine as the commit
> message. That was generated fresh for this email thread. All of the
> numbers I've quoted come from the same single-sender/single-receiver
> setup. I did also revert the change the in mlx4 driver and there was no
> change in the tc numbers.

Ok, i misunderstood then because you hinted Daniel had seen those
numbers. If you please also add that to your commit numbers.

cheers,
jamal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ