(RESEND w/ correct reply-to) click bug report (help needed)

[Eric Freudenthal]

Thanks Eddie.  We now see the proper number of /proc files.  However, this
config runs far slower than expected (varied ping forwarding latencies on an
otherwise unloaded system of 10-200ms).

Please advise if we're doing something inappropriate:

We want to emulate a system of multiple networks that are all slower than
Ethernet.  The idea is that we build simulated network & inter-network link
emulators using classifiers for inter-simulated-net routing.  When a packet
is rec'd from the real network interface, a click Classifier selects by src
addr the appropriate simulated network emulator chain that imposes latency &
bw restrictions.   Whenever a packet leaves a simulated network chain, it is
routed via a Classifer (by dst addr), either back to the appropriate network
interface (via ToLinux) or to another bw/latency chain that terminates in
another click-simulated network emulator chain.

Each of the click-simulated network emulator chains & inter-network link
chains is implemented as a chain with inputs & outputs either attached to
classifiers or other chains:

in_dcc_dce :: Queue(256)
 -> in_dcc_dce_RATE :: BandwidthShaper(100000000)
 -> SetTimestamp
 -> out_in_dcc_dce :: DelayUnqueue(0.001000s);

We let linux handle arp & packet forwarding to the appropriate interface?
We could implement the entire router in click (mostly we'd need to add arp
handling), but thought that linux's forwarding would be fine.  Is this a
likely cause for our troubles?

Thanks, Eric

Eric Freudenthal  // Courant Institute // New York University
719 Broadway, Room 712 // New York, NY // 10003
office: 212-998-3345 // cell: 917-279-6208

-----Original Message-----
From: Eddie Kohler [mailto:kohler at icir.org]
Sent: Thursday, February 28, 2002 3:52 PM
To: eric.freudenthal at nyu.edu; taozhao at cs.nyu.edu
Cc: click at amsterdam.lcs.mit.edu
Subject: Re: (RESEND w/ correct reply-to) click bug report (help needed)

I gave Tao a call. FYI for others:

> Also: when this config is installed, click requires 260k of memory,
> which kmalloc() is unable to fulfill.  We hacked our kernel to support
> this.  Any reason to not use vmalloc() instead?

vmalloc() is inappropriate for small objects, since it uses at least one
page per memory request. But the vmalloc/kmalloc thing is an issue we might
address in future releases.

> the following click config file misbehaves on our system.  It contains
> about 200 counters, all named with the suffix  _counter.  Only 56 of
> them seem to be visible in our proc file system, and the behavior of
> the resulting system is pretty screwy.

The way to fix this is to increase the value of the PROC_NDYNAMIC symbol in
LINUXDIR/include/linux/proc_fs.h . It limits the number of /proc files that
are allowed.

Eddie