[Click] User level Click Queues vs Kernel Queues

[Michael Sirivianos]

Hi,

We are trying to setup a simple experiment with userlevel click to
measure the performance degradation of a router performing some crypto
computations.

We would prefer to use it at kernel space, but 2.4 kernels do not really
work on our PC's (unless we spend all our time trying to choose the
correct compiling options) and due to gcc/glib incompatibilities we
cannot even compile them. 

our configuration is sthng like:

fromDevice->classifier-> Queue(200) -> Unqueue->StripIpheader-
>...OurElement->ARPQuerier.

However, we observe that no matter how expensive the computation in
OurElement is and no matter how much the sender rate increases, the
Queue never builds up over 1 packet. Instead we have packet losses, that
we have not been able to pinpoint exactly where they happen. By the
network monitor tools we infer, its not in the Ethernet interface, and
most likely not in the IP input queue at the kernel.

We theorize that we may have drops at a kernel/userspace queue but we
would like an opinion on that.

Am I correct to assume that  a frame is directly forwarded from the
device to a kernel queue and then userlevel click which is a single
thread  reads the frame from this in-kernel queue? Then click proceeds
with processing the packets at the rest of the modules including our
Queue element? Thus, the same thread puts the packet in the click queue
and then processes it. This is the only explanation I could find for not
being able to build up our Click queue over 1 packet.

Is it impossible to conduct this experiment at the userlevel?
At the kernel level would the NIC be the producer of packets that
directly places frame in our Click Queue and the Elements Unqueue->...
would be the consumers?

Thanks,
Michael