Thread (39 messages) flat view 39 messages, 8 authors, 2016-09-25

Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP

From: Eric Dumazet <hidden>
Date: 2016-09-22 14:46:26

On Thu, 2016-09-22 at 15:14 +0200, Jesper Dangaard Brouer wrote:
On Wed, 21 Sep 2016 21:56:58 +0200
Jesper Dangaard Brouer [off-list ref] wrote:
quoted
quoted
quoted
I'm not opposed to running non-BPF code at XDP. I'm against adding
a linked list of hook consumers.  
I also worry about the performance impact of a linked list.  We should
simple benchmark it instead of discussing it! ;-)
(Note, there are some stability issue with this RFC patchset, when
removing the xdp program, that I had to workaround/patch)


I've started benchmarking this and I only see added cost of 2.89ns from
these patches, at these crazy speeds it does correspond to -485Kpps.
I claim the methodology is too biased.

At full speed, all the extra code is hot in caches, and your core has
full access to memory bus anyway. Even branch predictor has fresh
information.

Now, in a mixed workload, where all cores compete to access L2/L3 and
RAM, things might be very different.

Testing icache/dcache pressure is not a matter of measuring how many
Kpps you add or remove on a hot path.

A latency test, when other cpus are busy reading/writing all over
memory, and your caches are cold, would be useful.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help