[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <570E2224.7050704@mojatatu.com>
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