Questions on ToLinux and ToLinuxSniffers Performance

Benjie Chen benjie at amsterdam.lcs.mit.edu
Tue Jul 10 18:51:16 EDT 2001


hi

> Question 1: Is it an expected result that using the element ToLinux and then
> in another approach using ToLinuxSniffers in order to pass packets to a user
> level sockets program (that basically does nothing but count packets)
> results in the same (poor) performance?

there is a performance difference. ToLinuxSniffers bypasses protocol 
processing, therefore it is faster. more on the performance side of
things later in this email.

> Question 2: Is it against the philosophy of click to attempt to do any
> processing in the user space (for example counting) since I see such a
> performance penalty when attempting to pass packets to a simple sockets
> program?

no, but you do suffer a penality. mostly packets need to be copied
from kernel to user space and the userlevel app needs to make system
calls. but you can certainly write userlevel application using Click
elements.

> Question 3 (unrelated to the remainder of this email) How do I use the click
> counter element's reset handler which is write only? I do not understand how
> to clear the counter's count value without having to do another cat to
> /proc/config which does a reset every time.

if you write to the reset handler, it resets the packet counter and the
rate counter. you either needs to do a cat into /proc/click/Counter at blah,
or you can use llrpc, which allows you to use iotcl to interact with
elements.

looking over counter.cc, it does not appear there is a reset llrpc.
implementing such thing may be a good exercise =)

> I have used PollDevice(eth1) -> Counter -> Discard to see that click allows
> counting packets at wire speed while using an Intel e1000 gigabit NIC.  I
> have been able to repeat the reported Intel Pro/1000 gigabit driver polling
> configuration receiving 1.3 million 64 byte packets per second :>)

cool.

the number you reported seems to be packets counted. you would count
fewer packets in userspace probably due to packets dropped at a queue
in linux, for the socket. ToLinuxSniffer does work faster. a simple
configuration 

PollDevice(eth1) 
  -> Counter 
  -> cc :: RoundTripCycleCount
  -> ToLinuxSniffers;
Idle -> ToDevice(eth1);

measures the number of cycles needed to push packets into ToLinuxSniffers
and back, that is, cost of calling push() method of ToLinuxSniffer.
you can get the numbers by looking at /proc/click/cc/{packets,cycles}.
you can also replace ToLinuxSniffers with ToLinux.

using this configuration, i was getting 2006 cycles per packet for ToLinux
and only 921 cycles per packet for ToLinuxSniffers. this is on a 700 Mhz
machine. so yes, they are both expensive, but ToLinuxSniffers is faster.

other people may have other stuff to add to this...

benjie


-- 
benjie chen
benjie at lcs.mit.edu



More information about the click mailing list