[Click] Click userlevel performance issues

Peter Dedecker Peter.Dedecker at intec.UGent.be
Sat Mar 6 11:06:30 EST 2010


Hi all,

I've done some performance tests with the VPAN software (which you might 
remember from the nice talk of Jeroen at the Click Symposium ;-)) on 
real performant hardware. I've disabled all encryption stuff to strip it 
all down to almost plain Click with some routing and simple 
encapsulation operations.

I have 3 types of nodes:
- a sender takes plain IP packets from its tun0 interface, encapsulates 
them and sents them out on its eth0 interface.
- a forwarding node takes packets from its eth0, decapsulates, looks up 
the next hop (like the sender also does), encapsulates the packet again, 
and sends it out on eth1.
- the reciever is the final destination of the packets, accepts them on 
its eth0 interface, decapsulates them and delivers them at its tun0 
interface.

All quite simple and almost all the same operations though. With 
increasing traffic, CPU usage of the Click process increases also, which 
seems normal. However, a main observation on all traffic ranges, is that 
the sender node consequently has the highest CPU load. Forwarding nodes 
have a CPU load of only +/-2/3 of the sender nodes, while the 
destination clearly has the easiest work to do with a CPU load of only 
+/-1/3 compared to the forwarding node or even less than 20% of the 
sender's CPU load.  For some figures: the click process has a CPU usage 
(measured with top) of 24% at a sending node, while 14% and 3% at 
forwarders and recievers. All nodes have a Dual-Core AMD Opteron(tm) 
Processor 2212 running at 2010.151 MHz with a cache size of 1024 KB, 
with 2 CPU's each node. Of course, as Click is single threaded, only one 
core will be used.

Is accepting packets from a tun0 interface so hard, compared with 
accepting packets from the eth0 interface? I don't think expensive 
headroom push for packet encapsulation can be the problem, as in this 
configuration only an ethernet header is added with its 14 bytes being 
lower than the default headroom of 28 bytes. Does anyone have an 
explanation for this? Thanks a lot!

Kind regards,

-- 
ir. Peter Dedecker
Department of Information Technology
Broadband Communication Networks (IBCN)
Ghent University - IBBT
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
M: +32 486152320
T: +32 9 33 14946 ; T Secr: +32 9 33 14900
F: +32 9 33 14899
E: Peter.Dedecker at intec.UGent.be
W : www.ibcn.intec.UGent.be


More information about the click mailing list