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

[Eddie Kohler]

[From pwangee]

Hi,

Thanks for your helps. But I still has some questions about this stuff.

> 
> 
> > 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.

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. I am a little
confuse about “the kernel *and* Click both receive a packet; the kernel will
forward the packet as well as Click.”

By the way, I know a 2-packet-long queue is extremely small. Why I do that is
because I want to find packet dropping and do some research in congestion
control. I have use some other parameters to the same work and find packet
dropping in kernel mode. Anyway, the small queue is to make the phenomenon more
clearly.


> 
> >> 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.

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.

> 
> > 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.

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.

> 
> > 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.

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?

Thanks again

Peng