[Click] confusion about the dropping packets by click element or by linux kernel

[Eddie Kohler]

Peng

> When click works in user mode, the server sends 1000000 strings which 
> have 14
> characters each to the client. The router click has two NICs named eth0 and
> eth1, and uses RED algorithm where the parameter about RED is
> RED(0,1,0.4)->Queue(2) for both eth0 and eth1.

WHen you run Click at userlevel, the kernel *and* Click both receive a packet; 
the kernel will forward the packet as well as Click.  So this usage scenario 
doesn't make much sense.  And a 2-packet-long queue is extremely small.

>> From the program tcpdump, we can find that some packets are dropped by 
>> linux kernel. It shows in the following table.

You've misunderstood tcpdump.  When tcpdump says a packet was "dropped by the 
kernel", that means that the *copy of the packet destined for tcpdump* was 
dropped.  It has no correlation with packets dropped by the kernel's forwarding 
logic.  Check the tcpdump manual page.

> But we can’t find packets dropping
> from the handler of RED. It shows zero. We only get a lot of strings 
> “ToDevice
> (eth0) send: No buffer space available”, whose number is obviously much 
> bigger
> than the number of packets dropped by kernel.

This error message comes from the kernel refusing to send packets that Click has 
passed it.  Those packets are getting dropped by Click.

> My first question:
> 1. Does the string “ToDevice (eth0) send: No buffer space available” 
> means that
> click drops packet? If it is, why click drops packets but in fact linux 
> kernel
> doesn’t drop the packets? 

Again this is not what those messages are telling you.  And Click running at 
userlevel will not work well, you shouldn't run it this way.

> Then I make click work in the kernel mode, and get another table which 
> is showed
> in the following. I find that the number of packets dropping by eth0 
> seems to
> be same as the number of the strings “ToDevice (eth0) send: No buffer space
> available”. I think that above string really means dropping packets by 
> click.

Not really.  Click is dropping the packets, because the kernel refused to send 
them.  RED is not dropping the packets.

> Now the linux kernel is bypassed by click.
> My second question is:
> 2. Does it mean that click really dropping so many packets? Click drops 
> too much
> more packets than linux kernel drops? Is that true? Why click drops in the
> kernel mode more than the linux kernel does in the user mode?

This question actually doesn't make any sense, because tcpdump isn't telling you 
how many packets the kernel is dropping, and because the ToDevice messages are 
not at all equivalent to the "RED out1.drops" numbers you collected.

Eddie