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

[Eddie Kohler]

> In my opinion, when I run click at userlevel, click receives packets 
> from the
> Linux kernel and do some work about the packets such as arp, rarp, and 
> routing
> etc. And then click sends packets to the linux kernel again. Linux 
> kernel is
> responsible to receive and send packets in the lower level. 

This is not correct.  From the FromDevice.u manual page (user-level FromDevice):

        The kernel networking code sees all of the packets that FromDevice pro-
        duces; be careful that at most one of Click  and  the  kernel  forwards
        each packet.

You have to install firewalling rules in your kernel if you want to prevent the 
kernel from processing packets.

Click at kernel level does behave as you describe.

> By the way, I know a 2-packet-long queue is extremely small....

OK, makes sense.

>> 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.
> 
> I check the tcpdump manual and find the following paragraph.
> 
> Packets “dropped by kernel” (this is the number of packets that were 
> dropped,
> due to a lack of buffer space, by the packet capture mechanism in the OS on
> which tcpdump is running, if the OS reports that information to 
> applications;
> if not, it will be reported as 0).
> 
> I am not sure the point in the manual is same as your point.

It is.  Note the phrase "by the packet capture mechanism"

>> This error message comes from the kernel refusing to send packets that 
>> Click
>> has passed it.  Those packets are getting dropped by Click.
> 
> Does it mean that kernel also drop these packets due to no buffer size? 
> I want
> to know whether the dropping by click also means dropping by kernel due 
> to the
> kernel has no buffer size.

I believe so, but you might have to check kernel code to make sure.

>> 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.
> 
> 
> Do the ToDevice messages mean that click drops packets? If it is, does this
> number of packets dropping is included in the RED out0.drops?

At user-level?  Yes (although by giving ToDevice an optional second output you 
can preserve the pakcets and try to send them again); and no (the RED drops 
count includes only packets dropped by RED).

E