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

Eddie Kohler kohler at cs.ucla.edu
Sat Jul 10 21:42:37 EDT 2004


[From Peng Wang pwangee at udel.edu]

Hi,

I have some questions about click and linux kernel. First I will introduce my
scenario.

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.

The commands are as follow.
	128.4.1.25/128.4.5.25 (albert):tty0 % /home/click/userlevel/click
                     –h out0.stats –h out1.stats wp-wire-red.click

         128.4.1.25/128.4.5.25 (albert):tty1 % tcpdump host 128.4.1.26
                                                             and 128.4.5.20

         128.4.1.26(Seminole): % ./server
	
         128.4.5.20: % ./client 128.4.1.26

>From the program tcpdump, we can find that some packets are dropped by linux
kernel. It shows in the following table. 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.

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?  It seems that there is great difference between
click dropping packets and linux kernel dropping packets. Does the string
“ToDevice (eth0) send: No buffer space available” means that the packet is also
dropped by the linux kernel?

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.

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?

I am confused about these. Thanks

Peng Wang


Click_User_Mode	
RED(0,1,0.4)->Queue(2)	
128.4.5.20: receiver buffer size 512000(set) and 1024000(get)
		
packets captured	packets received by filter	packets dropped by kernel
20089	                      20448	                         219
20112	                      20181	                           3
20502	                      20563	                           4
20503	                      20596	                          10
19895	                      20013	                          59
20283	                      20349	                           0
20486	                      20679	                          40
20303	                      20401	                          23
20233	                      20396	                         101
20472	                      20693	                          66
20613	                      20687	                          12
20355	                      20498	                          44
20430	                      20521	                          21


Click_Kernel_Mode		
RED(0,1,0.4)->Queue(2)		
128.4.5.20: receiver buffer size 512000(set) and 1024000(get)
			
eth0		eth1	
out0.avg_queue	out0.drops	out1.avg_queue	out1.drops
1.539	            5675	0.268	          0
0.86	            4282	0.135	          0
0.584	            5654	0.131	          0


More information about the click mailing list