From jensdewit at gmail.com Mon Mar 1 13:25:42 2010 From: jensdewit at gmail.com (Jens De Wit) Date: Mon, 1 Mar 2010 19:25:42 +0100 Subject: [Click] DS: New element: icmpipencap, a general icmppingencap In-Reply-To: References: <217154321002250902j537c55d9ha97b18e58e334efb@mail.gmail.com> <0822F3307FE52B4FAD7962B06DF51F8B032446E6@xmail01.ad.ua.ac.be> Message-ID: <217154321003011025u6057cec4p45ec3b0b3f92c001@mail.gmail.com> Dear list, I send this mail in reply to Eddie's remarks on the new ICMPIPEncap element. Attached you will find the improved version of the element, as well as a testie file containing a basic unit test for the new element. Kind regards, Jens De Wit 2010/2/28 De Wit Jens > > ------------------------------------------- > *Van:* Eddie Kohler[SMTP:KOHLER at CS.UCLA.EDU ] > *Verzonden:* zondag 28 februari 2010 21:52:07 > *Aan:* Braem Bart > *CC:* click at amsterdam.lcs.mit.edu; De Wit Jens > *Onderwerp:* Re: [Click] New element: icmpipencap, a general icmppingencap > > *Automatisch doorgezonden volgens een regel* > > Hi guys! > > Thanks very much for this element. I'd definitely like to add it to the > repository. However, I have some concerns that if you could address, it > would > be great. > > 1. Element documentation in the header file is missing. Even just one > paragraph plus the use case (e.g. "=c ICMPEncap(SRC, DST, TYPE [, CODE])".) > > 2. The _icmp_type and _icmp_code members should be read using IPNameInfo, > so > users can give symbolic names. E.g.: > > int32_t icmp_type; > ... "TYPE", cpkP+cpkM, cpNamedInteger, NameInfo::T_ICMP_TYPE, &icmp_type, > ... > > The CODE requires special handling since you need to know the TYPE before > parsing the CODE. Take a look at ICMPError for an example. > > 3. This is the big one: The current element adds a clcik_icmp_echo header. > But this header is only correct for TYPE echo or echo-reply. Other ICMP > types > add a different header, often with a different length. For example tstamp > and > tcstamp-reply have longer ehaders. See include/clicknet/icmp.h for more > examples. Either the element should be changed to add the appropriate > header > for _type, or the configure() method should return an error on an > inappropriate TYPE. > > Thanks very much, > Eddie > > > Braem Bart wrote: > > Dear list, > > > > Attached you will find an element our students (Jens De Wit and Nico Van > Looy) produced while working on their FireSim project, the Firewall > Simulation in Click as presented on SyClick. > > > The element allows transmitting ICMP packets with all types of codes and > types, which makes this element more general than ICMPPingEncap. It is a bit > the ICMP alternative to UDPIPEncap. > > > The element code is largely based on ICMPPingEncap so Jens and Nico > suggested just patching ICMPPingEncap with the new behaviour, although of > course the name then does not cover the contents of the element. > > > Jens promised to write a unit test with the testie framework, so this can > be expected as well. > > > > best regards, > > Bart > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > -------------- next part -------------- A non-text attachment was scrubbed... Name: icmpipencap.cc Type: text/x-c++src Size: 4576 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100301/73048774/attachment.cc -------------- next part -------------- A non-text attachment was scrubbed... Name: icmpipencap.hh Type: text/x-c++hdr Size: 1784 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100301/73048774/attachment.hh -------------- next part -------------- A non-text attachment was scrubbed... Name: ICMPIPEncap-01.testie Type: application/octet-stream Size: 473 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100301/73048774/attachment.obj From jesse.r.brown at lmco.com Mon Mar 1 16:12:06 2010 From: jesse.r.brown at lmco.com (Jesse Brown) Date: Mon, 01 Mar 2010 16:12:06 -0500 Subject: [Click] AGNOSTIC vs. PUSH/PULL Message-ID: <4B8C2DA6.6030501@atl.lmco.com> All: I am currently working on a router config that looks similar to the following: elementclass Monitor { input -> ipc :: IPClassifier (tcp, udp, icmp, -); f :: Foo; ipc[0] -> Print("tcp-in") -> [0]f[0] -> Print("tcp-out") -> output; ipc[1] -> Print("udp-in") -> [1]f[1] -> Print("udp-out") -> output; ipc[2] -> Print("icmp-in") -> [2]f[2] -> Print("icmp-out") -> output; ipc[3] -> Print("other-in") -> [3]f[3] -> Print("other-out") -> output; } FromDevice(eth0, PROMISC true) -> ... -> Monitor -> ... -> Queue -> ToDevice(eth1); This is obviously simplified but conveys my point, I think. If I define Foo as const char *class_name() const { return "Foo"; } const char *port_count() const { return "-/-"; } const char *processing() const { return AGNOSTIC; } Packet *simple_action(Packet *); Then I will always get icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 tcp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 Due to how Element::push behaves. In order to have a single copy of this element that can be located anywhere in a router I have to define Foo::simple_action, Foo::pull, and Foo::push. Is there a more standard way to get the behavior I am after? My desired result would look like: icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 icmp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 in the above example. Also, is there a reason that both Element::push and Element::pull ignore the port by default? Would the attached patch break existing behavior? Thanks, Jesse -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: port.patch Url: http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100301/c1f0d913/attachment.txt From cliff at meraki.com Mon Mar 1 19:12:48 2010 From: cliff at meraki.com (Cliff Frey) Date: Mon, 1 Mar 2010 16:12:48 -0800 Subject: [Click] AGNOSTIC vs. PUSH/PULL In-Reply-To: <4B8C2DA6.6030501@atl.lmco.com> References: <4B8C2DA6.6030501@atl.lmco.com> Message-ID: Jesse, Generally simple_action() is only used for elements with exactly one input and one or two outputs. If you want to make an element that maps many-to-many, then you would need to define push() and/or pull() methods. There is no need to override the simple_action method if you override push/pull. Changing the default element behavior does not seem like the right decision to me. However, in most cases where you want an element with many inputs and outputs, it is actually useful to break it up into many elements with a shared state element.... so you end up with something like: foo_table :: FooTable(); // no inputs or outputs cl [0] -> FooListener(TABLE foo_table) -> IPPrint(tcp) -> ... cl [1] -> FooListener(TABLE foo_table) -> IPPrint(udp) -> ... or something along those lines... however without knowing more details about what you are trying to do, I don't know if that is a good fit or not. Cliff On Mon, Mar 1, 2010 at 1:12 PM, Jesse Brown wrote: > All: > > I am currently working on a router config that looks similar to the > following: > > elementclass Monitor { > input -> > ipc :: IPClassifier (tcp, udp, icmp, -); > f :: Foo; > > ipc[0] -> Print("tcp-in") -> [0]f[0] -> Print("tcp-out") -> output; > ipc[1] -> Print("udp-in") -> [1]f[1] -> Print("udp-out") -> output; > ipc[2] -> Print("icmp-in") -> [2]f[2] -> Print("icmp-out") -> output; > ipc[3] -> Print("other-in") -> [3]f[3] -> Print("other-out") -> output; > } > > FromDevice(eth0, PROMISC true) -> > ... -> > Monitor -> > ... -> > Queue -> ToDevice(eth1); > > > This is obviously simplified but conveys my point, I think. > If I define Foo as > const char *class_name() const { return "Foo"; } > const char *port_count() const { return "-/-"; } > const char *processing() const { return AGNOSTIC; } > > Packet *simple_action(Packet *); > > Then I will always get > > icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > tcp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > > Due to how Element::push behaves. > > In order to have a single copy of this element that can be located anywhere > in a router I have to define Foo::simple_action, Foo::pull, and Foo::push. > Is there a more standard way to get the behavior I am after? My desired > result would look like: > > icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > icmp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > > in the above example. > > Also, is there a reason that both Element::push and Element::pull ignore > the port by default? Would the attached patch break existing behavior? > > Thanks, > > Jesse > > > diff -cr old/lib/element.cc new/lib/element.cc > *** old/lib/element.cc Sun Feb 28 10:22:28 2010 > --- new/lib/element.cc Mon Mar 1 13:58:08 2010 > *************** > *** 2706,2715 **** > void > Element::push(int port, Packet *p) > { > - (void) port; > p = simple_action(p); > if (p) > ! output(0).push(p); > } > > /** @brief Pull a packet from pull output @a port. > --- 2706,2714 ---- > void > Element::push(int port, Packet *p) > { > p = simple_action(p); > if (p) > ! output(port).push(p); > } > > /** @brief Pull a packet from pull output @a port. > *************** > *** 2727,2734 **** > Packet * > Element::pull(int port) > { > ! (void) port; > ! Packet *p = input(0).pull(); > if (p) > p = simple_action(p); > return p; > --- 2726,2732 ---- > Packet * > Element::pull(int port) > { > ! Packet *p = input(port).pull(); > if (p) > p = simple_action(p); > return p; > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > From harald at net.t-labs.tu-berlin.de Tue Mar 2 04:46:39 2010 From: harald at net.t-labs.tu-berlin.de (=?UTF-8?B?SGFyYWxkIFNjaGnDtmJlcmc=?=) Date: Tue, 02 Mar 2010 10:46:39 +0100 Subject: [Click] 1.8.0 RELEASED In-Reply-To: <4B8AE97A.2050805@cs.ucla.edu> References: <4B8AE97A.2050805@cs.ucla.edu> Message-ID: <4B8CDE7F.3090202@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eddie Kohler wrote: > Hi, > > Click 1.8.0 is released. Thanks to everyone for their contributions and > patience. Thanks a lot .... One thing, while merging our stuff, I realized that the online click-api doxygen is a bit behind: http://read.cs.ucla.edu/click/doxygen/ : "Generated on Sun Nov 9 18:12:44 2008 for Click " would you mind rerunning ? - -- Harald Schi?berg Technische Universit?t Berlin | T-Laboratories | FG INET www: http://www.net.t-labs.tu-berlin.de Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLjN5/y8wrZ9OvkU0RAsYJAKDMagBEdrF444N7SMS3CV329DNa9wCgnbDD jRpmiRVeRJtwPtmQM+MmN60= =uSd3 -----END PGP SIGNATURE----- From jesse.r.brown at lmco.com Tue Mar 2 11:45:37 2010 From: jesse.r.brown at lmco.com (Jesse Brown) Date: Tue, 02 Mar 2010 11:45:37 -0500 Subject: [Click] AGNOSTIC vs. PUSH/PULL In-Reply-To: References: <4B8C2DA6.6030501@atl.lmco.com> Message-ID: <4B8D40B1.3030104@atl.lmco.com> Cliff: Sorry for the duplicate, I forgot to include the list in my original reply. Cliff Frey wrote: > Jesse, > > Generally simple_action() is only used for elements with exactly one input > and one or two outputs. > Well, in the push case it would have to be N-to-1 (input to output) and pull would be 1-to-N, right? > If you want to make an element that maps many-to-many, then you would need > to define push() and/or pull() methods. There is no need to override the > simple_action method if you override push/pull. > Yes, I misspoke in my description. What I meant to say was that if I use an AGNOSTIC element in any multi-input/multi-output configuration it is no longer sufficient to just define simple_action. > Changing the default element behavior does not seem like the right decision > to me. > > However, in most cases where you want an element with many inputs and > outputs, it is actually useful to break it up into many elements with a > shared state element.... so you end up with something like: > > foo_table :: FooTable(); // no inputs or outputs > > cl [0] -> FooListener(TABLE foo_table) -> IPPrint(tcp) -> ... > cl [1] -> FooListener(TABLE foo_table) -> IPPrint(udp) -> ... > This will work just fine for my needs; I forgot that I could pass elements as arguments to other elements in the router. However, I still find it interesting that the default behavior for Element push/pull ignores ports. The documentation for Element::pull states "Often, pull() methods will request packets from upstream using input(i).pull()". I'm definitely not an authority on the subject, I just found that behavior counter-intuitive. > or something along those lines... however without knowing more details about > what you are trying to do, I don't know if that is a good fit or not. > > Cliff > > On Mon, Mar 1, 2010 at 1:12 PM, Jesse Brown wrote: > > >> All: >> >> I am currently working on a router config that looks similar to the >> following: >> >> elementclass Monitor { >> input -> >> ipc :: IPClassifier (tcp, udp, icmp, -); >> f :: Foo; >> >> ipc[0] -> Print("tcp-in") -> [0]f[0] -> Print("tcp-out") -> output; >> ipc[1] -> Print("udp-in") -> [1]f[1] -> Print("udp-out") -> output; >> ipc[2] -> Print("icmp-in") -> [2]f[2] -> Print("icmp-out") -> output; >> ipc[3] -> Print("other-in") -> [3]f[3] -> Print("other-out") -> output; >> } >> >> FromDevice(eth0, PROMISC true) -> >> ... -> >> Monitor -> >> ... -> >> Queue -> ToDevice(eth1); >> >> >> This is obviously simplified but conveys my point, I think. >> If I define Foo as >> const char *class_name() const { return "Foo"; } >> const char *port_count() const { return "-/-"; } >> const char *processing() const { return AGNOSTIC; } >> >> Packet *simple_action(Packet *); >> >> Then I will always get >> >> icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> tcp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> >> Due to how Element::push behaves. >> >> In order to have a single copy of this element that can be located anywhere >> in a router I have to define Foo::simple_action, Foo::pull, and Foo::push. >> Is there a more standard way to get the behavior I am after? My desired >> result would look like: >> >> icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> icmp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> >> in the above example. >> >> Also, is there a reason that both Element::push and Element::pull ignore >> the port by default? Would the attached patch break existing behavior? >> >> Thanks, >> >> Jesse >> >> >> diff -cr old/lib/element.cc new/lib/element.cc >> *** old/lib/element.cc Sun Feb 28 10:22:28 2010 >> --- new/lib/element.cc Mon Mar 1 13:58:08 2010 >> *************** >> *** 2706,2715 **** >> void >> Element::push(int port, Packet *p) >> { >> - (void) port; >> p = simple_action(p); >> if (p) >> ! output(0).push(p); >> } >> >> /** @brief Pull a packet from pull output @a port. >> --- 2706,2714 ---- >> void >> Element::push(int port, Packet *p) >> { >> p = simple_action(p); >> if (p) >> ! output(port).push(p); >> } >> >> /** @brief Pull a packet from pull output @a port. >> *************** >> *** 2727,2734 **** >> Packet * >> Element::pull(int port) >> { >> ! (void) port; >> ! Packet *p = input(0).pull(); >> if (p) >> p = simple_action(p); >> return p; >> --- 2726,2732 ---- >> Packet * >> Element::pull(int port) >> { >> ! Packet *p = input(port).pull(); >> if (p) >> p = simple_action(p); >> return p; >> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> >> > > Jesse From kohler at cs.ucla.edu Tue Mar 2 13:00:12 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Tue, 02 Mar 2010 10:00:12 -0800 Subject: [Click] AGNOSTIC vs. PUSH/PULL In-Reply-To: <4B8C2DA6.6030501@atl.lmco.com> References: <4B8C2DA6.6030501@atl.lmco.com> Message-ID: <4B8D522C.3090203@cs.ucla.edu> Jesse, We have very few elements that behave as you describe: N inputs and N outputs, and all packets from input N are emitted on output N. For that reason I don't think it's worthwhile to change the default push() and pull() behavior. simple_action() is after all meant to be simple. Your element sounds like it wants the following definition: elementclass Foo { ... const char *flow_code() const { return "#/#"; } ... void push(int port, Packet *p) { if ((p = simple_action(p))) output(port).push(p); } Packet *pull(int port) { Packet *p = input(port).pull(); if (p) p = simple_action(p); return p; } }; Note the flow_code(). Without the flow_code(), Click will believe that packets arriving on any port could be emitted on any port, and you won't get the agnostic behavior you might expect. Eddie Jesse Brown wrote: > All: > > I am currently working on a router config that looks similar to the > following: > > elementclass Monitor { > input -> > ipc :: IPClassifier (tcp, udp, icmp, -); > f :: Foo; > > ipc[0] -> Print("tcp-in") -> [0]f[0] -> Print("tcp-out") -> output; > ipc[1] -> Print("udp-in") -> [1]f[1] -> Print("udp-out") -> output; > ipc[2] -> Print("icmp-in") -> [2]f[2] -> Print("icmp-out") -> output; > ipc[3] -> Print("other-in") -> [3]f[3] -> Print("other-out") -> > output; > } > > FromDevice(eth0, PROMISC true) -> > ... -> > Monitor -> > ... -> > Queue -> ToDevice(eth1); > > > This is obviously simplified but conveys my point, I think. > If I define Foo as > const char *class_name() const { return "Foo"; } > const char *port_count() const { return "-/-"; } > const char *processing() const { return AGNOSTIC; } > > Packet *simple_action(Packet *); > > Then I will always get > > icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > tcp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > > Due to how Element::push behaves. > > In order to have a single copy of this element that can be located > anywhere in a router I have to define Foo::simple_action, Foo::pull, and > Foo::push. Is there a more standard way to get the behavior I am after? > My desired result would look like: > > icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > icmp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 > > in the above example. > > Also, is there a reason that both Element::push and Element::pull ignore > the port by default? Would the attached patch break existing behavior? > > Thanks, > > Jesse > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From jesse.r.brown at lmco.com Tue Mar 2 13:22:06 2010 From: jesse.r.brown at lmco.com (Jesse Brown) Date: Tue, 02 Mar 2010 13:22:06 -0500 Subject: [Click] AGNOSTIC vs. PUSH/PULL In-Reply-To: <4B8D522C.3090203@cs.ucla.edu> References: <4B8C2DA6.6030501@atl.lmco.com> <4B8D522C.3090203@cs.ucla.edu> Message-ID: <4B8D574E.8090309@atl.lmco.com> Eddie: Thank you for the feedback - Cliff's suggestion of a shared state element coupled with the description below solve my problem exactly. Jesse Eddie Kohler wrote: > Jesse, > > We have very few elements that behave as you describe: N inputs and N > outputs, and all packets from input N are emitted on output N. For > that reason I don't think it's worthwhile to change the default push() > and pull() behavior. simple_action() is after all meant to be simple. > > Your element sounds like it wants the following definition: > > elementclass Foo { > ... > const char *flow_code() const { return "#/#"; } > ... > void push(int port, Packet *p) { > if ((p = simple_action(p))) > output(port).push(p); > } > Packet *pull(int port) { > Packet *p = input(port).pull(); > if (p) > p = simple_action(p); > return p; > } > }; > > Note the flow_code(). Without the flow_code(), Click will believe > that packets arriving on any port could be emitted on any port, and > you won't get the agnostic behavior you might expect. > > Eddie > > > Jesse Brown wrote: >> All: >> >> I am currently working on a router config that looks similar to the >> following: >> >> elementclass Monitor { >> input -> >> ipc :: IPClassifier (tcp, udp, icmp, -); >> f :: Foo; >> >> ipc[0] -> Print("tcp-in") -> [0]f[0] -> Print("tcp-out") -> output; >> ipc[1] -> Print("udp-in") -> [1]f[1] -> Print("udp-out") -> output; >> ipc[2] -> Print("icmp-in") -> [2]f[2] -> Print("icmp-out") -> >> output; >> ipc[3] -> Print("other-in") -> [3]f[3] -> Print("other-out") -> >> output; >> } >> >> FromDevice(eth0, PROMISC true) -> >> ... -> >> Monitor -> >> ... -> >> Queue -> ToDevice(eth1); >> >> >> This is obviously simplified but conveys my point, I think. >> If I define Foo as >> const char *class_name() const { return "Foo"; } >> const char *port_count() const { return "-/-"; } >> const char *processing() const { return AGNOSTIC; } >> >> Packet *simple_action(Packet *); >> >> Then I will always get >> >> icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> tcp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> >> Due to how Element::push behaves. >> >> In order to have a single copy of this element that can be located >> anywhere in a router I have to define Foo::simple_action, Foo::pull, >> and Foo::push. Is there a more standard way to get the behavior I am >> after? My desired result would look like: >> >> icmp-in: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> icmp-out: 98 | 00151715 a8e50015 17163621 08004500 00540000 40004001 >> >> in the above example. >> >> Also, is there a reason that both Element::push and Element::pull >> ignore the port by default? Would the attached patch break existing >> behavior? >> >> Thanks, >> >> Jesse >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From esquivel at cs.wisc.edu Tue Mar 2 14:00:56 2010 From: esquivel at cs.wisc.edu (Holly Esquivel) Date: Tue, 2 Mar 2010 13:00:56 -0600 Subject: [Click] Click on Planet Lab Message-ID: <4a24db691003021100r28375574we9507be2c66c4051@mail.gmail.com> Hello Fellow Click Users, I was wondering if anyone has had experience getting Click to run on Planet Lab nodes. I heard that it was possible but that was about it. Any advice you may have would be greatly appreciated as I get ready to try to it. Thanks! Sincerely, Holly From kohler at cs.ucla.edu Tue Mar 2 15:27:51 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Tue, 02 Mar 2010 12:27:51 -0800 Subject: [Click] 1.8.0 RELEASED In-Reply-To: <4B8CDE7F.3090202@net.t-labs.tu-berlin.de> References: <4B8AE97A.2050805@cs.ucla.edu> <4B8CDE7F.3090202@net.t-labs.tu-berlin.de> Message-ID: <4B8D74C7.7020707@cs.ucla.edu> No problem! It's done. E Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eddie Kohler wrote: >> Hi, >> >> Click 1.8.0 is released. Thanks to everyone for their contributions and >> patience. > > Thanks a lot .... > One thing, while merging our stuff, I realized that the online click-api > doxygen is a bit behind: > > http://read.cs.ucla.edu/click/doxygen/ : > "Generated on Sun Nov 9 18:12:44 2008 for Click " > > would you mind rerunning ? > > > - -- > Harald Schi?berg > Technische Universit?t Berlin | T-Laboratories | FG INET > www: http://www.net.t-labs.tu-berlin.de > Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFLjN5/y8wrZ9OvkU0RAsYJAKDMagBEdrF444N7SMS3CV329DNa9wCgnbDD > jRpmiRVeRJtwPtmQM+MmN60= > =uSd3 > -----END PGP SIGNATURE----- From ianrose at eecs.harvard.edu Tue Mar 2 19:59:21 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Tue, 02 Mar 2010 19:59:21 -0500 Subject: [Click] Element::selected() Message-ID: <4B8DB469.3000707@eecs.harvard.edu> Hi list, Is there any rational for why Element::selected() doesn't tell you what the file descriptor was selected for (reading vs. writing)? Or is there a way to get this info that I don't know about? It seems to me that if you have a FD that you are both reading and writing to (like a socket) you are pretty much stuck with something like: void Foo::selected(int fd) { // perhaps fd was selected for writes... int rv = send(fd, ...); if (rv == -1) { if (errno == EAGAIN) { // oops - I guess fd was actually selected for reads int rv = recv(fd, ...); (etc) } else { // this is a "real" send failure } } // send succeeded! (etc) } Seems kinda ugly and inefficient to me... Am I missing something? I guess an alternative is to call select() on your fd to figure out which it was selected for, but that's rather redundant! - Ian From kohler at cs.ucla.edu Tue Mar 2 20:12:46 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Tue, 02 Mar 2010 17:12:46 -0800 Subject: [Click] Element::selected() In-Reply-To: <4B8DB469.3000707@eecs.harvard.edu> References: <4B8DB469.3000707@eecs.harvard.edu> Message-ID: <4B8DB78E.8010907@cs.ucla.edu> Hi Ian, It's this way because even if a file descriptor was selected for both reading and writing, selected() is called only once. It might be useful to say whether reading or writing was enabled...but of course in between select()'s return and the call of selected(), something might have happened to make the fd selectable in other ways. I don't feel that strongly. Eddie Ian Rose wrote: > Hi list, > > Is there any rational for why Element::selected() doesn't tell you what > the file descriptor was selected for (reading vs. writing)? Or is there > a way to get this info that I don't know about? It seems to me that if > you have a FD that you are both reading and writing to (like a socket) > you are pretty much stuck with something like: > > void > Foo::selected(int fd) > { > // perhaps fd was selected for writes... > int rv = send(fd, ...); > if (rv == -1) { > if (errno == EAGAIN) { > // oops - I guess fd was actually selected for reads > int rv = recv(fd, ...); > (etc) > } else { > // this is a "real" send failure > } > } > // send succeeded! > (etc) > } > > Seems kinda ugly and inefficient to me... Am I missing something? > > I guess an alternative is to call select() on your fd to figure out > which it was selected for, but that's rather redundant! > > - Ian > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Tue Mar 2 20:21:45 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Tue, 02 Mar 2010 20:21:45 -0500 Subject: [Click] Element::selected() In-Reply-To: <4B8DB78E.8010907@cs.ucla.edu> References: <4B8DB469.3000707@eecs.harvard.edu> <4B8DB78E.8010907@cs.ucla.edu> Message-ID: <4B8DB9A9.4030900@eecs.harvard.edu> Eddie Kohler wrote: > Hi Ian, > > It's this way because even if a file descriptor was selected for both > reading and writing, selected() is called only once. True, but you could just use flags right? So the function could be redefined as Element::selected(int fd, int ops) and called like elt->selected(fd, Element::SELECT_READ) or elt->selected(fd, Element::SELECT_WRITE) or elt->selected(fd, Element::SELECT_READ | Element::SELECT_WRITE) > > It might be useful to say whether reading or writing was enabled...but > of course in between select()'s return and the call of selected(), > something might have happened to make the fd selectable in other ways. Also true, but if it was really that important to someone, they could always do that re-checking themselves. E.g. if their selected() was called for reading, they could also check the fd for writing "just in case". That seems rather inefficient to me, but I guess there could be some apps that really want to know ASAP when the fd is ready. > I don't feel that strongly. I think that adding a second function something like the following would retain existing functionality - do you agree? (in element.hh) virtual void selected(int fd, int ops); (in element.cc) void Element::selected(int fd, int ops) { selected(fd); } > > Eddie > > > Ian Rose wrote: >> Hi list, >> >> Is there any rational for why Element::selected() doesn't tell you >> what the file descriptor was selected for (reading vs. writing)? Or >> is there a way to get this info that I don't know about? It seems to >> me that if you have a FD that you are both reading and writing to >> (like a socket) you are pretty much stuck with something like: >> >> void >> Foo::selected(int fd) >> { >> // perhaps fd was selected for writes... >> int rv = send(fd, ...); >> if (rv == -1) { >> if (errno == EAGAIN) { >> // oops - I guess fd was actually selected for reads >> int rv = recv(fd, ...); >> (etc) >> } else { >> // this is a "real" send failure >> } >> } >> // send succeeded! >> (etc) >> } >> >> Seems kinda ugly and inefficient to me... Am I missing something? >> >> I guess an alternative is to call select() on your fd to figure out >> which it was selected for, but that's rather redundant! >> >> - Ian >> >> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From roberto.riggio at create-net.org Wed Mar 3 03:52:12 2010 From: roberto.riggio at create-net.org (Roberto Riggio) Date: Wed, 03 Mar 2010 09:52:12 +0100 Subject: [Click] Click on Planet Lab In-Reply-To: <4a24db691003021100r28375574we9507be2c66c4051@mail.gmail.com> References: <4a24db691003021100r28375574we9507be2c66c4051@mail.gmail.com> Message-ID: <4B8E233C.1010507@create-net.org> Hi, we are actually using click to run our multiradio mesh network on planetlab+vini. Vini is useful in our case because it allows to have performance isolation at the network level between the various slices. At the moment we are using some very simple topologies (string, circle). The very interesting thing is that we can run the same code on planetlab and on the actual wireless routers. We plan to put some online resources on the project website as soon as we can cleanup scripts and codes (www.wing-project.org). R. On 03/02/2010 08:00 PM, Holly Esquivel wrote: > Hello Fellow Click Users, > > I was wondering if anyone has had experience getting Click to run on > Planet Lab nodes. I heard that it was possible but that was about it. > Any advice you may have would be greatly appreciated as I get ready to > try to it. > > Thanks! > > Sincerely, > Holly > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > -- -------------------------------------------------------- Roberto Riggio, PhD CREATE-NET Pervasive Area Researcher Via alla Cascata 56/D - 38123 Povo Trento (Italy) e-mail: roberto.riggio at create-net.org Tel: (+39) 0461 408400 - interno/extension 708 Fax: (+39) 0461 421157 http://www.create-net.org/ -------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited according to the Italian Law 196/2003 of the Legislature. If you received this in error, please contact the sender and delete the material from any computer. Le informazioni contenute in questo messaggio di posta elettronica e nei file allegati sono da considerarsi strettamente riservate. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalita' indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla cancellazione del messaggio stesso dal Vostro sistema. Trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita' diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs. 196/2003. From kohler at cs.ucla.edu Wed Mar 3 13:25:34 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 03 Mar 2010 10:25:34 -0800 Subject: [Click] Element::selected() In-Reply-To: <4B8DB9A9.4030900@eecs.harvard.edu> References: <4B8DB469.3000707@eecs.harvard.edu> <4B8DB78E.8010907@cs.ucla.edu> <4B8DB9A9.4030900@eecs.harvard.edu> Message-ID: <4B8EA99E.2070905@cs.ucla.edu> Yeah, point taken. The new interface is checked in! Eddie Ian Rose wrote: > > Eddie Kohler wrote: >> Hi Ian, >> >> It's this way because even if a file descriptor was selected for both >> reading and writing, selected() is called only once. > > True, but you could just use flags right? So the function could be > redefined as Element::selected(int fd, int ops) > > and called like > elt->selected(fd, Element::SELECT_READ) > or elt->selected(fd, Element::SELECT_WRITE) > or elt->selected(fd, Element::SELECT_READ | Element::SELECT_WRITE) > >> >> It might be useful to say whether reading or writing was enabled...but >> of course in between select()'s return and the call of selected(), >> something might have happened to make the fd selectable in other ways. > > Also true, but if it was really that important to someone, they could > always do that re-checking themselves. E.g. if their selected() was > called for reading, they could also check the fd for writing "just in > case". That seems rather inefficient to me, but I guess there could be > some apps that really want to know ASAP when the fd is ready. > >> I don't feel that strongly. > > I think that adding a second function something like the following would > retain existing functionality - do you agree? > > (in element.hh) > virtual void selected(int fd, int ops); > > (in element.cc) > void > Element::selected(int fd, int ops) > { > selected(fd); > } > > >> >> Eddie >> >> >> Ian Rose wrote: >>> Hi list, >>> >>> Is there any rational for why Element::selected() doesn't tell you >>> what the file descriptor was selected for (reading vs. writing)? Or >>> is there a way to get this info that I don't know about? It seems to >>> me that if you have a FD that you are both reading and writing to >>> (like a socket) you are pretty much stuck with something like: >>> >>> void >>> Foo::selected(int fd) >>> { >>> // perhaps fd was selected for writes... >>> int rv = send(fd, ...); >>> if (rv == -1) { >>> if (errno == EAGAIN) { >>> // oops - I guess fd was actually selected for reads >>> int rv = recv(fd, ...); >>> (etc) >>> } else { >>> // this is a "real" send failure >>> } >>> } >>> // send succeeded! >>> (etc) >>> } >>> >>> Seems kinda ugly and inefficient to me... Am I missing something? >>> >>> I guess an alternative is to call select() on your fd to figure out >>> which it was selected for, but that's rather redundant! >>> >>> - Ian >>> >>> >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Wed Mar 3 13:34:48 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Wed, 03 Mar 2010 13:34:48 -0500 Subject: [Click] Element::selected() In-Reply-To: <4B8EA99E.2070905@cs.ucla.edu> References: <4B8DB469.3000707@eecs.harvard.edu> <4B8DB78E.8010907@cs.ucla.edu> <4B8DB9A9.4030900@eecs.harvard.edu> <4B8EA99E.2070905@cs.ucla.edu> Message-ID: <4B8EABC8.4050501@eecs.harvard.edu> Thanks! That was impressively speedy. Eddie Kohler wrote: > Yeah, point taken. The new interface is checked in! > > Eddie > > > Ian Rose wrote: >> >> Eddie Kohler wrote: >>> Hi Ian, >>> >>> It's this way because even if a file descriptor was selected for both >>> reading and writing, selected() is called only once. >> >> True, but you could just use flags right? So the function could be >> redefined as Element::selected(int fd, int ops) >> >> and called like >> elt->selected(fd, Element::SELECT_READ) >> or elt->selected(fd, Element::SELECT_WRITE) >> or elt->selected(fd, Element::SELECT_READ | Element::SELECT_WRITE) >> >>> >>> It might be useful to say whether reading or writing was >>> enabled...but of course in between select()'s return and the call of >>> selected(), something might have happened to make the fd selectable >>> in other ways. >> >> Also true, but if it was really that important to someone, they could >> always do that re-checking themselves. E.g. if their selected() was >> called for reading, they could also check the fd for writing "just in >> case". That seems rather inefficient to me, but I guess there could >> be some apps that really want to know ASAP when the fd is ready. >> >>> I don't feel that strongly. >> >> I think that adding a second function something like the following >> would retain existing functionality - do you agree? >> >> (in element.hh) >> virtual void selected(int fd, int ops); >> >> (in element.cc) >> void >> Element::selected(int fd, int ops) >> { >> selected(fd); >> } >> >> >>> >>> Eddie >>> >>> >>> Ian Rose wrote: >>>> Hi list, >>>> >>>> Is there any rational for why Element::selected() doesn't tell you >>>> what the file descriptor was selected for (reading vs. writing)? Or >>>> is there a way to get this info that I don't know about? It seems >>>> to me that if you have a FD that you are both reading and writing to >>>> (like a socket) you are pretty much stuck with something like: >>>> >>>> void >>>> Foo::selected(int fd) >>>> { >>>> // perhaps fd was selected for writes... >>>> int rv = send(fd, ...); >>>> if (rv == -1) { >>>> if (errno == EAGAIN) { >>>> // oops - I guess fd was actually selected for reads >>>> int rv = recv(fd, ...); >>>> (etc) >>>> } else { >>>> // this is a "real" send failure >>>> } >>>> } >>>> // send succeeded! >>>> (etc) >>>> } >>>> >>>> Seems kinda ugly and inefficient to me... Am I missing something? >>>> >>>> I guess an alternative is to call select() on your fd to figure out >>>> which it was selected for, but that's rather redundant! >>>> >>>> - Ian >>>> >>>> >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From amita.ekbote at gmail.com Thu Mar 4 01:31:18 2010 From: amita.ekbote at gmail.com (Amita Ekbote) Date: Thu, 4 Mar 2010 00:31:18 -0600 Subject: [Click] Radiotap headers patch Message-ID: Hey, I had been trying to get the autorate fallback working on click since a while. It is working now, but I noticed that the radiotap header format has changed in madwifi and has not been updated in the click code. I have the code for radiotapdecap and would like to submit a patch , how do i go about doing it? Also for all of the rate algorithms some extra values were set which dont exist in the header leading to a bunch of garbage values causing them all to fail. By all I mean the Autoratefallback, MadwifiRate and ProbeTXRate. I have edited those to make them work too. Please let me know how I can submit those changes. I would also like to know if anyone has used them recently without making any changes. Thanks! -- Amita Ekbote From amita.ekbote at gmail.com Thu Mar 4 01:31:18 2010 From: amita.ekbote at gmail.com (Amita Ekbote) Date: Thu, 4 Mar 2010 00:31:18 -0600 Subject: [Click] Radiotap headers patch Message-ID: Hey, I had been trying to get the autorate fallback working on click since a while. It is working now, but I noticed that the radiotap header format has changed in madwifi and has not been updated in the click code. I have the code for radiotapdecap and would like to submit a patch , how do i go about doing it? Also for all of the rate algorithms some extra values were set which dont exist in the header leading to a bunch of garbage values causing them all to fail. By all I mean the Autoratefallback, MadwifiRate and ProbeTXRate. I have edited those to make them work too. Please let me know how I can submit those changes. I would also like to know if anyone has used them recently without making any changes. Thanks! -- Amita Ekbote From harald at net.t-labs.tu-berlin.de Thu Mar 4 05:18:39 2010 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Thu, 04 Mar 2010 11:18:39 +0100 Subject: [Click] Feature: debug_output Message-ID: <4B8F88FF.3060501@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, since 1.8.0 is out, lets talk about features;) here are some thoughts how we do debugging output in our Elements. I think they would fit in the Element class itself. What do you think ? Here is the idea: ################ code like this: void SomeElement::push(Packet *p){ debug_output(VERB_PACKETS, "packet with ip %s pushed", ntoa( p->ip_header->ip_src ) ); } given this config: (see notes below) -> foo:SomeElement(VERBOSITY VERB_PACKETS) -> should produce this output: [foo] packet with ip 1.2.3.4 pushed and close to 0 overhead if VERB_PACKETS is not set, especially no string unparsing #################### 1): /* make the verbosity of Elements configurable. Element::configure() { ... if (cp_va_kparse(conf, this, errh, "VERBOSITY", 0, cpUnsigned, &(_verbosity), /* Question: any way of making this happen? without adding cpIgnoreRest and a call to Element::configure to all Elements? (actually it's not soooo bad, because it only needs to be added to those, who actually use debug_output) */ 2): /* get an accessor */ int Element::verbosity() const { return _verbosity; } 3): /* define a base unparse method, but allow for fancier things */ virtual String Element::unparse() const { return "[" + name() + "] " ; } 4) /* define verbosity levels, this could be an enum, of maybe some kind of magic Info thingies, */ #define VERB_NONE 0 #define VERB_ALL 0xffffffff #define VERB_ERRORS 0x01 #define VERB_WARNINGS 0x02 #define VERB_INFO 0x04 #define VERB_DEBUG 0x08 #define VERB_MFD_QUEUES 0x10 // for the MFD Handler Queues #define VERB_PACKETS 0x20 // triggered on packet handling/traversal events #define VERB_DISPATCH 0x40 // for anything related to interconnecting handlers #define VERB_MFH_STATE 0x80 / 3) /*define debug_output macro * use of a macro allows to not even evaluate the parameters if the * verbosity bit is not set -> only one bit-comparision of overhead in * this case */ #define debug_output(mask, formatstring, args...) \ if ((mask) & (this->verbosity())) { \ ErrorHandler *errh = ErrorHandler::default_handler(); \ errh->xmessage( this->unparse(), errh->format( (formatstring) , ##args ) ); \ } Open Issues ########### We can currently only do - -> foo::SomeElement(VERBOSITY 0x20) -> I know that there are provivisions for parsing named values like "VERB_ERRORS" from configure files, and I suspect there might even be stuff for "VERB_ERRORS | VERB_WARNINGS" but I haven't looked into that yet. The macro definitely needs another definition for kernel level... - -- Harald Schi?berg Technische Universit?t Berlin | T-Laboratories | FG INET www: http://www.net.t-labs.tu-berlin.de Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLj4j+y8wrZ9OvkU0RAkHYAJ9Dlvk9o9HaW6jJiBwrTzhimfbccwCg8ruW RcapoedRI1Ah/ZrzZZLlAe0= =z1jC -----END PGP SIGNATURE----- From okure at unik.no Thu Mar 4 11:25:54 2010 From: okure at unik.no (=?iso-8859-1?Q?=D8ivind_Kure?=) Date: Thu, 4 Mar 2010 17:25:54 +0100 Subject: [Click] unable to compile v1.8 userlevel Message-ID: <8F9B308633F39143BFED17C4C569F7680F2B9D5480@astana.unik.no> Running a standard ./configure -enable-all-elements -disable-linuxmodule I get the following error: CXX ../lib/task.cc ../include/click/master.hh: In member function 'void Master::timer_place::operator()(Timer**)': ../include/click/timer.hh:286: error: 'int Timer::_schedpos1' is private ../include/click/master.hh:152: error: within this context I have no problem compiling v 1.7rc and 1.6. I know, based on the previous mail on the list, that setting the _schedpos1 to public would fix the problem. However, I assume it is more likely there are some basic steps I have overlooked in the setup and configuration process, but I am not able to find it/them. Any help appreciated. Regards ?ivind Kure From johnrlane at gmail.com Thu Mar 4 12:11:05 2010 From: johnrlane at gmail.com (John Russell Lane) Date: Fri, 5 Mar 2010 02:11:05 +0900 Subject: [Click] click Digest, Vol 81, Issue 5 In-Reply-To: References: Message-ID: <882f25641003040911k634588a3k6e18a4cefcb0ace7@mail.gmail.com> Hi Holly, We've been using Click for a while on PlanetLab ... As you likely already know, PlanetLab (and Vini) run within VServers, which mean you have to do a little more work than usual to get packets into the Click router. FromDevice/ToDevice/RawSocket* and anything that relies on root privileges are known *not* to work on PlanetLab and you're generally limited to a bound Socket listening and sending on a given port (though I heard once that it was possible to get the tap device working, I've not tried). Though I think the base installation is a somewhat old Fedora Core 8, getting Click built on PL isn't particularly difficult and there is (IIRC) a click.spec file for it running around somewhere (in the Click distribution? ...). The average PL box is highly loaded, though, so if you have access to a local Core 8 install or an environment like Emulab, it's much faster to build your things there (e.g., Emulab's FEDORA8-STD image seems to work well for our work). There may be a few other annoyances/gotchas depending upon what you're looking to do; the PL users list might also be a good place to search for answers / ask questions. jrl. * Note: IIRC, there used to be support for RawSocket (the element) on PlanetLab such that it would open a socket for you and allow you to use it with the same semantics as on a normal machine (though you could only send receive on one port), provided that the IP/port information were not spoofed. This may even be documented still somewhere, but to the best of my knowledge the feature was dropped in the latest PL upgrade a year or more ago. > Date: Wed, 03 Mar 2010 09:52:12 +0100 > From: Roberto Riggio > Subject: Re: [Click] Click on Planet Lab > To: click at pdos.csail.mit.edu > Message-ID: <4B8E233C.1010507 at create-net.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > we are actually using click to run our multiradio mesh network > on planetlab+vini. Vini is useful in our case because it allows to have > performance isolation at the network level between the various slices. > > At the moment we are using some very simple topologies (string, circle). > The very interesting thing is that we can run the same code on planetlab > and on the actual wireless routers. > > We plan to put some online resources on the project website as soon as > we can cleanup scripts and codes (www.wing-project.org). > > R. > > On 03/02/2010 08:00 PM, Holly Esquivel wrote: >> Hello Fellow Click Users, >> >> I was wondering if anyone has had experience getting Click to run on >> Planet Lab nodes. I heard that it was possible but that was about it. >> Any advice you may have would be greatly appreciated as I get ready to >> try to it. >> >> Thanks! >> >> Sincerely, >> Holly From kohler at CS.UCLA.EDU Thu Mar 4 12:35:28 2010 From: kohler at CS.UCLA.EDU (Eddie Kohler) Date: Thu, 04 Mar 2010 09:35:28 -0800 Subject: [Click] unable to compile v1.8 userlevel In-Reply-To: <8F9B308633F39143BFED17C4C569F7680F2B9D5480@astana.unik.no> References: <8F9B308633F39143BFED17C4C569F7680F2B9D5480@astana.unik.no> Message-ID: <4B8FEF60.8060905@cs.ucla.edu> Hi ?ivind, I had a look at this error, which I had thought was a problem with certain compilers, and found that perhaps it was Click's fault after all. Can you please try to compile 1.8.0 with the following patch applied? You can get it by a full git clone or apply by hand, it's simple. http://www.read.cs.ucla.edu/gitweb?p=click;a=commitdiff;h=a1fc56fd95f2c4c1ce77f564770711c8d19447bc Thanks for the report. Eddie ?ivind Kure wrote: > Running a standard ./configure -enable-all-elements -disable-linuxmodule I get the following error: > > CXX ../lib/task.cc > ../include/click/master.hh: In member function 'void Master::timer_place::operator()(Timer**)': > ../include/click/timer.hh:286: error: 'int Timer::_schedpos1' is private > ../include/click/master.hh:152: error: within this context > > > I have no problem compiling v 1.7rc and 1.6. I know, based on the previous mail on the list, that setting the _schedpos1 to public would fix the problem. However, I assume it is more likely there are some basic steps I have overlooked in the setup and configuration process, but I am not able to find it/them. Any help appreciated. > Regards > ?ivind Kure > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Thu Mar 4 12:48:34 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 04 Mar 2010 09:48:34 -0800 Subject: [Click] click Digest, Vol 81, Issue 5 In-Reply-To: <882f25641003040911k634588a3k6e18a4cefcb0ace7@mail.gmail.com> References: <882f25641003040911k634588a3k6e18a4cefcb0ace7@mail.gmail.com> Message-ID: <4B8FF272.3050409@cs.ucla.edu> A bit more: Back when the PlanetLab stuff was added, you would supply Click's configure script with the "--with-proper" argument; this would enable support for the root-ish RawSocket and Socket elements. A click.spec file is in fact included in the top-level Click directory. John, if RawSocket is in fact dead I would appreciate confirmation so I can remove it from the tree. E John Russell Lane wrote: > Hi Holly, > > We've been using Click for a while on PlanetLab ... > > As you likely already know, PlanetLab (and Vini) run within VServers, > which mean you have to do a little more work than usual to get packets > into the Click router. FromDevice/ToDevice/RawSocket* and anything > that relies on root privileges are known *not* to work on PlanetLab > and you're generally limited to a bound Socket listening and sending > on a given port (though I heard once that it was possible to get the > tap device working, I've not tried). > > Though I think the base installation is a somewhat old Fedora Core 8, > getting Click built on PL isn't particularly difficult and there is > (IIRC) a click.spec file for it running around somewhere (in the Click > distribution? ...). The average PL box is highly loaded, though, so > if you have access to a local Core 8 install or an environment like > Emulab, it's much faster to build your things there (e.g., Emulab's > FEDORA8-STD image seems to work well for our work). > > There may be a few other annoyances/gotchas depending upon what you're > looking to do; the PL users list might also be a good place to search > for answers / ask questions. > > jrl. > > * Note: IIRC, there used to be support for RawSocket (the element) on > PlanetLab such that it would open a socket for you and allow you to > use it with the same semantics as on a normal machine (though you > could only send receive on one port), provided that the IP/port > information were not spoofed. This may even be documented still > somewhere, but to the best of my knowledge the feature was dropped in > the latest PL upgrade a year or more ago. > >> Date: Wed, 03 Mar 2010 09:52:12 +0100 >> From: Roberto Riggio >> Subject: Re: [Click] Click on Planet Lab >> To: click at pdos.csail.mit.edu >> Message-ID: <4B8E233C.1010507 at create-net.org> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Hi, >> >> we are actually using click to run our multiradio mesh network >> on planetlab+vini. Vini is useful in our case because it allows to have >> performance isolation at the network level between the various slices. >> >> At the moment we are using some very simple topologies (string, circle). >> The very interesting thing is that we can run the same code on planetlab >> and on the actual wireless routers. >> >> We plan to put some online resources on the project website as soon as >> we can cleanup scripts and codes (www.wing-project.org). >> >> R. >> >> On 03/02/2010 08:00 PM, Holly Esquivel wrote: >>> Hello Fellow Click Users, >>> >>> I was wondering if anyone has had experience getting Click to run on >>> Planet Lab nodes. I heard that it was possible but that was about it. >>> Any advice you may have would be greatly appreciated as I get ready to >>> try to it. >>> >>> Thanks! >>> >>> Sincerely, >>> Holly > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Thu Mar 4 13:09:48 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 04 Mar 2010 10:09:48 -0800 Subject: [Click] DS: New element: icmpipencap, a general icmppingencap In-Reply-To: <217154321003011025u6057cec4p45ec3b0b3f92c001@mail.gmail.com> References: <217154321002250902j537c55d9ha97b18e58e334efb@mail.gmail.com> <0822F3307FE52B4FAD7962B06DF51F8B032446E6@xmail01.ad.ua.ac.be> <217154321003011025u6057cec4p45ec3b0b3f92c001@mail.gmail.com> Message-ID: <4B8FF76C.6070005@cs.ucla.edu> Jens, Excellent! Thank you so much for this. The new element is added. I do have some remaining comments, so if you're willing you might consider sending another patch: * You may be able to simplify the "switch (_icmp_type)" using the "click_icmp_hl()" function, which returns the ICMP header length appropriate for a given ICMP type. This function is defined in . You would still need to set "need_seq_number" based on _icmp_type. * The TSTAMP and TSTAMPREPLY ICMP types contain more data than the other types. This data area is currently left uninitialized, so it contains garbage. This is OK, but it might be less surprising to initialize this area to zero. Something like this would do it: memset(static_cast(icmp) + sizeof(click_icmp), 0, click_icmp_hl(_type) - sizeof(click_icmp)); * The "identifier" field is only relevant i f"need_seq_number" is true. If "need_seq_number" is false, I would instead initialize the identifier and sequence number to 0 (this is like initializing the "padding" field to 0). Thanks again. Eddie Jens De Wit wrote: > Dear list, > > I send this mail in reply to Eddie's remarks on the new ICMPIPEncap element. > Attached you will find the improved version of the element, as well as a > testie file containing a basic unit test for the new element. > > Kind regards, > Jens De Wit > > > > 2010/2/28 De Wit Jens > >> ------------------------------------------- >> *Van:* Eddie Kohler[SMTP:KOHLER at CS.UCLA.EDU ] >> *Verzonden:* zondag 28 februari 2010 21:52:07 >> *Aan:* Braem Bart >> *CC:* click at amsterdam.lcs.mit.edu; De Wit Jens >> *Onderwerp:* Re: [Click] New element: icmpipencap, a general icmppingencap >> >> *Automatisch doorgezonden volgens een regel* >> >> Hi guys! >> >> Thanks very much for this element. I'd definitely like to add it to the >> repository. However, I have some concerns that if you could address, it >> would >> be great. >> >> 1. Element documentation in the header file is missing. Even just one >> paragraph plus the use case (e.g. "=c ICMPEncap(SRC, DST, TYPE [, CODE])".) >> >> 2. The _icmp_type and _icmp_code members should be read using IPNameInfo, >> so >> users can give symbolic names. E.g.: >> >> int32_t icmp_type; >> ... "TYPE", cpkP+cpkM, cpNamedInteger, NameInfo::T_ICMP_TYPE, &icmp_type, >> ... >> >> The CODE requires special handling since you need to know the TYPE before >> parsing the CODE. Take a look at ICMPError for an example. >> >> 3. This is the big one: The current element adds a clcik_icmp_echo header. >> But this header is only correct for TYPE echo or echo-reply. Other ICMP >> types >> add a different header, often with a different length. For example tstamp >> and >> tcstamp-reply have longer ehaders. See include/clicknet/icmp.h for more >> examples. Either the element should be changed to add the appropriate >> header >> for _type, or the configure() method should return an error on an >> inappropriate TYPE. >> >> Thanks very much, >> Eddie >> >> >> Braem Bart wrote: >>> Dear list, >>> >>> Attached you will find an element our students (Jens De Wit and Nico Van >> Looy) produced while working on their FireSim project, the Firewall >> Simulation in Click as presented on SyClick. >> >>> The element allows transmitting ICMP packets with all types of codes and >> types, which makes this element more general than ICMPPingEncap. It is a bit >> the ICMP alternative to UDPIPEncap. >> >>> The element code is largely based on ICMPPingEncap so Jens and Nico >> suggested just patching ICMPPingEncap with the new behaviour, although of >> course the name then does not cover the contents of the element. >> >>> Jens promised to write a unit test with the testie framework, so this can >> be expected as well. >>> best regards, >>> Bart >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From harald at net.t-labs.tu-berlin.de Thu Mar 4 13:51:31 2010 From: harald at net.t-labs.tu-berlin.de (Harald Schioeberg) Date: Thu, 04 Mar 2010 19:51:31 +0100 Subject: [Click] unable to compile v1.8 userlevel In-Reply-To: <4B8FEF60.8060905@cs.ucla.edu> References: <8F9B308633F39143BFED17C4C569F7680F2B9D5480@astana.unik.no> <4B8FEF60.8060905@cs.ucla.edu> Message-ID: <4B900133.9060703@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ?ivind Kure wrote: > Running a standard ./configure -enable-all-elements > -disable-linuxmodule I get the following error: > > CXX ../lib/task.cc > ../include/click/master.hh: In member function 'void > Master::timer_place::operator()(Timer**)': > ../include/click/timer.hh:286: error: 'int Timer::_schedpos1' is > private > ../include/click/master.hh:152: error: within this context Hi ?ivind, this sounds familiar: http://pdos.csail.mit.edu/pipermail/click/2009-October/008351.html For me, it looked a lot like the ancient compilers that OpenWRT uses to build for the WRT54GL target, since it worked on all other platforms. What compiler are you using ? Harald -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQATMACgkQy8wrZ9OvkU25OgCguYrkC+obeMDqfAdx6XMp6i34 ktgAoKySDYStmwH/t+qoq5n+cdfjl5UV =wGT6 -----END PGP SIGNATURE----- From lbro at pulz8.com Thu Mar 4 14:07:34 2010 From: lbro at pulz8.com (Lars Bro) Date: Thu, 4 Mar 2010 20:07:34 +0100 Subject: [Click] Trouble adding my own element to linuxmodule Message-ID: <22b0d68b1003041107m6f08066dt23dc80d91e645dfe@mail.gmail.com> Hi, I have written a few element classes that I need to run in an unpatched kernel. It is for the time being not possible to write a "package", so instead, I simply put a link to the directory where I keep my elements into "click/elements", then rerun configure, make clean and make. "click-buildtool findelem" correctly finds my elements , as they have for example: ... CLICK_ENDDECLS ELEMENT_REQUIRES(linuxmodule|userlevel) EXPORT_ELEMENT(WrTI) in the bottom of the .cc file A simple script: Idle() -> WrTI() -> Idle; works with the command $ click /tmp/t.click but # sudo click-install /tmp/t.click /tmp/t.click:1: unknown element class 'WrTI' Router could not be initialized! Running "nm" on /usr/local/lib/click.ko shows a lot of symbols including WrTI, The .o file (wrti.o) appears in click/linuxmodule The element appears in elements.conf and elements.cc (beetlemonkey and click_export_elements) What am I missing ?? yours, Lars Bro From kohler at cs.ucla.edu Thu Mar 4 14:27:00 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 04 Mar 2010 11:27:00 -0800 Subject: [Click] Trouble adding my own element to linuxmodule In-Reply-To: <22b0d68b1003041107m6f08066dt23dc80d91e645dfe@mail.gmail.com> References: <22b0d68b1003041107m6f08066dt23dc80d91e645dfe@mail.gmail.com> Message-ID: <4B900984.8020506@cs.ucla.edu> Hi Lars, The most likely problem is that you have an old click module still in the kernel. click-install does not uninstall + reinstall the module by default. Try "click-install -u ...", which does uninstall + reinstall the module Eddie Lars Bro wrote: > Hi, > > I have written a few element classes that I need to run in an unpatched > kernel. > > It is for the time being not possible to write a "package", so instead, I > simply put a link to the directory where I keep my elements into > "click/elements", then rerun configure, make clean and make. > "click-buildtool findelem" correctly finds my elements , as they have for > example: > ... > CLICK_ENDDECLS > ELEMENT_REQUIRES(linuxmodule|userlevel) > EXPORT_ELEMENT(WrTI) > in the bottom of the .cc file > > A simple script: > Idle() -> WrTI() -> Idle; > > works with the command > $ click /tmp/t.click > > but > > # sudo click-install /tmp/t.click > /tmp/t.click:1: unknown element class 'WrTI' > Router could not be initialized! > > Running "nm" on /usr/local/lib/click.ko shows a lot of symbols including > WrTI, > The .o file (wrti.o) appears in click/linuxmodule > The element appears in elements.conf and elements.cc (beetlemonkey and > click_export_elements) > > What am I missing ?? > > yours, > Lars Bro > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From jetever at gmail.com Thu Mar 4 21:44:19 2010 From: jetever at gmail.com (Yongheng Qi) Date: Fri, 5 Mar 2010 10:44:19 +0800 Subject: [Click] roofnet dynamic rate Message-ID: <3958ac681003041844r78f475f2kc959ba010b733ee4@mail.gmail.com> Dear everyone anyone used roofnet click script? I find roofnet mesh not include the dynamic rate. it's use the static setrate. I want to know how to make roofnet support the dynamic rate arithmetic. Thanks very much. -- Yongheng Qi Mobile: +86 1390 119 7481 From amita.ekbote at gmail.com Fri Mar 5 22:31:44 2010 From: amita.ekbote at gmail.com (Amita Ekbote) Date: Fri, 5 Mar 2010 21:31:44 -0600 Subject: [Click] Writing own element Message-ID: Hey, I am writing an element with 4 input ports and I need the processing to be 2 agnostic and 2 push. I have tried all sorts of combinations and nothing works. Cant we do "aahh" ? or ahah? or just hha ? -- Amita Ekbote From amita.ekbote at gmail.com Fri Mar 5 22:31:44 2010 From: amita.ekbote at gmail.com (Amita Ekbote) Date: Fri, 5 Mar 2010 21:31:44 -0600 Subject: [Click] Writing own element Message-ID: Hey, I am writing an element with 4 input ports and I need the processing to be 2 agnostic and 2 push. I have tried all sorts of combinations and nothing works. Cant we do "aahh" ? or ahah? or just hha ? -- Amita Ekbote From ianrose at eecs.harvard.edu Fri Mar 5 22:37:14 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Fri, 05 Mar 2010 22:37:14 -0500 Subject: [Click] Writing own element In-Reply-To: References: Message-ID: <4B91CDEA.10203@eecs.harvard.edu> What do you mean by "nothing works"? Are you getting compiler errors? Or does click give errors when you try to run it? Can you post your class' port_count() and processing() methods, your router config, and the error message? - Ian Amita Ekbote wrote: > Hey, > > I am writing an element with 4 input ports and I need the processing to be 2 > agnostic and 2 push. I have tried all sorts of combinations and nothing > works. Cant we do "aahh" ? or ahah? or just hha ? > From amita.ekbote at gmail.com Fri Mar 5 23:09:28 2010 From: amita.ekbote at gmail.com (Amita Ekbote) Date: Fri, 5 Mar 2010 22:09:28 -0600 Subject: [Click] Writing own element In-Reply-To: <4B91CDEA.10203@eecs.harvard.edu> References: <4B91CDEA.10203@eecs.harvard.edu> Message-ID: Hey, Sorry for the vague question. There are no compiler errors. Here is the declarations const char *class_name() const { return "WlaRate"; } const char *port_count() const { return "4/0-2"; } const char *processing() const { return "aah/a"; } I am running something like this.. w :: wlarate input[0] -> [2] w input[1] -> [3] w src -> [1] w -> output src -> [0] w -> output I get the following error when I run it. illegal reuse of 'w :: WlaRate' push output 0 I have used the same element with 3 inputs, I just needed to add one agnostic input port. I am assuming it expects [1]w to be a push too , if that's the case I dont know how to solve it and was hoping on suggestions as to what could be the problem. Thanks On Fri, Mar 5, 2010 at 9:37 PM, Ian Rose wrote: > What do you mean by "nothing works"? Are you getting compiler errors? Or > does click give errors when you try to run it? Can you post your class' > port_count() and processing() methods, your router config, and the error > message? > > - Ian > > > > Amita Ekbote wrote: > >> Hey, >> >> I am writing an element with 4 input ports and I need the processing to be >> 2 >> agnostic and 2 push. I have tried all sorts of combinations and nothing >> works. Cant we do "aahh" ? or ahah? or just hha ? >> >> -- Amita Ekbote From ianrose at eecs.harvard.edu Fri Mar 5 23:15:05 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Fri, 05 Mar 2010 23:15:05 -0500 Subject: [Click] Writing own element In-Reply-To: References: <4B91CDEA.10203@eecs.harvard.edu> Message-ID: <4B91D6C9.1010703@eecs.harvard.edu> The error (or at least one error) is in your config. This is not allowed because you are using w[0] twice. > src -> [1] w -> output > src -> [0] w -> output This translates to: > src -> [1] w [0] -> output > src -> [0] w [0] -> output Which I don't think is what you mean. Specify the output ports explicitly: > src -> [1] w [1] -> output > src -> [0] w [0] -> output - Ian Amita Ekbote wrote: > Hey, > > Sorry for the vague question. There are no compiler errors. > > Here is the declarations > const char *class_name() const { return "WlaRate"; } > const char *port_count() const { return "4/0-2"; } > const char *processing() const { return "aah/a"; } > > I am running something like this.. > > w :: wlarate > > input[0] -> [2] w > input[1] -> [3] w > src -> [1] w -> output > src -> [0] w -> output > > > I get the following error when I run it. > > illegal reuse of 'w :: WlaRate' push output 0 > > I have used the same element with 3 inputs, I just needed to add one > agnostic input port. I am assuming it expects [1]w to be a push too , if > that's the case I dont know how to solve it and was hoping on > suggestions as to what could be the problem. > > Thanks > > On Fri, Mar 5, 2010 at 9:37 PM, Ian Rose > wrote: > > What do you mean by "nothing works"? Are you getting compiler > errors? Or does click give errors when you try to run it? Can you > post your class' port_count() and processing() methods, your router > config, and the error message? > > - Ian > > > > Amita Ekbote wrote: > > Hey, > > I am writing an element with 4 input ports and I need the > processing to be 2 > agnostic and 2 push. I have tried all sorts of combinations and > nothing > works. Cant we do "aahh" ? or ahah? or just hha ? > > > > > -- > Amita Ekbote From amita.ekbote at gmail.com Fri Mar 5 23:18:42 2010 From: amita.ekbote at gmail.com (Amita Ekbote) Date: Fri, 5 Mar 2010 22:18:42 -0600 Subject: [Click] Writing own element In-Reply-To: <4B91D6C9.1010703@eecs.harvard.edu> References: <4B91CDEA.10203@eecs.harvard.edu> <4B91D6C9.1010703@eecs.harvard.edu> Message-ID: Thanks! It looks like that was the problem :) On Fri, Mar 5, 2010 at 10:15 PM, Ian Rose wrote: > The error (or at least one error) is in your config. This is not allowed > because you are using w[0] twice. > > > > src -> [1] w -> output > > src -> [0] w -> output > > This translates to: > > > src -> [1] w [0] -> output > > src -> [0] w [0] -> output > > Which I don't think is what you mean. Specify the output ports explicitly: > > > src -> [1] w [1] -> output > > src -> [0] w [0] -> output > > - Ian > > > Amita Ekbote wrote: > >> Hey, >> >> Sorry for the vague question. There are no compiler errors. >> Here is the declarations >> const char *class_name() const { return "WlaRate"; } >> const char *port_count() const { return "4/0-2"; } >> const char *processing() const { return "aah/a"; } >> >> I am running something like this.. >> w :: wlarate >> >> input[0] -> [2] w >> input[1] -> [3] w >> src -> [1] w -> output >> src -> [0] w -> output >> >> >> I get the following error when I run it. >> illegal reuse of 'w :: WlaRate' push output 0 >> >> I have used the same element with 3 inputs, I just needed to add one >> agnostic input port. I am assuming it expects [1]w to be a push too , if >> that's the case I dont know how to solve it and was hoping on suggestions as >> to what could be the problem. >> >> Thanks >> On Fri, Mar 5, 2010 at 9:37 PM, Ian Rose > ianrose at eecs.harvard.edu>> wrote: >> >> What do you mean by "nothing works"? Are you getting compiler >> errors? Or does click give errors when you try to run it? Can you >> post your class' port_count() and processing() methods, your router >> config, and the error message? >> >> - Ian >> >> >> >> Amita Ekbote wrote: >> >> Hey, >> >> I am writing an element with 4 input ports and I need the >> processing to be 2 >> agnostic and 2 push. I have tried all sorts of combinations and >> nothing >> works. Cant we do "aahh" ? or ahah? or just hha ? >> >> >> >> >> -- >> Amita Ekbote >> > -- Amita Ekbote From Peter.Dedecker at intec.UGent.be Sat Mar 6 11:06:30 2010 From: Peter.Dedecker at intec.UGent.be (Peter Dedecker) Date: Sat, 06 Mar 2010 17:06:30 +0100 Subject: [Click] Click userlevel performance issues Message-ID: <4B927D86.5030306@intec.UGent.be> Hi all, I've done some performance tests with the VPAN software (which you might remember from the nice talk of Jeroen at the Click Symposium ;-)) on real performant hardware. I've disabled all encryption stuff to strip it all down to almost plain Click with some routing and simple encapsulation operations. I have 3 types of nodes: - a sender takes plain IP packets from its tun0 interface, encapsulates them and sents them out on its eth0 interface. - a forwarding node takes packets from its eth0, decapsulates, looks up the next hop (like the sender also does), encapsulates the packet again, and sends it out on eth1. - the reciever is the final destination of the packets, accepts them on its eth0 interface, decapsulates them and delivers them at its tun0 interface. All quite simple and almost all the same operations though. With increasing traffic, CPU usage of the Click process increases also, which seems normal. However, a main observation on all traffic ranges, is that the sender node consequently has the highest CPU load. Forwarding nodes have a CPU load of only +/-2/3 of the sender nodes, while the destination clearly has the easiest work to do with a CPU load of only +/-1/3 compared to the forwarding node or even less than 20% of the sender's CPU load. For some figures: the click process has a CPU usage (measured with top) of 24% at a sending node, while 14% and 3% at forwarders and recievers. All nodes have a Dual-Core AMD Opteron(tm) Processor 2212 running at 2010.151 MHz with a cache size of 1024 KB, with 2 CPU's each node. Of course, as Click is single threaded, only one core will be used. Is accepting packets from a tun0 interface so hard, compared with accepting packets from the eth0 interface? I don't think expensive headroom push for packet encapsulation can be the problem, as in this configuration only an ethernet header is added with its 14 bytes being lower than the default headroom of 28 bytes. Does anyone have an explanation for this? Thanks a lot! Kind regards, -- ir. Peter Dedecker Department of Information Technology Broadband Communication Networks (IBCN) Ghent University - IBBT Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium M: +32 486152320 T: +32 9 33 14946 ; T Secr: +32 9 33 14900 F: +32 9 33 14899 E: Peter.Dedecker at intec.UGent.be W : www.ibcn.intec.UGent.be From johnrlane at gmail.com Sat Mar 6 12:35:21 2010 From: johnrlane at gmail.com (John Russell Lane) Date: Sun, 7 Mar 2010 02:35:21 +0900 Subject: [Click] click Digest, Vol 81, Issue 5 In-Reply-To: <4B8FF272.3050409@cs.ucla.edu> References: <882f25641003040911k634588a3k6e18a4cefcb0ace7@mail.gmail.com> <4B8FF272.3050409@cs.ucla.edu> Message-ID: <882f25641003060935v6d781a37p924cf1845c58230b@mail.gmail.com> Hi Eddie, > John, if RawSocket is in fact dead I would appreciate confirmation so I can > remove it from the tree. The "proper" library was definitely deprecated with the new PlanetLab release, so I don't see any reason the Click code related to it can't be removed. See: http://www.planet-lab.org/node/247 ... as well as the email included below. For those interested, proper's basic functionality was replaced by vsys: http://www.cs.princeton.edu/~sapanb/vsys/ However, with respect to Click and raw socket usage, the new PlanetLab release (4.2+) now uses netfilter (by which inbound packets are tagged / assigned to vservers), which allows, for example, "ownership" of port ranges: http://lists.planet-lab.org/pipermail/users/2009-August/003377.html http://lists.planet-lab.org/pipermail/devel/2008-February/002291.html It is my understanding that no particular user-level code changes are required to use the new functionality within a slice (another advantage over proper) and even raw sockets should work, although it is necessary to register port ranges to be used via the process described on the pages noted above and the interface here: http://planetflow.planet-lab.org/#port Finally, it seems (from the URL above) that the tun/tap interface is still not working (so FromDevice/ToDevice will still not work) and Click users are left with Socket for packet input / output; if someone knows otherwise, please say so, since I haven't tried this. Thanks! jrl. --- From: Sapan Bhatia via RT Date: Fri, Sep 12, 2008 at 2:48 AM To: johnrlane at gmail.com Hi John, Yes, Proper has been deprecated. The semantics for getting access to a restricted resources have changed, and depend on the resource you are trying to get access to. In this case, it appears that the resource is RAW sockets. All sockets have isolated RAW socket access, so if you create the socket directly instead of invoking Proper, then it should just work. Are you trying to set up IIAS? Sapan From cliff at meraki.com Sat Mar 6 14:39:50 2010 From: cliff at meraki.com (Cliff Frey) Date: Sat, 6 Mar 2010 11:39:50 -0800 Subject: [Click] Click userlevel performance issues In-Reply-To: <4B927D86.5030306@intec.UGent.be> References: <4B927D86.5030306@intec.UGent.be> Message-ID: I'd be curious what the system and interrupt times were on the various machines. Perhaps there is more linux kernel overhead in the different configurations. These numbers likely show up in top, or you can read raw values from /proc/stat and see how they are changing. Cliff On Sat, Mar 6, 2010 at 8:06 AM, Peter Dedecker < Peter.Dedecker at intec.ugent.be> wrote: > Hi all, > > I've done some performance tests with the VPAN software (which you might > remember from the nice talk of Jeroen at the Click Symposium ;-)) on > real performant hardware. I've disabled all encryption stuff to strip it > all down to almost plain Click with some routing and simple > encapsulation operations. > > I have 3 types of nodes: > - a sender takes plain IP packets from its tun0 interface, encapsulates > them and sents them out on its eth0 interface. > - a forwarding node takes packets from its eth0, decapsulates, looks up > the next hop (like the sender also does), encapsulates the packet again, > and sends it out on eth1. > - the reciever is the final destination of the packets, accepts them on > its eth0 interface, decapsulates them and delivers them at its tun0 > interface. > > All quite simple and almost all the same operations though. With > increasing traffic, CPU usage of the Click process increases also, which > seems normal. However, a main observation on all traffic ranges, is that > the sender node consequently has the highest CPU load. Forwarding nodes > have a CPU load of only +/-2/3 of the sender nodes, while the > destination clearly has the easiest work to do with a CPU load of only > +/-1/3 compared to the forwarding node or even less than 20% of the > sender's CPU load. For some figures: the click process has a CPU usage > (measured with top) of 24% at a sending node, while 14% and 3% at > forwarders and recievers. All nodes have a Dual-Core AMD Opteron(tm) > Processor 2212 running at 2010.151 MHz with a cache size of 1024 KB, > with 2 CPU's each node. Of course, as Click is single threaded, only one > core will be used. > > Is accepting packets from a tun0 interface so hard, compared with > accepting packets from the eth0 interface? I don't think expensive > headroom push for packet encapsulation can be the problem, as in this > configuration only an ethernet header is added with its 14 bytes being > lower than the default headroom of 28 bytes. Does anyone have an > explanation for this? Thanks a lot! > > Kind regards, > > -- > ir. Peter Dedecker > Department of Information Technology > Broadband Communication Networks (IBCN) > Ghent University - IBBT > Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium > M: +32 486152320 > T: +32 9 33 14946 ; T Secr: +32 9 33 14900 > F: +32 9 33 14899 > E: Peter.Dedecker at intec.UGent.be > W : www.ibcn.intec.UGent.be > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From kohler at cs.ucla.edu Sat Mar 6 18:37:41 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 15:37:41 -0800 Subject: [Click] Click on FreeBSD 7.1 amd64 In-Reply-To: <4B6A0A76.6010706@colorado.edu> References: <4B6A0A76.6010706@colorado.edu> Message-ID: <4B92E745.7060102@cs.ucla.edu> Hi Tyler, Some patches from Nikola Kne?evi? were recently added that may have fixed this error. Could you take a look and report any further problems you have? Eddie Tyler Schoenke wrote: > Hi, > > I'm trying to compile Click! on FreeBSD 7.1 amd64. I got past a couple > compile errors, but am stuck at this one: > > CXX ../elements/bsdmodule/anydevice.cc > CXX ../elements/bsdmodule/fastudpsrc.cc > In file included from ../elements/bsdmodule/fastudpsrc.cc:19: > ../elements/bsdmodule/fastudpsrc.hh:61: error: expected class-name > before '{' token > ../elements/bsdmodule/fastudpsrc.hh:83: error: 'GapRate' does not name a > type > ../elements/bsdmodule/fastudpsrc.hh:95: error: 'Vector' has not been > declared > ../elements/bsdmodule/fastudpsrc.hh:95: error: expected ',' or '...' > before '<' token > ../elements/bsdmodule/fastudpsrc.hh:96: error: 'ErrorHandler' has not > been declared > ../elements/bsdmodule/fastudpsrc.hh:97: error: 'CleanupStage' has not > been declared > ../elements/bsdmodule/fastudpsrc.hh:98: error: expected ';' before '*' token > ../elements/bsdmodule/fastudpsrc.hh: In member function 'const char* > FastUDPSource::port_count() const': > ../elements/bsdmodule/fastudpsrc.hh:92: error: 'PORTS_0_1' was not > declared in this scope > ../elements/bsdmodule/fastudpsrc.hh: In member function 'const char* > FastUDPSource::processing() const': > ../elements/bsdmodule/fastudpsrc.hh:93: error: 'PULL' was not declared > in this scope > ../elements/bsdmodule/fastudpsrc.cc: At global scope: > ../elements/bsdmodule/fastudpsrc.cc:40: error: 'int > FastUDPSource::configure' is not a static member of 'class FastUDPSource' > ../elements/bsdmodule/fastudpsrc.cc:40: error: 'Vector' was not declared > in this scope > ../elements/bsdmodule/fastudpsrc.cc:40: error: 'String' was not declared > in this scope > ../elements/bsdmodule/fastudpsrc.cc:40: error: 'conf' was not declared > in this scope > ../elements/bsdmodule/fastudpsrc.cc:40: error: 'ErrorHandler' was not > declared in this scope > ../elements/bsdmodule/fastudpsrc.cc:40: error: 'errh' was not declared > in this scope > ../elements/bsdmodule/fastudpsrc.cc:41: error: expected ',' or ';' > before '{' token > gmake: *** [fastudpsrc.o] Error 1 > *** Error code 2 > > Any ideas? > > Thanks, > > Tyler > > From kohler at cs.ucla.edu Sat Mar 6 18:53:27 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 15:53:27 -0800 Subject: [Click] IP6 enanle problem In-Reply-To: <329a00810904191753i3d729285sc56d011083820563@mail.gmail.com> References: <329a00810904191753i3d729285sc56d011083820563@mail.gmail.com> Message-ID: <4B92EAF7.60009@cs.ucla.edu> The answer is to supply "--enable-ip6" to Click's "./configure" script. E ?? wrote: > Hi, everyone. I have a problem when using click router. I need some > function which supports ipv6, or there are errors like "undefined type > ip6_addr" when using click. > i think the reason is the HAVE_IP6 in the 'config.h' is not defined by > deafault. > I modified "configure.in" and replace line "ELEMENTS_ARG_ENABLE(ip6, > [include IPv6 elements (EXPERIMENTAL)], NO, AC_DEFINE(HAVE_IP6))" > with "ELEMENTS_ARG_ENABLE(ip6, [include IPv6 elements], yes)" , but > after "./configure" the argument of HAVE_IP6 is still not enabled. > At last I manually replace the line "/* #undef HAVE_IP6 */" with > "#define HAVE_IP6 1" , but after that when i use "make install" it > reports errors as follows: > > /home/sirs/Desktop/click-1.6.0/userlevel/../lib/confparse.cc:4752: > undefined reference to `IP6FlowID_linker_trick' > libclick.a(confparse.o): In function `cp_ip6_prefix(String const&, > unsigned char*, int*, bool, Element*)': > /home/sirs/Desktop/click-1.6.0/userlevel/../lib/confparse.cc:2418: > undefined reference to `IP6Address::IP6Address(unsigned char const*)' > /home/sirs/Desktop/click-1.6.0/userlevel/../lib/confparse.cc:2418: > undefined reference to `IP6Address::mask_to_prefix_len() const' > libclick.a(confparse.o): In function `cp_ip6_prefix(String const&, > unsigned char*, unsigned char*, bool, Element*)': > /home/sirs/Desktop/click-1.6.0/userlevel/../lib/confparse.cc:2440: > undefined reference to `IP6Address::make_prefix(int)' > libclick.a(addressinfo.o): In function > `AddressInfo::configure(Vector&, ErrorHandler*)': > /home/sirs/Desktop/click-1.6.0/userlevel/../elements/standard/addressinfo.cc:96: > undefined reference to `IP6Address::make_prefix(int)' > libclick.a(addressinfo.o): In function `operator~': > /home/sirs/Desktop/click-1.6.0/userlevel/../include/click/ip6address.hh:171: > undefined reference to `IP6Address::IP6Address()' > libclick.a(addressinfo.o): In function `operator&': > /home/sirs/Desktop/click-1.6.0/userlevel/../include/click/ip6address.hh:149: > undefined reference to `IP6Address::IP6Address()' > collect2: ld returned 1 exit status > make[1]: *** [click] Error 1 > make[1]: Leaving directory `/home/sirs/Desktop/click-1.6.0/userlevel' > make: *** [install] Error 1 > > ps. I also tried the 1.7.0 version and the errors are the same. > > so I try to enable IP6 functions and failed. Would anyone tell me how to do it? > Thanks > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Sat Mar 6 19:03:13 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 16:03:13 -0800 Subject: [Click] User defined deterministic NAT Table In-Reply-To: References: Message-ID: <4B92ED41.2030106@cs.ucla.edu> Hi, I've just looked briefly at the IPAddrPairRewriter, which is closest to your requirements. One could add to it "add" and "remove" handlers. It would work, but not the most natural fit. The IPMapper interface would be pretty simple to use however. Take a look at RoundRobinIPMapper (elements/ip/rripmapper.{cc,hh}) for a simple example. (SourceIPHashMapper is another.) You pretty much just override one function, rewrite_flowid(). Then you define the desired IPMapper element in your config, and proivide the element name instead of a pattern to the IPAddrPairRewriter configuration. ALternatively a brand new element wouldn't be too bad. If you were interested in contributing your work, so much the better. Eddie Latency Buster wrote: > I am trying to do some pretty basic NATing but with the only > requirement that the NAT mapping table should be user driven. For NAT > I would like to change the tuple (SA,DA) pair to (SA`, DA`) but the > user should be able to drive the mapping from SA->SA` and DA->DA`. > Ideally, this should look something like, IPAddrMapper (SA - SA` DA - > DA`, ..., ..,). > > Is there any existing elements that would allow me to achieve such a > functionality? I looked around IPAddrRewriter() and IPRwriter but they > do not allow the fine control of the address mapping (as I > understand). Else, I am planning to write one. > > Thanks, > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Sat Mar 6 19:11:28 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 16:11:28 -0800 Subject: [Click] BUG: warning at kernel/softirq.c:120/_local_bh_enable() with HashTable In-Reply-To: <4936C468.9010400@gmail.com> References: <4936C468.9010400@gmail.com> Message-ID: <4B92EF30.8040000@cs.ucla.edu> Hi Alessandro, Well... it's been a while since you wrote; apologies. If you're still experiencing a problem like this with newer code, do let us know. The backtrace is surprising to me. Normally I would *not* expect StatTable::insert_pre_stat to show up after FromDevice::got_skb, because got-skb does not push packets downwards through the configuration. Of course Linux backtraces are often pretty iffy. I assume that StatInfo didn't do anything crazy like send a packet or anything... Eddie Alessandro Erta wrote: > Hi all! > > I have written two elements to collect statistics from wireless cards > like e.g. link RSSI ecc. Specifically, one element periodically reads > the statistics and sends packets to the other one which is just a table > to store them implemented with a hashtable. Click is running in kernel > mode with kernel 2.6.19.2 with two wireless cards and madwifi driver. > The system is single-threaded and the kernel preemption is disabled. > Everything works fine but sometimes I get kernel bugs like the following: > > BUG: warning at kernel/softirq.c:120/_local_bh_enable() > [] _local_bh_enable+0x45/0xa4 > [] do_softirq+0x22/0x26 > [] do_IRQ+0x67/0x7a > [] net_rx_action+0x5d/0xd8 > [] common_interrupt+0x1a/0x20 > [] > _ZN9StatTable15insert_pre_statEP13pre_link_stat+0x2633/0x42a0 [click] > [] zz02dc1763+0x18f/0x1bc [ath_hal] > [] ath_intr+0x500/0x68a [ath_pci] > [] handle_IRQ_event+0x26/0x4e > [] kfree_skbmem+0x70/0x74 > [] _ZN10FromDevice7got_skbEP7sk_buff+0xcc/0x140 [click] > ............ > > The bug shows up during the insertion function > StatTable::insert_pre_stat. The funny thing is that if I comment the > hashtable data insertion in StatTable::insert_pre_stat I cannot > reproduce it. The way I do insertion in the table is as follows: > > IPAddress ip = new_ip; > if ( _table_data.find( ip ) == _table_data.end() ) { // check if IP > already present > _table_data[ ip ] = StatInfo(ip); > } > _table_data[ ip ].par1 = par1; > _table_data[ ip ].par2 = par2; > ... > > I cannot see anything wrong in the above code, but commenting it > prevents the bug from occuring. Any Ideas? > > Thanks a lot! > > Regards, > Alessandro > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Sat Mar 6 19:21:26 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 16:21:26 -0800 Subject: [Click] e1000 transmit lockups? Message-ID: <4B92F186.8080608@cs.ucla.edu> Dear Click e1000 users, Is anyone still seeing occasional errors at driver install time, where an e000 reports "e1000_clean_tx_irq: Detected Tx Unit Hang" and refuses to send packets? Kevin Springborn sent the forwarded mail 2 years ago (THANKS KEVIN!!!), which mentioned this problem and contained a fix. However, it does not seem like Joonwoo's drivers contain the patch. I don't know whether the drivers themselves have evolved enough so as not to need the patch, or whether the bug is still happening. Please let me know. Thanks for your patience, Eddie -------------- next part -------------- An embedded message was scrubbed... From: springbo at cs.wisc.edu Subject: [Click] e1000 polling tx_ring lockup patch Date: Thu, 10 Jan 2008 17:43:34 -0600 (CST) Size: 9210 Url: http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100306/26af5779/attachment.eml From kohler at cs.ucla.edu Sat Mar 6 19:33:55 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 16:33:55 -0800 Subject: [Click] NAT Latency Measurement In-Reply-To: References: Message-ID: <4B92F473.4000508@cs.ucla.edu> Hi, For what it's worth -- 1. We believe the newer IPRewriter elements, which were released slightly before 1.8.0, are faster than the the older elements -- perhaps even significantly. But I don't have specific measurements to report. 2. When doing more in-depth Click performance analysis (YEARS AGO) we used performance counter elements like SetCycleCount -> IPRewriter -> CycleCountAccum. If I was doing it now I might profile at userlevel using IP summary dumps. Eddie Latency Buster wrote: > Does anyone has a rough estimate of the port to port latency of NAT > using Click? I'm using a combination of IPClassifier, IPRewriter and > seeing the port to port latency varying between between 20 - 30 us. > This is when the IPRewriter has a single mapping instance and I am > using PollDevice for pulling packets. > > rw :: IPRewriter ( // > pattern 192.16.13.24 - 192.16.14.26 - 0 1, //Active > ) > > > A related question: What's the approach to nail down the most delay > prone element along the packet path inside Click? In my instance, > Click is running on Intel Xeon processor (quad core), PCIe cards and > with 8GB RAM. > > > Thanks, > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Sat Mar 6 19:34:17 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 16:34:17 -0800 Subject: [Click] help about fromdevice In-Reply-To: <657242.568471260882516455.JavaMail.javamailuser@localhost> References: <726412.2151.qm@web15301.mail.cnb.yahoo.com> <657242.568471260882516455.JavaMail.javamailuser@localhost> Message-ID: <4B92F489.8000306@cs.ucla.edu> ... and the element that does this is ToDump. E Leo Lee wrote: > As far as I know, Click can store packets in a file which like stored by tcpdump/wireshark > > > ?2009-12-01?"?? ?" ??? > > hi, > I have a question that I want to use click to capture packets and store them in pcap files and I want to know that where do the pcap files captured store? > > Waiting to hear from you! Thank you very much! > > Yours sinceryly, > Aaron Shu > > > ___________________________________________________________ > ????????????????? > http://card.mail.cn.yahoo.com/ > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Sat Mar 6 19:47:41 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 16:47:41 -0800 Subject: [Click] VLAN Switch implementation In-Reply-To: <1246438639.1759.3.camel@fadjar-laptop> References: <1246438639.1759.3.camel@fadjar-laptop> Message-ID: <4B92F7AD.9050406@cs.ucla.edu> Fadjar, There aren't any official VLAN elements in the Click repository yet, but Thomas Asa Paine at Wisconsin did send some elements a while ago: http://www.mail-archive.com/click at amsterdam.lcs.mit.edu/msg02949.html If you try them let us know your experiences. Eddie Fadjar Tandabawana wrote: > Dear All, > > I'm newbie in Click Modular router. > I already read the archive of this milist but I did not find the VLAN > solution for the switching element. > > I'm glad if there any documents or another resources concerning this > matter. > > Please help > > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Sat Mar 6 20:06:04 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 17:06:04 -0800 Subject: [Click] UDPIP6Encap element In-Reply-To: <4A5597EB.3090607@intec.ugent.be> References: <4A5597EB.3090607@intec.ugent.be> Message-ID: <4B92FBFC.1010300@cs.ucla.edu> Hi Wim, Thanks for this element! I've added it to the tree. And another message is coming. Eddie Wim Vandenberghe wrote: > Hello, > > in attachment you can find an IPv6 version of the UDPIPEncap element. > Maybe this could be interesting to include in the Click distribution. > > There are two remarks that should be made: > > * The checksum calculation does not take the possible presence of > routing headers into account. But because the element encapsulates > with an IPv6 header without a routing header extension, this > shouldn't be a problem > * The small block of code that checks the alignment is not yet > updated to IPv6. I did not understand that block of code > completely, maybe someone from the Click community with more > experience in this field can have a look at those lines. > > > Kind regards, > > Wim > > -- > Wim Vandenberghe > Researcher > IBBT - IBCN - Ghent University > Gaston Crommenlaan 8 bus 201 > 9050 Gent, Belgium > E-mail: wim.vandenberghe at intec.UGent.be > Tel. +32 9 33 14981 > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Sat Mar 6 20:11:33 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 17:11:33 -0800 Subject: [Click] Request for project: click_in6_cksum_pseudohdr Message-ID: <4B92FD45.5070704@cs.ucla.edu> Hey guys, This is a quick note about Click's IPv6 checksum functions, which are defined in lib/ip6address.cc. I believe that these functions are badly designed and slow. The IPv6 checksum operation is the same as the IPv4, except for the pseudoheader calculation; but these functions do them both, and the "fast" version isn't particularly fast. I would love to see a contribution of a click_in6_cksum_pseudohdr function, which would have roughly the same interface as click_in_cksum_pseudohdr. Any interest? Eddie From kohler at cs.ucla.edu Sat Mar 6 20:16:44 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sat, 06 Mar 2010 17:16:44 -0800 Subject: [Click] problem with StaticIPLookup In-Reply-To: <003401ca2ca9$dc3a1690$6801a8c0@D674VYB1> References: <003401ca2ca9$dc3a1690$6801a8c0@D674VYB1> Message-ID: <4B92FE7C.70407@cs.ucla.edu> Victor, I don't think you have really asked a question here. StaticIPLookup takes arguments that define the routing table. An argument like "192.168.1.0/255.255.255.0 1", says "packets that match 192.168.1.x should be sent to output 1". And output 1 of the StaticIPLookup is sent eventually to eth0. If you want those packets to be sent to eth1 instead, then just change either the routing table entry (specify output 2), or the config (route rt[1] to eth1, and rt[2] to eth0). E Victor wrote: > I am really confused with how "StaticIPLookup" is used for packet forwarding > in basic-router > > In my basic-router I (see below ) I have configuration for the forwarding > between 192.168.1.x and 192.168.10.x where (as far as can see ) > StaticIPLookup output 1 of 192.168.1.x is sent back to eth0, StaticIPLookup > output2 of 192.168.10.x is sent back to eth1, and both are sent to the local > stack (ToHost). > > Can someone be so kind to explain the forwarding logic? I would expect to > see something like: > > "take output of 192.168.1.x, if destination address belongs to 192.168.10.x > - send it to eth1". > > Or, is my basic-router.click not created correctly? > > Thanks > > Student of click > > > > Basic-router.click > > > > // eth0 192.168.1.176 00:00:C0:3B:71:EF > > // eth1 192.168.10.1 00:00:C0:CA:68:EF > > // Shared IP input path and routing table ip :: Strip(14) > > -> CheckIPHeader(INTERFACES 192.168.1.176/255.255.255.0 > > 192.168.10.1/255.255.255.0) > > -> rt :: StaticIPLookup( > > 192.168.1.176/32 0, > > 192.168.1.255/32 0, > > 192.168.1.0/32 0, > > 192.168.10.1/32 0, > > 192.168.10.255/32 0, > > 192.168.10.0/32 0, > > 192.168.1.0/255.255.255.0 1, > > 192.168.10.0/255.255.255.0 2, > > 255.255.255.255/32 0.0.0.0 0, > > 0.0.0.0/32 0, > > 0.0.0.0/0.0.0.0 18.26.4.1 1); > > // Input and output paths for eth0 > > c0 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -); > > PollDevice(eth0) -> c0; > > out0 :: Queue(200) -> todevice0 :: ToDevice(eth0); > > c0[0] -> ar0 :: ARPResponder(192.168.1.176 00:00:C0:3B:71:EF) -> out0; > > arpq0 :: ARPQuerier(192.168.1.176, 00:00:C0:3B:71:EF) -> out0; > > c0[1] -> arpt; > > arpt[0] -> [1]arpq0; > > c0[2] -> Paint(1) -> ip; > > c0[3] -> Print("eth0 non-IP") -> Discard; > > > > // Input and output paths for eth1 > > c1 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -); > > PollDevice(eth1) -> c1; > > out1 :: Queue(200) -> todevice1 :: ToDevice(eth1); > > c1[0] -> ar1 :: ARPResponder(192.168.10.1 00:00:C0:CA:68:EF) -> out1; > > arpq1 :: ARPQuerier(192.168.10.1, 00:00:C0:CA:68:EF) -> out1; > > c1[1] -> arpt; > > arpt[1] -> [1]arpq1; > > c1[2] -> Paint(2) -> ip; > > c1[3] -> Print("eth1 non-IP") -> Discard; > > > > // Local delivery > > toh :: ToHost; > > arpt[2] -> toh; > > rt[0] -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2) -> toh; > > > > // Forwarding path for eth0 > > rt[1] -> DropBroadcasts > > -> cp0 :: PaintTee(1) > > -> gio0 :: IPGWOptions(192.168.1.176) > > -> FixIPSrc(192.168.1.176) > > -> dt0 :: DecIPTTL > > -> fr0 :: IPFragmenter(1500) > > -> [0]arpq0; > > dt0[1] -> ICMPError(192.168.1.176, timeexceeded) -> rt; > > fr0[1] -> ICMPError(192.168.1.176, unreachable, needfrag) -> rt; > > gio0[1] -> ICMPError(192.168.1.176, parameterproblem) -> rt; > > cp0[1] -> ICMPError(192.168.1.176, redirect, host) -> rt; > > > > // Forwarding path for eth1 > > rt[2] -> DropBroadcasts > > -> cp1 :: PaintTee(2) > > -> gio1 :: IPGWOptions(192.168.10.1) > > -> FixIPSrc(192.168.10.1) > > -> dt1 :: DecIPTTL > > -> fr1 :: IPFragmenter(1500) > > -> [0]arpq1; > > dt1[1] -> ICMPError(192.168.10.1, timeexceeded) -> rt; > > fr1[1] -> ICMPError(192.168.10.1, unreachable, needfrag) -> rt; > > gio1[1] -> ICMPError(192.168.10.1, parameterproblem) -> rt; > > cp1[1] -> ICMPError(192.168.10.1, redirect, host) -> rt; > > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From rajaram_s at yahoo.com Sun Mar 7 11:01:35 2010 From: rajaram_s at yahoo.com (Raj Sidh) Date: Sun, 7 Mar 2010 08:01:35 -0800 (PST) Subject: [Click] Help! 2.6.18 kernel panic with click 1.6.0 In-Reply-To: <4B89C37E.6090908@cs.ucla.edu> References: <748114.4682.qm@web50912.mail.re2.yahoo.com> <4B89C37E.6090908@cs.ucla.edu> Message-ID: <895372.38048.qm@web50903.mail.re2.yahoo.com> Eddie, Thanks for the follow up email. During my attempts to avoid the kernel panic earlier, I figured the panic was somehow related to the ipfilter.cc under certain conditions. When I replaced the ipfilter.cc with the one from 1.5pre then panic halted! Due to other task pressure I did not drill deeper at that point. I thought probably it was the way I was using the element. I will try out the newer source and verify on my router soon. Thanks again. Rajaram ----- Original Message ---- From: Eddie Kohler To: Raj Sidh Cc: click at amsterdam.lcs.mit.edu Sent: Sat, February 27, 2010 5:14:38 PM Subject: Re: [Click] Help! 2.6.18 kernel panic with click 1.6.0 Raj, It looks like people have recently run into a similar bug, but the bug appears now to be fixed. Please try with the current sources if you can. E Raj Sidh wrote: > Hi, > > I am running click kernel module over centos 5 which I patched to accept click 1.6.0. I am getting kernel panics time to time when the traffic is going on. Please see couple oops dumps below. I had customized the click to expect VLAN packets and process, though I am not sure whether that is causing the issue. A newbie to the kernel space and oops, I will appreciate any leads on what could be going wrong and advice. Thanks a lot! - Rajaram > > Oops #1 > ======= > > BUG: unable to handle kernel NULL pointer dereference at virtual address 00000001 > printing eip: > c04d0cba > *pde = 00000000 > Oops: 0000 [#1] > last sysfs file: /class/net/fake4/address > Modules linked in: click(U) proclikefs(U) deflate(U) zlib_deflate(U) af_key(U) pk_drv(PU) ipv6(U) xfrm_nalgo(U) crypto_api(U) autofs4(U) dm_mirror(U) dm_log(U) dm_multipath(U) scsi_dh(U) dm_mod(U) video(U) sbs(U) backlight(U) i2c_ec(U) i2c_core(U) button(U) battery(U) asus_acpi(U) ac(U) parport_pc(U) lp(U) parport(U) joydev(U) ata_piix(U) i5000_edac(U) edac_mc(U) pcspkr(U) libata(U) e1000e(U) bnx2(U) ide_cd(U) serio_raw(U) cdrom(U) cciss(U) sd_mod(U) scsi_mod(U) ext3(U) jbd(U) uhci_hcd(U) ohci_hcd(U) ehci_hcd(U) > CPU: 0 > EIP: 0060:[] Tainted: P VLI > EFLAGS: 00010082 (2.6.18-click.patched.1 #1) > EIP is at list_del+0x6/0x5c > eax: 00000001 ebx: f61a6d40 ecx: f7fff0c0 edx: 00000000 > esi: f7ffd440 edi: f675a000 ebp: f7fff7c0 esp: c06eaf6c > ds: 007b es: 007b ss: 0068 > Process kclick (pid: 2277, ti=c06ea000 task=f7a17000 task.ti=f7924000) > Stack: f61a6d40 c045a5f6 00000000 0000000c 0000000b f7ffc180 0000000c 00000000 > f7fff7c0 f7ffc140 c045a43e 00000000 f7ffc140 f672d000 00000286 0000000a > c045a4ab f665c550 f7e63b5c 00000007 c04183a0 c0719060 c042690d c07190dc > Call Trace: > [] free_block+0x67/0xda > [] cache_flusharray+0x53/0x6e > [] kfree+0x52/0x61 > [] free_task+0x16/0x23 > [] __rcu_process_callbacks+0xcf/0x128 > [] rcu_process_callbacks+0xf/0x1e > [] tasklet_action+0x58/0x97 > [] __do_softirq+0x5d/0xc6 > [] do_softirq+0x3b/0x85 > [] local_bh_enable+0x66/0x71 > [] _ZN8ToDevice8run_taskEP4Task+0x13f/0x400 [click] > [] _ZN12RouterThread6driverEv+0x177/0x290 [click] > [] _Z11click_schedPv+0x82/0x130 [click] > [] _Z11click_schedPv+0x0/0x130 [click] > [] kernel_thread_helper+0x7/0x10 > ======================= > Code: 8d 4b 04 8b 51 04 8d 46 04 e8 73 00 00 00 8d 4b 0c 8b 51 04 8d 46 0c 5b 5e 5f e9 62 00 00 00 89 c3 eb eb 90 90 53 89 c3 8b 40 04 <8b> 00 39 d8 74 17 50 53 68 a9 62 61 c0 e8 93 9c f4 ff 0f 0b 41 > EIP: [] list_del+0x6/0x5c SS:ESP 0068:c06eaf6c > <0>Kernel panic - not syncing: Fatal exception in interrupt > > > > Oops #2 > ======= > > ------------[ cut here ]------------ > > kernel BUG at mm/slab.c:1605! > > invalid opcode: 0000 [#1] > > last sysfs file: /class/net/fake2/address > > Modules linked in: click(U) proclikefs(U) deflate(U) zlib_deflate(U) af_key(U) pk_drv(PU) ipv6(U) xfrm_nalgo(U) crypto_api(U) autofs4(U) dm_mirror(U) dm_log(U) dm_multipath(U) scsi_dh(U) dm_mod(U) video(U) sbs(U) backlight(U) i2c_ec(U) i2c_core(U) button(U) battery(U) asus_acpi(U) ac(U) parport_pc(U) lp(U) parport(U) joydev(U) pcspkr(U) ata_piix(U) i5000_edac(U) edac_mc(U) libata(U) e1000e(U) bnx2(U) ide_cd(U) serio_raw(U) cdrom(U) cciss(U) sd_mod(U) scsi_mod(U) ext3(U) jbd(U) uhci_hcd(U) ohci_hcd(U) ehci_hcd(U) > > CPU: 0 > > EIP: 0060:[] Tainted: P VLI > > EFLAGS: 00010046 (2.6.18-click.patched.1 #1) > > EIP is at kmem_freepages+0x49/0x97 > > eax: c0080000 ebx: f7fff7c0 ecx: c5800000 edx: 00000000 > > esi: 00000001 edi: 00000000 ebp: 00000000 esp: c06eaf50 > > ds: 007b es: 007b ss: 0068 > > Process kclick (pid: 2289, ti=c06ea000 task=f7fb0000 task.ti=f619e000) > > Stack: f7fff7c0 f5e25680 00000000 c045a576 f5e25680 f7ffd440 f5e37fff f7fff7c0 > > c045a630 00000aa0 0000000c 00000007 f7ffc170 0000000c 00000000 f7fff7c0 > > f7ffc140 c045a43e 00000000 f7ffc140 f5caf000 00000286 00000001 c045a4ab > > Call Trace: > > [] slab_destroy+0x53/0x6c > > [] free_block+0xa1/0xda > > [] cache_flusharray+0x53/0x6e > > [] kfree+0x52/0x61 > > [] free_task+0x16/0x23 > > [] __rcu_process_callbacks+0xcf/0x128 > > [] rcu_process_callbacks+0xf/0x1e > > [] tasklet_action+0x58/0x97 > > [] __do_softirq+0x5d/0xc6 > > [] do_softirq+0x3b/0x85 > > [] local_bh_enable+0x66/0x71 > > [] _ZN8ToDevice8run_taskEP4Task+0x13f/0x400 [click] > > [] _ZN12RouterThread6driverEv+0x177/0x290 [click] > > [] _Z11click_schedPv+0x82/0x130 [click] > > [] _Z11click_schedPv+0x0/0x130 [click] > > [] kernel_thread_helper+0x7/0x10 > > ======================= > > Code: c1 e1 05 03 0d b0 53 72 c0 8b 01 c1 e8 1e 8b 04 85 84 f6 6a c0 01 90 0c 01 00 00 01 15 2c fd 71 c0 89 f2 eb 15 8b 01 84 c0 78 08 <0f> 0b 45 06 d8 cb 60 c0 0f ba 31 07 83 c1 20 4a 83 fa ff 75 e5 > > EIP: [] kmem_freepages+0x49/0x97 SS:ESP 0068:c06eaf50 > > <0>Kernel panic - not syncing: Fatal exception in interrupt > > > > > > Note: ==== > The tainted "P" is due to Version info missing for a module. The crash happens with or without that module. > > > > In case helpful: snippet of the change in tohost.cc to accomodate vlan as follows in ToHost::push() > ========================================================================= > > if ((skb->nh.raw - skb->data) > 14) { > skb_pull(skb, skb->nh.raw - skb->data); > } > else > skb_pull(skb, 14); > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) > const ethhdr *eth = eth_hdr(skb); > #else > const ethhdr *eth = skb->mac.ethernet; > #endif > unsigned short proto = ntohs(eth->h_proto); > > if (proto == ETH_P_8021Q) { > const vlan_ethhdr* veth = vlan_eth_hdr(skb); > proto = ntohs(veth->h_vlan_encapsulated_proto); > } > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From fanyang.scu at gmail.com Mon Mar 8 01:12:38 2010 From: fanyang.scu at gmail.com (Jimmy) Date: Mon, 8 Mar 2010 01:12:38 -0500 Subject: [Click] Record queue length overtime Message-ID: <2fe59bbc1003072212j1947f1c5k2a28de4c86f1f986@mail.gmail.com> Hello all, Using handlers, I know how to record the total queue length. -> ct :: Queue(50) -> TimedUnqueue(1) -> ccl :: Counter -> Print(TIMESTAMP true) -> Discard; DriverManager(pause, print >>log cnt.count, print >>log ct.length, print >>log ccl.count) Here, -> Print(TIMESTAMP true) command can print received packets overtime on screen, I mean it can show when each packet is received. But in DriverManager, I can only record the number of packets I received when I stop this program. How can I record the overtime information of received packets or the number of packets in the queue? I mean is it possible to record the number of packets in the queue for every second? Another question is that are there any source elements relating to an exponential or poisson packets source (thus the arrival rate of packets is exponential or poisson distributed). Thank you very much for your help! -- Best Regards, Jimmy From cliff at meraki.com Mon Mar 8 02:06:50 2010 From: cliff at meraki.com (Cliff Frey) Date: Sun, 7 Mar 2010 23:06:50 -0800 Subject: [Click] Record queue length overtime In-Reply-To: <2fe59bbc1003072212j1947f1c5k2a28de4c86f1f986@mail.gmail.com> References: <2fe59bbc1003072212j1947f1c5k2a28de4c86f1f986@mail.gmail.com> Message-ID: You can easily do that with a Script element... you could use either 'read' or 'print' to display the data. If you wanted even more control, you could add a ControlSocket to your config and then write a script that would access the ControlSocket. Here is an example script element that should do what you want. Cliff Script(wait 1.0, read ct.length, loop); On Sun, Mar 7, 2010 at 10:12 PM, Jimmy wrote: > Hello all, > > Using handlers, I know how to record the total queue length. > > -> ct :: Queue(50) > > -> TimedUnqueue(1) > > -> ccl :: Counter > > -> Print(TIMESTAMP true) > > -> Discard; > > DriverManager(pause, > print >>log cnt.count, > print >>log ct.length, > print >>log ccl.count) > > Here, -> Print(TIMESTAMP true) command can print received packets > overtime on screen, I mean it can show when each packet is received. > > But in DriverManager, I can only record the number of packets I > received when I stop this program. > > How can I record the overtime information of received packets or the > number of packets in the queue? I mean is it possible to record the > number of packets in the queue for every second? > > Another question is that are there any source elements relating to an > exponential or poisson packets source (thus the arrival rate of > packets is exponential or poisson distributed). > > Thank you very much for your help! > > -- > Best Regards, > > Jimmy > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From kohler at cs.ucla.edu Mon Mar 8 12:24:33 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Mon, 08 Mar 2010 09:24:33 -0800 Subject: [Click] Click userlevel performance issues In-Reply-To: References: <4B927D86.5030306@intec.UGent.be> Message-ID: <4B9532D1.2000404@cs.ucla.edu> I would actually EXPECT tun to be more expensive, but not because of Click: because the kernel path is more expensive. (You don't mention whether the CPU charged to Click is kernel or user.) I am a little surprised by this degree of difference. I would try to narrow down the source of the difference by using a different source element -- InfiniteSource + UDPIPEncap, or FromIPSummaryDump, or something else. More specific info about what type of time is being wasted, etc. would be useful too. E Cliff Frey wrote: > I'd be curious what the system and interrupt times were on the various > machines. Perhaps there is more linux kernel overhead in the different > configurations. These numbers likely show up in top, or you can read raw > values from /proc/stat and see how they are changing. > > Cliff > > On Sat, Mar 6, 2010 at 8:06 AM, Peter Dedecker < > Peter.Dedecker at intec.ugent.be> wrote: > >> Hi all, >> >> I've done some performance tests with the VPAN software (which you might >> remember from the nice talk of Jeroen at the Click Symposium ;-)) on >> real performant hardware. I've disabled all encryption stuff to strip it >> all down to almost plain Click with some routing and simple >> encapsulation operations. >> >> I have 3 types of nodes: >> - a sender takes plain IP packets from its tun0 interface, encapsulates >> them and sents them out on its eth0 interface. >> - a forwarding node takes packets from its eth0, decapsulates, looks up >> the next hop (like the sender also does), encapsulates the packet again, >> and sends it out on eth1. >> - the reciever is the final destination of the packets, accepts them on >> its eth0 interface, decapsulates them and delivers them at its tun0 >> interface. >> >> All quite simple and almost all the same operations though. With >> increasing traffic, CPU usage of the Click process increases also, which >> seems normal. However, a main observation on all traffic ranges, is that >> the sender node consequently has the highest CPU load. Forwarding nodes >> have a CPU load of only +/-2/3 of the sender nodes, while the >> destination clearly has the easiest work to do with a CPU load of only >> +/-1/3 compared to the forwarding node or even less than 20% of the >> sender's CPU load. For some figures: the click process has a CPU usage >> (measured with top) of 24% at a sending node, while 14% and 3% at >> forwarders and recievers. All nodes have a Dual-Core AMD Opteron(tm) >> Processor 2212 running at 2010.151 MHz with a cache size of 1024 KB, >> with 2 CPU's each node. Of course, as Click is single threaded, only one >> core will be used. >> >> Is accepting packets from a tun0 interface so hard, compared with >> accepting packets from the eth0 interface? I don't think expensive >> headroom push for packet encapsulation can be the problem, as in this >> configuration only an ethernet header is added with its 14 bytes being >> lower than the default headroom of 28 bytes. Does anyone have an >> explanation for this? Thanks a lot! >> >> Kind regards, >> >> -- >> ir. Peter Dedecker >> Department of Information Technology >> Broadband Communication Networks (IBCN) >> Ghent University - IBBT >> Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium >> M: +32 486152320 >> T: +32 9 33 14946 ; T Secr: +32 9 33 14900 >> F: +32 9 33 14899 >> E: Peter.Dedecker at intec.UGent.be >> W : www.ibcn.intec.UGent.be >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From cliff at meraki.com Mon Mar 8 12:27:23 2010 From: cliff at meraki.com (Cliff Frey) Date: Mon, 8 Mar 2010 09:27:23 -0800 Subject: [Click] Record queue length overtime In-Reply-To: <2fe59bbc1003080838q53bd0c10p48bc05ce6c53e985@mail.gmail.com> References: <2fe59bbc1003072212j1947f1c5k2a28de4c86f1f986@mail.gmail.com> <2fe59bbc1003080838q53bd0c10p48bc05ce6c53e985@mail.gmail.com> Message-ID: Jimmy, Please always CC the click mailing list with your questions. I don't have any experience with those elements. Cliff On Mon, Mar 8, 2010 at 8:38 AM, Jimmy wrote: > Hi Cliff, > > Thanks very much for your instruction. I will check those elements and > see how they work. > > Btw, can you give me any advices on the exponential or poisson arrival > rate source? > > Jimmy > > On Mon, Mar 8, 2010 at 2:06 AM, Cliff Frey wrote: > > You can easily do that with a Script element... you could use either > 'read' > > or 'print' to display the data. > > If you wanted even more control, you could add a ControlSocket to your > > config and then write a script that would access the ControlSocket. > > Here is an example script element that should do what you want. > > Cliff > > > > Script(wait 1.0, read ct.length, loop); > > > > On Sun, Mar 7, 2010 at 10:12 PM, Jimmy wrote: > >> > >> Hello all, > >> > >> Using handlers, I know how to record the total queue length. > >> > >> -> ct :: Queue(50) > >> > >> -> TimedUnqueue(1) > >> > >> -> ccl :: Counter > >> > >> -> Print(TIMESTAMP true) > >> > >> -> Discard; > >> > >> DriverManager(pause, > >> print >>log cnt.count, > >> print >>log ct.length, > >> print >>log ccl.count) > >> > >> Here, -> Print(TIMESTAMP true) command can print received packets > >> overtime on screen, I mean it can show when each packet is received. > >> > >> But in DriverManager, I can only record the number of packets I > >> received when I stop this program. > >> > >> How can I record the overtime information of received packets or the > >> number of packets in the queue? I mean is it possible to record the > >> number of packets in the queue for every second? > >> > >> Another question is that are there any source elements relating to an > >> exponential or poisson packets source (thus the arrival rate of > >> packets is exponential or poisson distributed). > >> > >> Thank you very much for your help! > >> > >> -- > >> Best Regards, > >> > >> Jimmy > >> _______________________________________________ > >> click mailing list > >> click at amsterdam.lcs.mit.edu > >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > > > > > -- > Best Regards, > > Jimmy > From kohler at cs.ucla.edu Mon Mar 8 12:27:25 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Mon, 08 Mar 2010 09:27:25 -0800 Subject: [Click] Radiotap headers patch In-Reply-To: References: Message-ID: <4B95337D.3010602@cs.ucla.edu> Hi Amita, The procedure for submitting a patch is simple. Just take a git checkout of click, make your change, test it (if possible add a test to the test/ tree -- may not be possible here), and then send the patch to the list. To create a patch, I would recommend: (1) Commit your change. git add ........ git commit [enter a good commit message] (2) Make sure your Click checkout is up to date. git fetch git rebase origin (3) Prepare the patch git format-patch origin [produces a file named something like 0001-blah-blah-blah.patch) (4) Send a message to the list, with the patch as as an attachment. Eddie Amita Ekbote wrote: > Hey, > > I had been trying to get the autorate fallback working on click since a > while. It is working now, but I noticed that the radiotap header format has > changed in madwifi and has not been updated in the click code. I have the > code for radiotapdecap and would like to submit a patch , how do i go about > doing it? Also for all of the rate algorithms some extra values were set > which dont exist in the header leading to a bunch of garbage values causing > them all to fail. By all I mean the Autoratefallback, MadwifiRate and > ProbeTXRate. I have edited those to make them work too. Please let me know > how I can submit those changes. I would also like to know if anyone has used > them recently without making any changes. > > Thanks! > From jensdewit at gmail.com Mon Mar 8 18:31:06 2010 From: jensdewit at gmail.com (Jens De Wit) Date: Tue, 9 Mar 2010 00:31:06 +0100 Subject: [Click] DS: New element: icmpipencap, a general icmppingencap In-Reply-To: <4B8FF76C.6070005@cs.ucla.edu> References: <217154321002250902j537c55d9ha97b18e58e334efb@mail.gmail.com> <0822F3307FE52B4FAD7962B06DF51F8B032446E6@xmail01.ad.ua.ac.be> <217154321003011025u6057cec4p45ec3b0b3f92c001@mail.gmail.com> <4B8FF76C.6070005@cs.ucla.edu> Message-ID: <217154321003081531w163b162cm2b6fa7d9a804c91d@mail.gmail.com> Hi Eddie, I'm sending you an update of the ICMPIPEncap element that addresses your previous remarks. That click_icmp_hl() function was quite useful indeed. The other 2 issues were solved simultaneously by simply initializing the complete icmp header to 0 at the start. I've also updated the comments in the header file a bit. There's one thing I'm a bit curious about though: I've noticed the byte orderings of the sequence number and the ICMP identifier are in network order (just like in the ICMPPingEncap element on which Nico and me originally based this new element). I was wondering if there is any specific reason why this was done? All other fields seem to follow host ordering, including for instance the IP identifier. Best Regards, Jens 2010/3/4 Eddie Kohler > Jens, > > Excellent! Thank you so much for this. The new element is added. > > I do have some remaining comments, so if you're willing you might consider > sending another patch: > > * You may be able to simplify the "switch (_icmp_type)" using the > "click_icmp_hl()" function, which returns the ICMP header length appropriate > for a given ICMP type. This function is defined in . You > would still need to set "need_seq_number" based on _icmp_type. > > * The TSTAMP and TSTAMPREPLY ICMP types contain more data than the other > types. This data area is currently left uninitialized, so it contains > garbage. This is OK, but it might be less surprising to initialize this > area to zero. Something like this would do it: > > memset(static_cast(icmp) + sizeof(click_icmp), 0, > click_icmp_hl(_type) - sizeof(click_icmp)); > > * The "identifier" field is only relevant i f"need_seq_number" is true. If > "need_seq_number" is false, I would instead initialize the identifier and > sequence number to 0 (this is like initializing the "padding" field to 0). > > Thanks again. > Eddie > > > > Jens De Wit wrote: > >> Dear list, >> >> I send this mail in reply to Eddie's remarks on the new ICMPIPEncap >> element. >> Attached you will find the improved version of the element, as well as a >> testie file containing a basic unit test for the new element. >> >> Kind regards, >> Jens De Wit >> >> >> >> 2010/2/28 De Wit Jens >> >> ------------------------------------------- >>> *Van:* Eddie Kohler[SMTP:KOHLER at CS.UCLA.EDU < >>> SMTP%3AKOHLER at CS.UCLA.EDU >] >>> *Verzonden:* zondag 28 februari 2010 21:52:07 >>> *Aan:* Braem Bart >>> *CC:* click at amsterdam.lcs.mit.edu; De Wit Jens >>> *Onderwerp:* Re: [Click] New element: icmpipencap, a general >>> icmppingencap >>> >>> *Automatisch doorgezonden volgens een regel* >>> >>> Hi guys! >>> >>> Thanks very much for this element. I'd definitely like to add it to the >>> repository. However, I have some concerns that if you could address, it >>> would >>> be great. >>> >>> 1. Element documentation in the header file is missing. Even just one >>> paragraph plus the use case (e.g. "=c ICMPEncap(SRC, DST, TYPE [, >>> CODE])".) >>> >>> 2. The _icmp_type and _icmp_code members should be read using IPNameInfo, >>> so >>> users can give symbolic names. E.g.: >>> >>> int32_t icmp_type; >>> ... "TYPE", cpkP+cpkM, cpNamedInteger, NameInfo::T_ICMP_TYPE, >>> &icmp_type, >>> ... >>> >>> The CODE requires special handling since you need to know the TYPE before >>> parsing the CODE. Take a look at ICMPError for an example. >>> >>> 3. This is the big one: The current element adds a clcik_icmp_echo >>> header. >>> But this header is only correct for TYPE echo or echo-reply. Other ICMP >>> types >>> add a different header, often with a different length. For example >>> tstamp >>> and >>> tcstamp-reply have longer ehaders. See include/clicknet/icmp.h for more >>> examples. Either the element should be changed to add the appropriate >>> header >>> for _type, or the configure() method should return an error on an >>> inappropriate TYPE. >>> >>> Thanks very much, >>> Eddie >>> >>> >>> Braem Bart wrote: >>> >>>> Dear list, >>>> >>>> Attached you will find an element our students (Jens De Wit and Nico Van >>>> >>> Looy) produced while working on their FireSim project, the Firewall >>> Simulation in Click as presented on SyClick. >>> >>> The element allows transmitting ICMP packets with all types of codes and >>>> >>> types, which makes this element more general than ICMPPingEncap. It is a >>> bit >>> the ICMP alternative to UDPIPEncap. >>> >>> The element code is largely based on ICMPPingEncap so Jens and Nico >>>> >>> suggested just patching ICMPPingEncap with the new behaviour, although of >>> course the name then does not cover the contents of the element. >>> >>> Jens promised to write a unit test with the testie framework, so this >>>> can >>>> >>> be expected as well. >>> >>>> best regards, >>>> Bart >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: icmpipencap.cc Type: text/x-c++src Size: 3915 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100309/32685761/attachment-0001.cc -------------- next part -------------- A non-text attachment was scrubbed... Name: icmpipencap.hh Type: text/x-c++hdr Size: 1796 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100309/32685761/attachment-0001.hh From kohler at cs.ucla.edu Tue Mar 9 12:38:36 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Tue, 09 Mar 2010 09:38:36 -0800 Subject: [Click] DS: New element: icmpipencap, a general icmppingencap In-Reply-To: <217154321003081531w163b162cm2b6fa7d9a804c91d@mail.gmail.com> References: <217154321002250902j537c55d9ha97b18e58e334efb@mail.gmail.com> <0822F3307FE52B4FAD7962B06DF51F8B032446E6@xmail01.ad.ua.ac.be> <217154321003011025u6057cec4p45ec3b0b3f92c001@mail.gmail.com> <4B8FF76C.6070005@cs.ucla.edu> <217154321003081531w163b162cm2b6fa7d9a804c91d@mail.gmail.com> Message-ID: <4B96879C.3070708@cs.ucla.edu> Hi Jens, Excellent! The patch is applied. Jens De Wit wrote: > There's one thing I'm a bit curious about though: I've noticed the byte > orderings of the sequence number and the ICMP identifier are in network > order (just like in the ICMPPingEncap element on which Nico and me > originally based this new element). I was wondering if there is any > specific reason why this was done? All other fields seem to follow host > ordering, including for instance the IP identifier. Well, some of the fields have no ordering. ICMP type and ICMP code are both one byte long -- no order applies. The ICMP identifier and ICMP ID fields are sent in network order by most BSD-derived stacks [i.e., htons() is applied], but in host order by Linux -- thus the #ifdef __linux__. Make sense? The IP ID is sent in network order in the current code, but this doesn't really matter; host order would be fine, since other hosts on the network are supposed to treat IP IDs like opaque tokens, not sequence numbers. (We only care about the ordering so that IPPrint/tcpdump will print the expected values.) Eddie > > Best Regards, > Jens > > > 2010/3/4 Eddie Kohler > > > Jens, > > Excellent! Thank you so much for this. The new element is added. > > I do have some remaining comments, so if you're willing you might > consider sending another patch: > > * You may be able to simplify the "switch (_icmp_type)" using the > "click_icmp_hl()" function, which returns the ICMP header length > appropriate for a given ICMP type. This function is defined in > . You would still need to set "need_seq_number" based > on _icmp_type. > > * The TSTAMP and TSTAMPREPLY ICMP types contain more data than the > other types. This data area is currently left uninitialized, so it > contains garbage. This is OK, but it might be less surprising to > initialize this area to zero. Something like this would do it: > > memset(static_cast(icmp) + sizeof(click_icmp), 0, > click_icmp_hl(_type) - sizeof(click_icmp)); > > * The "identifier" field is only relevant i f"need_seq_number" is > true. If "need_seq_number" is false, I would instead initialize the > identifier and sequence number to 0 (this is like initializing the > "padding" field to 0). > > Thanks again. > Eddie > > > > Jens De Wit wrote: > > Dear list, > > I send this mail in reply to Eddie's remarks on the new > ICMPIPEncap element. > Attached you will find the improved version of the element, as > well as a > testie file containing a basic unit test for the new element. > > Kind regards, > Jens De Wit > > > > 2010/2/28 De Wit Jens > > > ------------------------------------------- > *Van:* Eddie Kohler[SMTP:KOHLER at CS.UCLA.EDU > > >] > *Verzonden:* zondag 28 februari 2010 21:52:07 > *Aan:* Braem Bart > *CC:* click at amsterdam.lcs.mit.edu > ; De Wit Jens > *Onderwerp:* Re: [Click] New element: icmpipencap, a general > icmppingencap > > *Automatisch doorgezonden volgens een regel* > > Hi guys! > > Thanks very much for this element. I'd definitely like to > add it to the > repository. However, I have some concerns that if you could > address, it > would > be great. > > 1. Element documentation in the header file is missing. > Even just one > paragraph plus the use case (e.g. "=c ICMPEncap(SRC, DST, > TYPE [, CODE])".) > > 2. The _icmp_type and _icmp_code members should be read > using IPNameInfo, > so > users can give symbolic names. E.g.: > > int32_t icmp_type; > ... "TYPE", cpkP+cpkM, cpNamedInteger, > NameInfo::T_ICMP_TYPE, &icmp_type, > ... > > The CODE requires special handling since you need to know > the TYPE before > parsing the CODE. Take a look at ICMPError for an example. > > 3. This is the big one: The current element adds a > clcik_icmp_echo header. > But this header is only correct for TYPE echo or echo-reply. > Other ICMP > types > add a different header, often with a different length. For > example tstamp > and > tcstamp-reply have longer ehaders. See > include/clicknet/icmp.h for more > examples. Either the element should be changed to add the > appropriate > header > for _type, or the configure() method should return an error > on an > inappropriate TYPE. > > Thanks very much, > Eddie > > > Braem Bart wrote: > > Dear list, > > Attached you will find an element our students (Jens De > Wit and Nico Van > > Looy) produced while working on their FireSim project, the > Firewall > Simulation in Click as presented on SyClick. > > The element allows transmitting ICMP packets with all > types of codes and > > types, which makes this element more general than > ICMPPingEncap. It is a bit > the ICMP alternative to UDPIPEncap. > > The element code is largely based on ICMPPingEncap so > Jens and Nico > > suggested just patching ICMPPingEncap with the new > behaviour, although of > course the name then does not cover the contents of the element. > > Jens promised to write a unit test with the testie > framework, so this can > > be expected as well. > > best regards, > Bart > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > From kohler at cs.ucla.edu Tue Mar 9 16:51:59 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Tue, 09 Mar 2010 13:51:59 -0800 Subject: [Click] Kernel Panic In-Reply-To: References: Message-ID: <4B96C2FF.6030500@cs.ucla.edu> Hi Ritun, Thanks for this long-ago bug report. A number of fixes have been committed to the tree that may have some impact on the bug. If you are still working on this problem, give the newer device drivers & Click core a try. E Ritun Patney wrote: > Hey, > I have been doing some experiments using click on emulab and have been > running into this problem where the kernel panics and crashes. Initially I > thought its one of my modules, but now I have noticed it just happens > without my modules also. > > The setup I have is machines with 1G ethernet ports (e1000 intel) running > click patched kernel 2.6.24.7. The version of click is 1.7.0rc1. There > are just 2 nodes involved in the experiment, one transmitter and the > other is receiving that traffic. Both are running click modules to send > and receive. The source has the following configuration: > > RatedSource(DATA ...., RATE 500000)->ToDevice(ethx) > > The destination has the following configuration: > > FromDevice(ethx)->Counter->Discard > > The kernel seems to panic at data rates where either the FromDevice > module or the interface starts to drop packets. Also, the > error seems to be to memory related. I have attached 2 > error reports from 2 different runs printed on the console. In a separate > run (call it the third run), I got a huge call trace but it started > with the error "BUG: unable to handle kernel paging request at virtual > address xxxxxx". I would appreciate any help. > Thanks > -Ritun > > ---------------------------------------------------------------------------- > First Run > ---------------------------------------------------------------------------- > click: starting router thread pid 4227 (f6bf1e40) > ------------[ cut here ]------------ > kernel BUG at mm/slab.c:3007! > invalid opcode: 0000 [#1] SMP > Modules linked in: click proclikefs i2c_dev i2c_core tulip e100 3c59x > dm_mirror nvram e1000 button > > Pid: 6, comm: ksoftirqd/1 Not tainted (2.6.24.7-1.2944.fc6.emulab-1 #1) > EIP: 0060:[] EFLAGS: 00010046 CPU: 1 > EIP is at cache_alloc_refill+0xf3/0x49d > EAX: 00000008 EBX: f78515c0 ECX: 00000016 EDX: f7800880 > ESI: f78b0c80 EDI: 00000005 EBP: f78022c0 ESP: f7871e88 > DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 > Process ksoftirqd/1 (pid: 6, ti=f7870000 task=f784b0c0 task.ti=f7870000) > Stack: f7808400 00000008 00000020 f7800880 f78515c0 00000000 f696b680 > 00000246 > f8cfe4dd f8e92fe4 ffffffff 00000000 f696b580 f7800880 00000246 > 00000020 > c01659e2 f696b580 00000080 f696b580 f787cdc0 c0318cca 00000000 > 00000020 > Call Trace: > [] packet_notifier_hook+0x5d/0x80 [click] > [] __kmalloc+0x6f/0xa5 > [] __alloc_skb+0x53/0xff > [] __netdev_alloc_skb+0x1c/0x35 > [] e1000_clean_rx_irq+0x1b1/0x44c [e1000] > [] e1000_clean_rx_irq+0x0/0x44c [e1000] > [] e1000_clean+0x59/0x1e6 [e1000] > [] net_rx_action+0x8d/0x174 > [] run_timer_softirq+0x2f/0x156 > [] __do_softirq+0x5d/0xc1 > [] ksoftirqd+0x0/0xa4 > [] do_softirq+0x32/0x36 > [] ksoftirqd+0x42/0xa4 > [] kthread+0x38/0x60 > [] kthread+0x0/0x60 > [] kernel_thread_helper+0x7/0x10 > ======================= > Code: 8b 75 00 39 ee 75 15 8b 75 10 8d 45 10 c7 45 34 01 00 00 00 39 c6 0f > 84 a5 00 00 00 8b 54 24 0c 8b 82 98 00 00 00 39 46 10 72 37 <0f> 0b eb fe > 8b > 44 24 0c 8b 5c 24 10 8b 90 8c 00 00 00 8b 44 24 > EIP: [] cache_alloc_refill+0xf3/0x49d SS:ESP 0068:f7871e88 > Kernel panic - not syncing: Fatal exception in interrupt > > > > ---------------------------------------------------------------------------- > Second Run > ---------------------------------------------------------------------------- > > Fedora Core release 6 (Zod) > Kernel 2.6.24.7-1.2944.fc6.emulab-1 on an i686 > > node0.eval.forest.emulab.net login: click: starting router thread pid 3889 > (f576dc40) > ------------[ cut here ]------------ > kernel BUG at mm/slab.c:602! > invalid opcode: 0000 [#1] SMP > Modules linked in: click proclikefs i2c_dev i2c_core tulip e100 3c59x > dm_mirror nvram e1000 button > > Pid: 3889, comm: kclick Not tainted (2.6.24.7-1.2944.fc6.emulab-1 #1) > EIP: 0060:[] EFLAGS: 00010046 CPU: 0 > EIP is at free_block+0x4d/0x104 > EAX: 40000000 EBX: 0000001c ECX: f5621800 EDX: c16ac420 > ESI: f5405dc0 EDI: f78022c0 EBP: f7800880 ESP: f73b7ee8 > DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 > Process kclick (pid: 3889, ti=f73b6000 task=f5592330 task.ti=f73b6000) > Stack: 00000007 00000000 0000001b 00000018 f78054f4 f78022c0 000000d8 > f7800880 > 0000001b c0164e7d 00000000 f7805480 f7805480 00000286 f540b800 > 0047b8a4 > c0164f0b f56b4a80 f702d180 00000001 c0318570 f8e936e0 f8d31991 > 00000000 > Call Trace: > [] cache_flusharray+0x71/0x98 > [] kfree+0x67/0x76 > [] __kfree_skb+0x8/0xd > [] _ZN15RecycledSkbPool7recycleEP7sk_buff+0x31/0xf0 [click] > [] _ZN7Element4pushEiP6Packet+0x26/0x40 [click] > [] _ZN10FromDevice8run_taskEP4Task+0x78/0xf0 [click] > [] _ZN12RouterThread6driverEv+0x235/0x470 [click] > [] sched_move_task+0xc1/0xc7 > [] switch_uid+0x5c/0x69 > [] click_lalloc+0x34/0x60 [click] > [] _Z11click_schedPv+0xc9/0x1b0 [click] > [] _Z11click_schedPv+0x0/0x1b0 [click] > [] kernel_thread_helper+0x7/0x10 > ======================= > Code: 8b 08 8d 91 00 00 00 40 c1 ea 0c c1 e2 05 03 15 80 f6 51 c0 8b 02 25 > 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c > 8b 02 84 c0 78 04 <0f> 0b eb fe 8b 72 1c 8b 54 24 28 8b 46 04 8b bc 95 c8 > 00 00 00 > EIP: [] free_block+0x4d/0x104 SS:ESP 0068:f73b7ee8 > ---[ end trace e44c05cd35086d7b ]--- > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Tue Mar 9 20:50:40 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Tue, 09 Mar 2010 17:50:40 -0800 Subject: [Click] Generate local Click element documentation? In-Reply-To: References: <15418196.8383.1256053673485.JavaMail.seven@ap0.p4.uk.7sys.net> <4ADE056E.2070405@cs.ucla.edu> Message-ID: <4B96FAF0.8080106@cs.ucla.edu> Hi Bart, Just found this!! I've attached the $DOCDIR/template and $EXDIR/template we use. However, in the current Click site, we do this differently -- we create Dokuwiki-formatted files rather than HTML. Eddie Bart Braem wrote: > Thanks for the fast answer! The script requires a template in both > $DOCDIR/template and $EXDIR/template for use by click-pretty, if I > understand things correctly. > What should I provide? No template or just a directory do not seem to be > good ideas. > > regards, > Bart > > On 20 Oct 2009, at 20:46, Eddie Kohler wrote: > >> All of Click's online documentation is generated by a script that is >> checked in to the repository, but not part of the tarball. The script >> is doc/mkwebdoc.pl. It depends on doc/man2html as well. >> >> The online element documentation is stored in a dokuwiki (easy to find >> online); at this point doc/mkwebdoc.pl generates dokuwiki-formatted >> files. >> >> E >> >> >> adam.greenhalgh at googlemail.com wrote: >>> I wonder is this an offer to run a click mirror site ? :-) >>> Adam >>> -original message- >>> Subject: [Click] Generate local Click element documentation? >>> From: "Bart Braem" >>> Date: 20/10/2009 4:35 pm >>> Hi, >>> What would be the best way to generate local element documentation? >>> Our students have to use Click-1.6.0, so we want to generate a copy >>> of the element documentation of version 1.6.0 and host it on a local >>> web server. We know the element documentation is generated, but how? >>> regards, >>> Bart >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100309/d63f04a5/attachment-0002.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100309/d63f04a5/attachment-0003.htm From kohler at cs.ucla.edu Wed Mar 10 12:46:14 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 10 Mar 2010 09:46:14 -0800 Subject: [Click] [PATCH]: radiotapdecap.cc: pull the correct amount of bytes on big-endian In-Reply-To: <4B15C487.9030106@eecs.harvard.edu> References: <6c6bb6f90911161646x3045b984lf8a3214393ae7a7@mail.gmail.com> <4B15BED2.2090901@cs.ucla.edu> <4B15C487.9030106@eecs.harvard.edu> Message-ID: <4B97DAE6.206@cs.ucla.edu> Hi Ian, I've finally committed this change. I renamed the PUSH_ETH argument to ETHER for consistency with other elements. Thanks very much! Eddie Ian Rose wrote: > Hi Eddie - > > If you are in the mood to patch radiotap elements, I submitted some > patches a few months ago that I don't think were ever applied (and if > the patch was rejected, I didn't hear that). > > This is the original email (verbose explanation at the top, patches at > the end): > https://pdos.csail.mit.edu/pipermail/click/2009-August/008190.html > > - Ian > > > Eddie Kohler wrote: >> Alastair, >> >> Thanks,a pplied! >> >> E >> >> >> Alastair McKinley wrote: >>> Hi Eddie, >>> >>> I sent a patch some time ago regarding big-endian problems in >>> radiotapdecap.cc. >>> Somehow I missed sending one of the changes in my local tree and just >>> noticed today that it wasn't applied to your tree. >>> >>> Attached is another one liner. >>> >>> Alastair >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Mar 10 14:03:32 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 10 Mar 2010 11:03:32 -0800 Subject: [Click] HEADS UP: 1.8.0 In-Reply-To: <9367D9DE-852E-469D-8A35-65B63E65CB90@gmail.com> References: <4B7F29D1.6000207@cs.ucla.edu> <9367D9DE-852E-469D-8A35-65B63E65CB90@gmail.com> Message-ID: <4B97ED04.7080308@cs.ucla.edu> Hi Johan, Thanks for the patch. I have included a version of it in the current sources. It is somewhat different from the version you provided because I guess FromHost itself may have changed a bit (the patch did not apply cleanly). Let me know if you have any issues. Eddie Johan Bergs wrote: > Hi, Eddie, > > Could you also consider the attached patch for userlevel fromhost? This enables setting IPv6 addresses on tun/tap devices, which is useful when using IPv6 in userlevel click. We have used this patch without problems for some time now... > > > > Regards, > > Johan. > > > > > ------------------------------------------------------------------------ > > > > On 20 Feb 2010, at 01:16, Eddie Kohler wrote: > >> Hi all, >> >> It has been more than a year since the release of Click 1.7.0rc1. Therefore, >> I am going to release Click 1.8.0 next Friday. :) >> >> I will be going through emails and responding to requests. If you have any >> bugs with the current version of the code please let us know. The 1.8.0 >> version will likely *not* include support for FromHost in linux-patchless >> installs. Also, I'm not sure linux-patchless will work with 2.6.32 kernels, >> although it may. It is better to get the release out sooner. >> >> REQUEST: There are several versions of e1000 and other driver code floating >> around on the mailing list. Please, if you are using such a driver and it >> works, send mail to the list. I would like to include the latest working >> version of the e1000 driver with the release, although I'm unlikely to be able >> to test it myself. >> >> Thanks, >> Eddie >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From rchertov at cs.ucsb.edu Wed Mar 10 17:49:47 2010 From: rchertov at cs.ucsb.edu (rchertov at cs.ucsb.edu) Date: Wed, 10 Mar 2010 14:49:47 -0800 Subject: [Click] Kernel level click In-Reply-To: <4B97ED04.7080308@cs.ucla.edu> References: <4B7F29D1.6000207@cs.ucla.edu> <9367D9DE-852E-469D-8A35-65B63E65CB90@gmail.com> <4B97ED04.7080308@cs.ucla.edu> Message-ID: I know that right now Click supports the "patchless" kernel option. However, if I want to use e1000e polling driver, I should create a Linux kernel using the old process (patch, compile, and install), right? Thanks Roman From ianrose at eecs.harvard.edu Wed Mar 10 19:54:46 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Wed, 10 Mar 2010 19:54:46 -0500 Subject: [Click] %{element} syntax Message-ID: <4B983F56.1020508@eecs.harvard.edu> Hi all - In various places (such as simplequeue.cc), there are lines like this: > click_chatter("%{element}: overflow", this); I'm guessing that this is supposed to print some kind of description/representation of the element, followed by ": overflow", but on my machine (userspace click, FreeBSD 7.2-STABLE) it just prints "{element}: overflow". Does this "work" (as I am assuming its supposed to) for other people or does it print oddly for everyone? - Ian From kohler at cs.ucla.edu Wed Mar 10 20:39:06 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 10 Mar 2010 17:39:06 -0800 Subject: [Click] %{element} syntax In-Reply-To: <4B983F56.1020508@eecs.harvard.edu> References: <4B983F56.1020508@eecs.harvard.edu> Message-ID: <4B9849BA.1010400@cs.ucla.edu> Ian, This works correctly on Mac OS X at least. I'm surprised it fails for you. Are you using a modified driver at all? Eddie On 3/10/10 4:54 PM, Ian Rose wrote: > Hi all - > > In various places (such as simplequeue.cc), there are lines like this: > >> click_chatter("%{element}: overflow", this); > > I'm guessing that this is supposed to print some kind of > description/representation of the element, followed by ": overflow", but > on my machine (userspace click, FreeBSD 7.2-STABLE) it just prints > "{element}: overflow". > > Does this "work" (as I am assuming its supposed to) for other people or > does it print oddly for everyone? > > - Ian > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Mar 10 20:41:23 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 10 Mar 2010 17:41:23 -0800 Subject: [Click] %{element} syntax In-Reply-To: <4B983F56.1020508@eecs.harvard.edu> References: <4B983F56.1020508@eecs.harvard.edu> Message-ID: <4B984A43.3040505@cs.ucla.edu> The code that handles this case starts at error.cc:690, if you're interested in single stepping. On 3/10/10 4:54 PM, Ian Rose wrote: > Hi all - > > In various places (such as simplequeue.cc), there are lines like this: > >> click_chatter("%{element}: overflow", this); > > I'm guessing that this is supposed to print some kind of > description/representation of the element, followed by ": overflow", but > on my machine (userspace click, FreeBSD 7.2-STABLE) it just prints > "{element}: overflow". > > Does this "work" (as I am assuming its supposed to) for other people or > does it print oddly for everyone? > > - Ian > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Wed Mar 10 20:47:01 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Wed, 10 Mar 2010 20:47:01 -0500 Subject: [Click] %{element} syntax In-Reply-To: <4B984A43.3040505@cs.ucla.edu> References: <4B983F56.1020508@eecs.harvard.edu> <4B984A43.3040505@cs.ucla.edu> Message-ID: <4B984B95.5060100@eecs.harvard.edu> AH HA! My mistake - I totally forgot that (normally) click_chatter calls through an ErrorHandler rather than directly to vsnprintf or the like. I have changed my glue.cc to NOT use ErrorHandler::default_handler(), which is why this special syntax is not working for me. Sorry about the false alarm there! - Ian Eddie Kohler wrote: > The code that handles this case starts at error.cc:690, if you're > interested in single stepping. > > > On 3/10/10 4:54 PM, Ian Rose wrote: >> Hi all - >> >> In various places (such as simplequeue.cc), there are lines like this: >> >>> click_chatter("%{element}: overflow", this); >> >> I'm guessing that this is supposed to print some kind of >> description/representation of the element, followed by ": overflow", but >> on my machine (userspace click, FreeBSD 7.2-STABLE) it just prints >> "{element}: overflow". >> >> Does this "work" (as I am assuming its supposed to) for other people or >> does it print oddly for everyone? >> >> - Ian >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Mar 10 20:46:30 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 10 Mar 2010 17:46:30 -0800 Subject: [Click] Kernel level click In-Reply-To: References: <4B7F29D1.6000207@cs.ucla.edu> <9367D9DE-852E-469D-8A35-65B63E65CB90@gmail.com> <4B97ED04.7080308@cs.ucla.edu> Message-ID: <4B984B76.80902@cs.ucla.edu> Yes, that's right. E On 3/10/10 2:49 PM, rchertov at cs.ucsb.edu wrote: > I know that right now Click supports the "patchless" kernel option. > However, if I want to use e1000e polling driver, I should create a Linux > kernel using the old process (patch, compile, and install), right? > > Thanks > > Roman > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Mar 10 20:51:55 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 10 Mar 2010 17:51:55 -0800 Subject: [Click] %{element} syntax In-Reply-To: <4B984B95.5060100@eecs.harvard.edu> References: <4B983F56.1020508@eecs.harvard.edu> <4B984A43.3040505@cs.ucla.edu> <4B984B95.5060100@eecs.harvard.edu> Message-ID: <4B984CBB.9020609@cs.ucla.edu> Ah, OK. Whatever you're doing, I would definitely do it by subclassing ErrorHandler. Elements definitely expect the %{..} syntax to work and you will get crashes if it is ignored. E On 3/10/10 5:47 PM, Ian Rose wrote: > AH HA! > > My mistake - I totally forgot that (normally) click_chatter calls > through an ErrorHandler rather than directly to vsnprintf or the like. I > have changed my glue.cc to NOT use ErrorHandler::default_handler(), > which is why this special syntax is not working for me. > > Sorry about the false alarm there! > > - Ian > > > Eddie Kohler wrote: >> The code that handles this case starts at error.cc:690, if you're >> interested in single stepping. >> >> >> On 3/10/10 4:54 PM, Ian Rose wrote: >>> Hi all - >>> >>> In various places (such as simplequeue.cc), there are lines like this: >>> >>>> click_chatter("%{element}: overflow", this); >>> >>> I'm guessing that this is supposed to print some kind of >>> description/representation of the element, followed by ": overflow", but >>> on my machine (userspace click, FreeBSD 7.2-STABLE) it just prints >>> "{element}: overflow". >>> >>> Does this "work" (as I am assuming its supposed to) for other people or >>> does it print oddly for everyone? >>> >>> - Ian >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Wed Mar 10 21:03:22 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Wed, 10 Mar 2010 21:03:22 -0500 Subject: [Click] %{element} syntax In-Reply-To: <4B984CBB.9020609@cs.ucla.edu> References: <4B983F56.1020508@eecs.harvard.edu> <4B984A43.3040505@cs.ucla.edu> <4B984B95.5060100@eecs.harvard.edu> <4B984CBB.9020609@cs.ucla.edu> Message-ID: <4B984F6A.5060603@eecs.harvard.edu> Hmm really? That's a bit worrisome. Is it vsnprintf that you think may crash or code that's actually in some elements themselves? I note that in line 112 of glue.cc, you fall back on just a simple vsnprintf if ErrorHandler::default_handler() returns NULL: > 112 if (ErrorHandler *errh = ErrorHandler::default_handler()) { > 113 errh->xmessage(ErrorHandler::e_info, fmt, val); > 114 } else { > [...] So is this behavior also dangerous? Now admittedly, I'm not sure why default_handler would ever be NULL, so maybe this is just a "this should never happen but if it does let's do our best to print something even if its unsafe" type thing? All I am actually trying to do is make click_chatter go to stdout while leaving all other errors going to stderr. I guess I could create a new FileErrorHandler using stdout instead of stderr and then change line 112 above to be something like: if (ErrorHandler *errh = ) { thanks, Ian Eddie Kohler wrote: > Ah, OK. > > Whatever you're doing, I would definitely do it by subclassing > ErrorHandler. Elements definitely expect the %{..} syntax to work and > you will get crashes if it is ignored. > > E > > > On 3/10/10 5:47 PM, Ian Rose wrote: >> AH HA! >> >> My mistake - I totally forgot that (normally) click_chatter calls >> through an ErrorHandler rather than directly to vsnprintf or the like. I >> have changed my glue.cc to NOT use ErrorHandler::default_handler(), >> which is why this special syntax is not working for me. >> >> Sorry about the false alarm there! >> >> - Ian >> >> >> Eddie Kohler wrote: >>> The code that handles this case starts at error.cc:690, if you're >>> interested in single stepping. >>> >>> >>> On 3/10/10 4:54 PM, Ian Rose wrote: >>>> Hi all - >>>> >>>> In various places (such as simplequeue.cc), there are lines like this: >>>> >>>>> click_chatter("%{element}: overflow", this); >>>> >>>> I'm guessing that this is supposed to print some kind of >>>> description/representation of the element, followed by ": overflow", >>>> but >>>> on my machine (userspace click, FreeBSD 7.2-STABLE) it just prints >>>> "{element}: overflow". >>>> >>>> Does this "work" (as I am assuming its supposed to) for other people or >>>> does it print oddly for everyone? >>>> >>>> - Ian >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Mar 10 21:39:03 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 10 Mar 2010 18:39:03 -0800 Subject: [Click] %{element} syntax In-Reply-To: <4B984F6A.5060603@eecs.harvard.edu> References: <4B983F56.1020508@eecs.harvard.edu> <4B984A43.3040505@cs.ucla.edu> <4B984B95.5060100@eecs.harvard.edu> <4B984CBB.9020609@cs.ucla.edu> <4B984F6A.5060603@eecs.harvard.edu> Message-ID: <4B9857C7.10002@cs.ucla.edu> On 3/10/10 6:03 PM, Ian Rose wrote: > Hmm really? That's a bit worrisome. Is it vsnprintf that you think may > crash or code that's actually in some elements themselves? I'd expect something like click_chatter("%{element} blah %d %s", this, 39, "foo"); to crash when the element pointer is misinterpreted as an integer and then "39" is cast to const char *. > I note that in line 112 of glue.cc, you fall back on just a simple > vsnprintf if ErrorHandler::default_handler() returns NULL: > >> 112 if (ErrorHandler *errh = ErrorHandler::default_handler()) { >> 113 errh->xmessage(ErrorHandler::e_info, fmt, val); >> 114 } else { > > [...] > > So is this behavior also dangerous? Now admittedly, I'm not sure why > default_handler would ever be NULL, so maybe this is just a "this should > never happen but if it does let's do our best to print something even if > its unsafe" type thing? It is exactly "this should never happen but if it does etc." > All I am actually trying to do is make click_chatter go to stdout while > leaving all other errors going to stderr. I guess I could create a new > FileErrorHandler using stdout instead of stderr and then change line 112 > above to be something like: > > if (ErrorHandler *errh = ) { And that's exactly what I would do. Eddie > thanks, > Ian > > > Eddie Kohler wrote: >> Ah, OK. >> >> Whatever you're doing, I would definitely do it by subclassing >> ErrorHandler. Elements definitely expect the %{..} syntax to work and >> you will get crashes if it is ignored. >> >> E >> >> >> On 3/10/10 5:47 PM, Ian Rose wrote: >>> AH HA! >>> >>> My mistake - I totally forgot that (normally) click_chatter calls >>> through an ErrorHandler rather than directly to vsnprintf or the like. I >>> have changed my glue.cc to NOT use ErrorHandler::default_handler(), >>> which is why this special syntax is not working for me. >>> >>> Sorry about the false alarm there! >>> >>> - Ian >>> >>> >>> Eddie Kohler wrote: >>>> The code that handles this case starts at error.cc:690, if you're >>>> interested in single stepping. >>>> >>>> >>>> On 3/10/10 4:54 PM, Ian Rose wrote: >>>>> Hi all - >>>>> >>>>> In various places (such as simplequeue.cc), there are lines like this: >>>>> >>>>>> click_chatter("%{element}: overflow", this); >>>>> >>>>> I'm guessing that this is supposed to print some kind of >>>>> description/representation of the element, followed by ": >>>>> overflow", but >>>>> on my machine (userspace click, FreeBSD 7.2-STABLE) it just prints >>>>> "{element}: overflow". >>>>> >>>>> Does this "work" (as I am assuming its supposed to) for other >>>>> people or >>>>> does it print oddly for everyone? >>>>> >>>>> - Ian >>>>> _______________________________________________ >>>>> click mailing list >>>>> click at amsterdam.lcs.mit.edu >>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From bart.braem at ua.ac.be Thu Mar 11 02:40:41 2010 From: bart.braem at ua.ac.be (Bart Braem) Date: Thu, 11 Mar 2010 08:40:41 +0100 Subject: [Click] Generate local Click element documentation? In-Reply-To: <4B96FAF0.8080106@cs.ucla.edu> References: <15418196.8383.1256053673485.JavaMail.seven@ap0.p4.uk.7sys.net> <4ADE056E.2070405@cs.ucla.edu> <4B96FAF0.8080106@cs.ucla.edu> Message-ID: <1B8A7DA7-5418-4FF2-8740-E1E774C2DAA4@ua.ac.be> Hi Eddie, Thanks for this, it helps us a lot to be able to present a stable release and stable documentation to our students! best regards, Bart On 10 Mar 2010, at 02:50, Eddie Kohler wrote: > Hi Bart, > > Just found this!! I've attached the $DOCDIR/template and $EXDIR/template we use. However, in the current Click site, we do this differently -- we create Dokuwiki-formatted files rather than HTML. > > Eddie > > > Bart Braem wrote: >> Thanks for the fast answer! The script requires a template in both $DOCDIR/template and $EXDIR/template for use by click-pretty, if I understand things correctly. >> What should I provide? No template or just a directory do not seem to be good ideas. >> regards, >> Bart >> On 20 Oct 2009, at 20:46, Eddie Kohler wrote: >>> All of Click's online documentation is generated by a script that is checked in to the repository, but not part of the tarball. The script is doc/mkwebdoc.pl. It depends on doc/man2html as well. >>> >>> The online element documentation is stored in a dokuwiki (easy to find online); at this point doc/mkwebdoc.pl generates dokuwiki-formatted files. >>> >>> E >>> >>> >>> adam.greenhalgh at googlemail.com wrote: >>>> I wonder is this an offer to run a click mirror site ? :-) >>>> Adam >>>> -original message- >>>> Subject: [Click] Generate local Click element documentation? >>>> From: "Bart Braem" >>>> Date: 20/10/2009 4:35 pm >>>> Hi, >>>> What would be the best way to generate local element documentation? >>>> Our students have to use Click-1.6.0, so we want to generate a copy of the element documentation of version 1.6.0 and host it on a local web server. We know the element documentation is generated, but how? >>>> regards, >>>> Bart >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> > > documentation > > &mantitle; > Click documentation > > > examples > > <~filename> > <~filename>: <~title> > > Configuration > > <~config> > > Element tables > > ' noinputentry='' outputentry='' nooutputentry='' inputconnection='<~name> [<~port>]' outputconnection='[<~port>] <~name>' noinputconnection='not connected' nooutputconnection='not connected' column='1/2' /-->' noinputentry='' outputentry='' nooutputentry='' inputconnection='<~name> [<~port>]' outputconnection='[<~port>] <~name>' noinputconnection='not connected' nooutputconnection='not connected' column='2/2' /--> > <~elements entry=' > <~name> :: <~type link><~config limit=10 parens> <~configlink> > <~inputs><~outputs> > ' configlink='(config)' inputentry=' > input <~port> (<~processing>) <- <~inputconnections sep=", "> > no inputs > output <~port> (<~processing>) -> <~outputconnections sep=", "> > no outputs > <~elements entry=' > <~name> :: <~type link><~config limit=10 parens> <~configlink> > <~inputs><~outputs> > ' configlink='(config)' inputentry=' > input <~port> (<~processing>) <- <~inputconnections sep=", "> > no inputs > output <~port> (<~processing>) -> <~outputconnections sep=", "> > no outputs > Index > > <~elements entry=' > <~name> :: <~type link> - <~configlink sep=", ">table > > ' typeentry=' > <~type link> (type) > see <~typerefs sep=", "> > > ' typeref='<~name>' configlink='config' column='1/2' /--> <~elements entry=' > <~name> :: <~type link> - <~configlink sep=", ">table > > ' typeentry=' > <~type link> (type) > see <~typerefs sep=", "> > > ' typeref='<~name>' configlink='config' column='2/2' /--> From fanyang.scu at gmail.com Thu Mar 11 13:10:30 2010 From: fanyang.scu at gmail.com (Jimmy) Date: Thu, 11 Mar 2010 13:10:30 -0500 Subject: [Click] Script element Message-ID: <2fe59bbc1003111010o40c02a9aid9a70f3a6de4cc0f@mail.gmail.com> Hi all, I read the script element description and know that it can be used to configure the network. I also used it to implement some simple comfiguration. My question is how and when is this element executed? Below is a simple example: 1 Source -> Queue -> UnQueue -> Print -> Discard; 2 Script( ... ); So line 1 just sets the network and line 2 implements the configuration. Is line 2 executed parallel with line 1? Or is it executed after line 1 is executed? Thanks. -- Best Regards, Jimmy From cliff at meraki.com Thu Mar 11 13:35:52 2010 From: cliff at meraki.com (Cliff Frey) Date: Thu, 11 Mar 2010 10:35:52 -0800 Subject: [Click] Script element In-Reply-To: <2fe59bbc1003111010o40c02a9aid9a70f3a6de4cc0f@mail.gmail.com> References: <2fe59bbc1003111010o40c02a9aid9a70f3a6de4cc0f@mail.gmail.com> Message-ID: First the click configuration is loaded. This means that all elements are created (including all Script elements) and configured and initialized. At this point, the click configuration is considered to be loaded. Then "tasks" are allowed to run. In your example, the Source element, UnQueue element, and Script element all have associated tasks. Those tasks will start running in round-robin fashion. You cannot really make any assumptions about the order of the first instruction in your script vs the first action of the Source element, but you can control it if the Source starts out disabled. For instance click foo.click foo.click: is :: InfiniteSource(LIMIT 1, ACTIVE false) -> Print -> Discard; Script( print "script is starting", writeq is.active true, print "script started the source", wait 1.0, print "script is stopping the router", stop);' On Thu, Mar 11, 2010 at 10:10 AM, Jimmy wrote: > Hi all, > > I read the script element description and know that it can be used to > configure the network. I also used it to implement some simple > comfiguration. > > My question is how and when is this element executed? Below is a > simple example: > > 1 Source -> Queue -> UnQueue -> Print -> Discard; > 2 Script( ... ); > > So line 1 just sets the network and line 2 implements the > configuration. Is line 2 executed parallel with line 1? Or is it > executed after line 1 is executed? > > Thanks. > -- > Best Regards, > > Jimmy > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From kohler at cs.ucla.edu Thu Mar 11 13:35:54 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 11 Mar 2010 10:35:54 -0800 Subject: [Click] Script element In-Reply-To: <2fe59bbc1003111010o40c02a9aid9a70f3a6de4cc0f@mail.gmail.com> References: <2fe59bbc1003111010o40c02a9aid9a70f3a6de4cc0f@mail.gmail.com> Message-ID: <4B99380A.2030503@cs.ucla.edu> I think there's a bit of confusion about "execution" here. In Click a configuration is set up all as a unit -- and then everything starts running. in your example the SCript will run after the configuration is initialized. I think this means "after line 1 is executed" but the terms are wrong. On 3/11/10 10:10 AM, Jimmy wrote: > Hi all, > > I read the script element description and know that it can be used to > configure the network. I also used it to implement some simple > comfiguration. > > My question is how and when is this element executed? Below is a > simple example: > > 1 Source -> Queue -> UnQueue -> Print -> Discard; > 2 Script( ... ); > > So line 1 just sets the network and line 2 implements the > configuration. Is line 2 executed parallel with line 1? Or is it > executed after line 1 is executed? > > Thanks. From ianrose at eecs.harvard.edu Thu Mar 11 13:40:26 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Thu, 11 Mar 2010 13:40:26 -0500 Subject: [Click] Script element In-Reply-To: References: <2fe59bbc1003111010o40c02a9aid9a70f3a6de4cc0f@mail.gmail.com> Message-ID: <4B99391A.5060605@eecs.harvard.edu> Jimmy - I'm not sure if you care, but if you want your Script element to run at other times (e.g. when a packet is received, or when a handler is called), take a look at the optional TYPE parameter: http://read.cs.ucla.edu/click/elements/script#script-types For what its worth, Script(TYPE PACKET, ...) is a nice debugging tool. - Ian Cliff Frey wrote: > First the click configuration is loaded. This means that all elements are > created (including all Script elements) and configured and initialized. At > this point, the click configuration is considered to be loaded. Then > "tasks" are allowed to run. In your example, the Source element, UnQueue > element, and Script element all have associated tasks. Those tasks will > start running in round-robin fashion. You cannot really make any > assumptions about the order of the first instruction in your script vs the > first action of the Source element, but you can control it if the Source > starts out disabled. > > For instance > > click foo.click > > foo.click: > > is :: InfiniteSource(LIMIT 1, ACTIVE false) -> Print -> Discard; > Script( > print "script is starting", > writeq is.active true, > print "script started the source", > wait 1.0, > print "script is stopping the router", > stop);' > > > On Thu, Mar 11, 2010 at 10:10 AM, Jimmy wrote: > >> Hi all, >> >> I read the script element description and know that it can be used to >> configure the network. I also used it to implement some simple >> comfiguration. >> >> My question is how and when is this element executed? Below is a >> simple example: >> >> 1 Source -> Queue -> UnQueue -> Print -> Discard; >> 2 Script( ... ); >> >> So line 1 just sets the network and line 2 implements the >> configuration. Is line 2 executed parallel with line 1? Or is it >> executed after line 1 is executed? >> >> Thanks. >> -- >> Best Regards, >> >> Jimmy >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From fanyang.scu at gmail.com Fri Mar 12 14:43:22 2010 From: fanyang.scu at gmail.com (Jimmy) Date: Fri, 12 Mar 2010 14:43:22 -0500 Subject: [Click] Script element In-Reply-To: <4B99391A.5060605@eecs.harvard.edu> References: <2fe59bbc1003111010o40c02a9aid9a70f3a6de4cc0f@mail.gmail.com> <4B99391A.5060605@eecs.harvard.edu> Message-ID: <2fe59bbc1003121143i75f3165apa92d608794122e18@mail.gmail.com> Thank you all for this kind explanation, which clearifies my confusion. I'm just starting with click and I think it is really fun! J. On Thu, Mar 11, 2010 at 1:40 PM, Ian Rose wrote: > Jimmy - > > I'm not sure if you care, but if you want your Script element to run at > other times (e.g. when a packet is received, or when a handler is called), > take a look at the optional TYPE parameter: > > http://read.cs.ucla.edu/click/elements/script#script-types > > For what its worth, Script(TYPE PACKET, ...) is a nice debugging tool. > > - Ian > > Cliff Frey wrote: >> >> First the click configuration is loaded. ?This means that all elements are >> created (including all Script elements) and configured and initialized. >> ?At >> this point, the click configuration is considered to be loaded. ?Then >> "tasks" are allowed to run. ?In your example, the Source element, UnQueue >> element, and Script element all have associated tasks. ?Those tasks will >> start running in round-robin fashion. ?You cannot really make any >> assumptions about the order of the first instruction in your script vs the >> first action of the Source element, but you can control it if the Source >> starts out disabled. >> >> For instance >> >> click foo.click >> >> foo.click: >> >> is :: InfiniteSource(LIMIT 1, ACTIVE false) -> Print -> Discard; >> Script( >> ?print "script is starting", >> ?writeq is.active true, >> ?print "script started the source", >> ?wait 1.0, >> ?print "script is stopping the router", >> ?stop);' >> >> >> On Thu, Mar 11, 2010 at 10:10 AM, Jimmy wrote: >> >>> Hi all, >>> >>> I read the script element description and know that it can be used to >>> configure the network. I also used it to implement some simple >>> comfiguration. >>> >>> My question is how and when is this element executed? ?Below is a >>> simple example: >>> >>> 1 ?Source -> Queue -> UnQueue -> Print -> Discard; >>> 2 ?Script( ... ); >>> >>> So line 1 just sets the network and line 2 implements the >>> configuration. Is line 2 executed parallel with line 1? Or is it >>> executed after line 1 is executed? >>> >>> Thanks. >>> -- >>> Best Regards, >>> >>> Jimmy >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > -- Best Regards, Jimmy From rajamhayek at yahoo.com Fri Mar 12 23:27:24 2010 From: rajamhayek at yahoo.com (R H) Date: Fri, 12 Mar 2010 20:27:24 -0800 (PST) Subject: [Click] Multithreaded question In-Reply-To: <4B89C5A7.2030708@cs.ucla.edu> Message-ID: <924735.43513.qm@web56503.mail.re3.yahoo.com> Thanks Eddie. We managed quite well with a single thread.? And now we have much better understanding of click's scheduling/threading internals. The issue with burstiness:? We had an active element with a requirement to produce a packet every 10ms, we had a timer and task scheduling combined.? We placed it in its own thread using StaticThreadSched.? Under load, the producer sometimes sends more than a packet, other times misses the 10ms mark.? Even when moving the logic to a separate executable running independent of click, we still had the same results until we up'ed the thread's priority to its highest level and ensured no services kick-in when running... Thanks again for your help, Raja? --- On Sat, 2/27/10, Eddie Kohler wrote: From: Eddie Kohler Subject: Re: [Click] Multithreaded question To: rajamhayek at yahoo.com Cc: "Click Mailinglist" Date: Saturday, February 27, 2010, 5:23 PM Hi Raja, For some discussion on the "best" way to assign tasks to threads, see the paper by Chen and Morris, "Flexible COntrol of Parallelism...". As for your 1-4, the thing about queues is that they are in *both* a push region *and* a pull region; that is their entire point.? Queues are passive elements and do not beling to threads themselves.? So your 2-4 options don't really make sense. FWIW at Intel's Routebricks project we have found it valuable to ensure that only one core touches a packet on its entire path through the router. Parallelism is achieved by having separable paths. As for bursty behavior, hard to know there what you mean either.? Were you using StaticThreadSched?? BalancedThreadSched?? If you didn't use either, then in your multithreaded program only one thread was doing all the work. Eddie rajamhayek at yahoo.com wrote: > Hi Eddie, > > I am not sure how the threading/stride scheduling work together.? I have included a sample image, extracted from a Master's thesis, that describe the single threaded execution.? In this picture, the active elements (A1, A2, and A3) are scheduled to run in sequence.? When they do run, they call synchronously the elements they are connected to until a queue (passive element) is reached.? This decomposes the execution into push/pull regions. Now we want to move this to multithreaded execution, what is the best way of adding elements to threads: > > 1- Only the active elements run on threads. > 2- The full regions are assigned to threads and the queues remain in the main thread. > 3- The full regions are assigned to threads and the queues are in the push region. > 4- The full regions are assigned to threads and the queues are in the pull regions. > > So far with our application, assigning only active elements to threads, we are getting an unwanted bursty behavior of packet.? In single threaded, the bursty behavior disappears but we do not reach the required throughput.? I appreciate any pointers that can help us resolve this problem. > > Thank you, > Raja > > > > > > ------------------------------------------------------------------------ > From msmythili at gmail.com Mon Mar 15 14:10:25 2010 From: msmythili at gmail.com (Mythili) Date: Mon, 15 Mar 2010 11:10:25 -0700 Subject: [Click] kernel mode - 2.6.24.7 Message-ID: <2c9314111003151110v3347be5en6d289a0150fee355@mail.gmail.com> Hi I am running click on linux 2.6.24.7 (source from kernel.org). The kernel has been patched successfully with the latest version of click. I am able to run click in the kernel mode. I need to run some floating point arithmetic in a new element. I see multiple errors when I run make install. And of course insmod fails as there are undefined symbols in the .ko files created by the make install command. WARNING: "__mulsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! WARNING: "__floatsisf" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! WARNING: "__subsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! WARNING: "__divsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! I am able to run click in the usermode. I also tried using the same arithmetic in a c file and loading it as a kernel module. There are no errors. So my guess is that click needs to be configured with some specific flags/options to fix this. I currently tried with no flags as /usr/src/linux points to the correct source directory. ( I am a little unsure about how grid elements don't cause this error as floating point numbers are used there). I would really appreciate any help on this. Regards Mythili From a.greenhalgh at cs.ucl.ac.uk Mon Mar 15 14:23:19 2010 From: a.greenhalgh at cs.ucl.ac.uk (adam.greenhalgh@googlemail.com) Date: Mon, 15 Mar 2010 18:23:19 +0000 (UTC) Subject: [Click] kernel mode - 2.6.24.7 Message-ID: <19773433.21346.1268677400549.JavaMail.seven@ap0.p4.uk.7sys.net> I didn't think the kernel supported floating point arithmetic. I could be wrong , but its difficult to look things up from a commuter train. Adam -original message- Subject: [Click] kernel mode - 2.6.24.7 From: "Mythili" Date: 15/03/2010 6:15 pm Hi I am running click on linux 2.6.24.7 (source from kernel.org). The kernel has been patched successfully with the latest version of click. I am able to run click in the kernel mode. I need to run some floating point arithmetic in a new element. I see multiple errors when I run make install. And of course insmod fails as there are undefined symbols in the .ko files created by the make install command. WARNING: "__mulsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! WARNING: "__floatsisf" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! WARNING: "__subsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! WARNING: "__divsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] undefined! I am able to run click in the usermode. I also tried using the same arithmetic in a c file and loading it as a kernel module. There are no errors. So my guess is that click needs to be configured with some specific flags/options to fix this. I currently tried with no flags as /usr/src/linux points to the correct source directory. ( I am a little unsure about how grid elements don't cause this error as floating point numbers are used there). I would really appreciate any help on this. Regards Mythili _______________________________________________ click mailing list click at amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click From msmythili at gmail.com Mon Mar 15 14:24:52 2010 From: msmythili at gmail.com (Mythili) Date: Mon, 15 Mar 2010 11:24:52 -0700 Subject: [Click] kernel mode - 2.6.24.7 In-Reply-To: <19773433.21346.1268677400549.JavaMail.seven@ap0.p4.uk.7sys.net> References: <19773433.21346.1268677400549.JavaMail.seven@ap0.p4.uk.7sys.net> Message-ID: <2c9314111003151124v454fdb4en7d8b1e0ea9c25d43@mail.gmail.com> But how is it that any other file with floating point arithmetic works fine and can be loaded as a kernel module? I am not sure if I get what you are saying. Mythili On 15 March 2010 11:23, adam.greenhalgh at googlemail.com < a.greenhalgh at cs.ucl.ac.uk> wrote: > I didn't think the kernel supported floating point arithmetic. I could be > wrong , but its difficult to look things up from a commuter train. > > Adam > > -original message- > Subject: [Click] kernel mode - 2.6.24.7 > From: "Mythili" > Date: 15/03/2010 6:15 pm > > Hi > I am running click on linux 2.6.24.7 (source from kernel.org). The > kernel has been patched successfully with the latest version of click. I am > able to run click in the kernel mode. I need to run some floating point > arithmetic in a new element. I see multiple errors when I run make install. > And of course insmod fails as there are undefined symbols in the .ko files > created by the make install command. > > WARNING: "__mulsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > undefined! > WARNING: "__floatsisf" > [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > undefined! > WARNING: "__subsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > undefined! > WARNING: "__divsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > undefined! > > I am able to run click in the usermode. I also tried using the same > arithmetic in a c file and loading it as a kernel module. There are no > errors. > > So my guess is that click needs to be configured with some specific > flags/options to fix this. I currently tried with no flags as > /usr/src/linux > points to the correct source directory. ( I am a little unsure about how > grid elements don't cause this error as floating point numbers are used > there). I would really appreciate any help on this. > > Regards > Mythili > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > From ianrose at eecs.harvard.edu Mon Mar 15 14:56:16 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Mon, 15 Mar 2010 14:56:16 -0400 Subject: [Click] kernel mode - 2.6.24.7 In-Reply-To: <2c9314111003151124v454fdb4en7d8b1e0ea9c25d43@mail.gmail.com> References: <19773433.21346.1268677400549.JavaMail.seven@ap0.p4.uk.7sys.net> <2c9314111003151124v454fdb4en7d8b1e0ea9c25d43@mail.gmail.com> Message-ID: <4B9E82D0.2040203@eecs.harvard.edu> What do you mean by "any other file with floating point arithmetic"? Are you talking about click code specifically? If so, I think you'll find that there is no kernel-mode floating point in click. If you are seeing floating point code its probably inside a '#ifdef CLICK_USERLEVEL' block. - Ian Mythili wrote: > But how is it that any other file with floating point arithmetic works fine > and can be loaded as a kernel module? I am not sure if I get what you are > saying. > > Mythili > > > On 15 March 2010 11:23, adam.greenhalgh at googlemail.com < > a.greenhalgh at cs.ucl.ac.uk> wrote: > >> I didn't think the kernel supported floating point arithmetic. I could be >> wrong , but its difficult to look things up from a commuter train. >> >> Adam >> >> -original message- >> Subject: [Click] kernel mode - 2.6.24.7 >> From: "Mythili" >> Date: 15/03/2010 6:15 pm >> >> Hi >> I am running click on linux 2.6.24.7 (source from kernel.org). The >> kernel has been patched successfully with the latest version of click. I am >> able to run click in the kernel mode. I need to run some floating point >> arithmetic in a new element. I see multiple errors when I run make install. >> And of course insmod fails as there are undefined symbols in the .ko files >> created by the make install command. >> >> WARNING: "__mulsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >> undefined! >> WARNING: "__floatsisf" >> [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >> undefined! >> WARNING: "__subsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >> undefined! >> WARNING: "__divsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >> undefined! >> >> I am able to run click in the usermode. I also tried using the same >> arithmetic in a c file and loading it as a kernel module. There are no >> errors. >> >> So my guess is that click needs to be configured with some specific >> flags/options to fix this. I currently tried with no flags as >> /usr/src/linux >> points to the correct source directory. ( I am a little unsure about how >> grid elements don't cause this error as floating point numbers are used >> there). I would really appreciate any help on this. >> >> Regards >> Mythili >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From rchertov at cs.ucsb.edu Mon Mar 15 14:51:36 2010 From: rchertov at cs.ucsb.edu (rchertov at cs.ucsb.edu) Date: Mon, 15 Mar 2010 11:51:36 -0700 Subject: [Click] kernel mode - 2.6.24.7 In-Reply-To: <2c9314111003151124v454fdb4en7d8b1e0ea9c25d43@mail.gmail.com> References: <19773433.21346.1268677400549.JavaMail.seven@ap0.p4.uk.7sys.net> <2c9314111003151124v454fdb4en7d8b1e0ea9c25d43@mail.gmail.com> Message-ID: On 11:24 am 03/15/10 Mythili wrote: > But how is it that any other file with floating point arithmetic works > fine and can be loaded as a kernel module? I am not sure if I get what > you are saying. Please take a look at this. http://lkml.indiana.edu/hypermail/linux/kernel/0405.3/1620.html Typically, FP operations are not a good idea in the kernel. Roman > > Mythili > > > On 15 March 2010 11:23, adam.greenhalgh at googlemail.com < > a.greenhalgh at cs.ucl.ac.uk> wrote: > > > I didn't think the kernel supported floating point arithmetic. I > > could be wrong , but its difficult to look things up from a commuter > > train. > > > > Adam > > > > -original message- > > Subject: [Click] kernel mode - 2.6.24.7 > > From: "Mythili" > > Date: 15/03/2010 6:15 pm > > > > Hi > > I am running click on linux 2.6.24.7 (source from kernel.org). The > > kernel has been patched successfully with the latest version of > > click. I am able to run click in the kernel mode. I need to run some > > floating point arithmetic in a new element. I see multiple errors > > when I run make install. And of course insmod fails as there are > > undefined symbols in the .ko files created by the make install > > command. > > > > WARNING: "__mulsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > > undefined! > > WARNING: "__floatsisf" > > [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > > undefined! > > WARNING: "__subsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > > undefined! > > WARNING: "__divsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] > > undefined! > > > > I am able to run click in the usermode. I also tried using the same > > arithmetic in a c file and loading it as a kernel module. There are no > > errors. > > > > So my guess is that click needs to be configured with some specific > > flags/options to fix this. I currently tried with no flags as > > /usr/src/linux > > points to the correct source directory. ( I am a little unsure about > > how grid elements don't cause this error as floating point numbers > > are used there). I would really appreciate any help on this. > > > > Regards > > Mythili > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From msmythili at gmail.com Mon Mar 15 15:06:14 2010 From: msmythili at gmail.com (Mythili) Date: Mon, 15 Mar 2010 12:06:14 -0700 Subject: [Click] kernel mode - 2.6.24.7 In-Reply-To: <4B9E82D0.2040203@eecs.harvard.edu> References: <19773433.21346.1268677400549.JavaMail.seven@ap0.p4.uk.7sys.net> <2c9314111003151124v454fdb4en7d8b1e0ea9c25d43@mail.gmail.com> <4B9E82D0.2040203@eecs.harvard.edu> Message-ID: <2c9314111003151206u5e2c152k3eb00b89bd68069c@mail.gmail.com> I don't mean a click file. I meant any simple kernel module with the same arithmetic doesn't throw any errors and am able to add the module to the kernel. And I did check about the click element .. the one I was looking at is indeed for userlevel. Thank you for the link on the floating point arithmetic usage in kernel. Mythili On 15 March 2010 11:56, Ian Rose wrote: > What do you mean by "any other file with floating point arithmetic"? Are > you talking about click code specifically? If so, I think you'll find that > there is no kernel-mode floating point in click. If you are seeing floating > point code its probably inside a '#ifdef CLICK_USERLEVEL' block. > > - Ian > > > > Mythili wrote: > >> But how is it that any other file with floating point arithmetic works >> fine >> and can be loaded as a kernel module? I am not sure if I get what you are >> saying. >> >> Mythili >> >> >> On 15 March 2010 11:23, adam.greenhalgh at googlemail.com < >> a.greenhalgh at cs.ucl.ac.uk> wrote: >> >> I didn't think the kernel supported floating point arithmetic. I could be >>> wrong , but its difficult to look things up from a commuter train. >>> >>> Adam >>> >>> -original message- >>> Subject: [Click] kernel mode - 2.6.24.7 >>> From: "Mythili" >>> Date: 15/03/2010 6:15 pm >>> >>> Hi >>> I am running click on linux 2.6.24.7 (source from kernel.org). The >>> kernel has been patched successfully with the latest version of click. I >>> am >>> able to run click in the kernel mode. I need to run some floating point >>> arithmetic in a new element. I see multiple errors when I run make >>> install. >>> And of course insmod fails as there are undefined symbols in the .ko >>> files >>> created by the make install command. >>> >>> WARNING: "__mulsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >>> undefined! >>> WARNING: "__floatsisf" >>> [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >>> undefined! >>> WARNING: "__subsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >>> undefined! >>> WARNING: "__divsf3" [/home/live/Desktop/click-1.8.0/linuxmodule/click.ko] >>> undefined! >>> >>> I am able to run click in the usermode. I also tried using the same >>> arithmetic in a c file and loading it as a kernel module. There are no >>> errors. >>> >>> So my guess is that click needs to be configured with some specific >>> flags/options to fix this. I currently tried with no flags as >>> /usr/src/linux >>> points to the correct source directory. ( I am a little unsure about how >>> grid elements don't cause this error as floating point numbers are used >>> there). I would really appreciate any help on this. >>> >>> Regards >>> Mythili >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >>> >>> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > From jyyoo at netmedia.gist.ac.kr Tue Mar 16 22:11:54 2010 From: jyyoo at netmedia.gist.ac.kr (JaeYong Yoo) Date: Wed, 17 Mar 2010 11:11:54 +0900 Subject: [Click] vim syntax highlight of click script Message-ID: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> Hi, is there any vim plugin that highlights according to the syntax of click script? wishes, jaeyong From gcinalo at gmail.com Tue Mar 16 22:15:52 2010 From: gcinalo at gmail.com (Gcinah Dludla) Date: Wed, 17 Mar 2010 04:15:52 +0200 Subject: [Click] Learning Click Message-ID: <7f03c1341003161915p34e7d8e6n7d94bf20f99c5181@mail.gmail.com> Hi, on the Click, how do you check the IP packets, methods, functions to manipulate the IP packets. Looking forward to your reply Gcina Dludla. From harald at net.t-labs.tu-berlin.de Wed Mar 17 02:54:26 2010 From: harald at net.t-labs.tu-berlin.de (Harald Schioeberg) Date: Wed, 17 Mar 2010 07:54:26 +0100 Subject: [Click] Learning Click In-Reply-To: <7f03c1341003161915p34e7d8e6n7d94bf20f99c5181@mail.gmail.com> References: <7f03c1341003161915p34e7d8e6n7d94bf20f99c5181@mail.gmail.com> Message-ID: <4BA07CA2.4000607@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gcinah Dludla wrote: > on the Click, how do you check the IP packets, methods, functions to > manipulate the IP packets. Hi Gcinah, For a first start: check out the tutorials at http://www.read.cs.ucla.edu/click/learning Welcome and good luck Harald -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkugfKEACgkQy8wrZ9OvkU0psQCgwb1ykcfbOvJKyz51pHv6MPOp MbsAn0hlF7aNMw1d1LIpvruLf4qMPWtN =c85f -----END PGP SIGNATURE----- From harald at net.t-labs.tu-berlin.de Wed Mar 17 04:15:34 2010 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Wed, 17 Mar 2010 09:15:34 +0100 Subject: [Click] Learning Click In-Reply-To: <7f03c1341003170109o4fbcba1dm74e535fb16a3c960@mail.gmail.com> References: <7f03c1341003161915p34e7d8e6n7d94bf20f99c5181@mail.gmail.com> <4BA07CA2.4000607@net.t-labs.tu-berlin.de> <7f03c1341003170053j63e79076xb7f2b1cce2cfacd4@mail.gmail.com> <7f03c1341003170109o4fbcba1dm74e535fb16a3c960@mail.gmail.com> Message-ID: <4BA08FA6.4050307@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gcinah Dludla wrote: > How do you manipulate IP packets in Click. Almost all of click is concerned with "manipulating IP packets". If the tutorials do not cover what you want to do: please be a bit more specific, so that we can help you out with your question. Harald > > On Wed, Mar 17, 2010 at 9:53 AM, Gcinah Dludla > wrote: > > Thanks for your reply. > > i went through this link http://www.read.cs.ucla.edu/click/learning, > u have sent to me checked the tutorial, but still i couldn't figure > out , How in Click under the components, to check: > IP packets, methods and functions to manipulate IP packets > Could you please at least direct me where really i should go. > > Looking for to your reply > > On Wed, Mar 17, 2010 at 8:54 AM, Harald Schioeberg > > wrote: > > > > Gcinah Dludla wrote: >> on the Click, how do you check the IP packets, methods, > functions to >> manipulate the IP packets. > > Hi Gcinah, > > For a first start: check out the tutorials at > http://www.read.cs.ucla.edu/click/learning > > Welcome and good luck > > Harald - -- Harald Schi?berg Technische Universit?t Berlin | T-Laboratories | FG INET www: http://www.net.t-labs.tu-berlin.de Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLoI+my8wrZ9OvkU0RAkuyAKCuBMTOhS+1qWhrtNowEHldayajNgCbBreR qtF0oYd0uudcTUTp1tWa5MA= =91AU -----END PGP SIGNATURE----- From jesse.r.brown at lmco.com Wed Mar 17 06:50:32 2010 From: jesse.r.brown at lmco.com (Jesse Brown) Date: Wed, 17 Mar 2010 06:50:32 -0400 Subject: [Click] vim syntax highlight of click script In-Reply-To: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> References: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> Message-ID: <4BA0B3F8.3010402@atl.lmco.com> JaeYong Yoo wrote: > Hi, > > is there any vim plugin that highlights according to the syntax of click script? > > wishes, > > jaeyong > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > Hi jaeyong, In general, the C syntax is pretty close. Based on that I added the elements (current as of 1.6.0), support for the '->' and '::' operators and the elementclass keyword. Attached is the syntax file. To use this you would edit your .vimrc to include the following lines: au BufNewFile,BufRead *.click set filetype=click au! Syntax click source ~/.vim/syntax/click.vim And place the attached file in ~/.vim/syntax/click.vim I understand that this is pretty crude, but it works well for me. Jesse -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: click.vim Url: http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100317/a029bc86/attachment-0001.txt From lbro at pulz8.com Wed Mar 17 07:02:54 2010 From: lbro at pulz8.com (Lars Bro) Date: Wed, 17 Mar 2010 12:02:54 +0100 Subject: [Click] Weird bridge behavior unpatched 2.6.31.12 Message-ID: <22b0d68b1003170402xf874a06hef36a1c0833984bf@mail.gmail.com> Hi, I have a click configuration where I need make a tap on the traffic between two hosts. Therefore, I have made a simple "Bridge" element class like below: /* * Bridge between two interfaces and send IP packets to output */ elementclass Bridge { \$if1, \$if2 | FromDevice(\$if1) -> if1_tee::Tee(); FromDevice(\$if2) -> if2_tee::Tee(); if1_tee\[0\] -> Queue() -> ToDevice(\$if2); if1_tee\[1\] -> Strip(14) -> output; if2_tee\[0\] -> Queue() -> ToDevice(\$if1); if2_tee\[1\] -> Strip(14) -> output; }; When the test router is not running, I will of course need the bridging functionality anyway, so I do brctl addbr br0 brctl addif br0 xxx brctl addif br0 yyy ip link set up dev br0 Before starting the router. I remove the bridge and set the interfaces up ip link set down dev br0 brctl delbr br0 ip link set up dev xxx ip link set up dev yyy click-install ... This seems not to work, however. It seems that only broadcast traffic (and maybe also traffic directly for the xxx and yyy MAC addrees, but I dont know, since I am trying to make a bridge) If I try with ip link set xxx promisc on ip link set yyy promisc on I get "some" data through, still not good enough But if I start the router without removing the original bridge, it works fine as far as I can see. Is this as it is supposed to be ? yours, Lars Bro From jyyoo at netmedia.gist.ac.kr Wed Mar 17 07:26:46 2010 From: jyyoo at netmedia.gist.ac.kr (JaeYong Yoo) Date: Wed, 17 Mar 2010 20:26:46 +0900 Subject: [Click] =?ks_c_5601-1987?q?=C8=B8=BD=C5=3A___vim_syntax_highlight?= =?ks_c_5601-1987?q?_of_click_script?= In-Reply-To: <4BA0B3F8.3010402@atl.lmco.com> References: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr>, <4BA0B3F8.3010402@atl.lmco.com> Message-ID: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD7A@NML2007.netmedia.kjist.ac.kr> Hi Jesse, I have applied according to your instructions and when I open .click file, vim shows these error messages, "multiop.click" 248L, 10339C Error detected while processing /home/yjaeyong/.vim/syntax/click.vim: line 5: E492: Not an editor command: ^M line 7: E15: Invalid expression: exists("b:current_syntax")^M line 339: E171: Missing :endif line 6: E492: Not an editor command: ^M line 7: E15: Invalid expression: exists("b:current_syntax")^M line 339: E171: Missing :endif do you have any clue? wishes, jaeyong ________________________________________ ?? ??: Jesse Brown [jesse.r.brown at lmco.com] ?? ??: 2010? 3? 17? ??? ?? 7:50 ?? ??: JaeYong Yoo ??: click at pdos.csail.mit.edu ??: Re: [Click] vim syntax highlight of click script JaeYong Yoo wrote: > Hi, > > is there any vim plugin that highlights according to the syntax of click script? > > wishes, > > jaeyong > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > Hi jaeyong, In general, the C syntax is pretty close. Based on that I added the elements (current as of 1.6.0), support for the '->' and '::' operators and the elementclass keyword. Attached is the syntax file. To use this you would edit your .vimrc to include the following lines: au BufNewFile,BufRead *.click set filetype=click au! Syntax click source ~/.vim/syntax/click.vim And place the attached file in ~/.vim/syntax/click.vim I understand that this is pretty crude, but it works well for me. Jesse From jesse.r.brown at lmco.com Wed Mar 17 07:50:50 2010 From: jesse.r.brown at lmco.com (Jesse Brown) Date: Wed, 17 Mar 2010 07:50:50 -0400 Subject: [Click] =?euc-kr?q?=C8=B8=BD=C5=3A___vim_syntax_highlight_of_clic?= =?euc-kr?q?k_script?= In-Reply-To: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD7A@NML2007.netmedia.kjist.ac.kr> References: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> <4BA0B3F8.3010402@atl.lmco.com> <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD7A@NML2007.netmedia.kjist.ac.kr> Message-ID: <4BA0C21A.9090701@atl.lmco.com> Hi jaeyong: The ^M characters in your file are causing problems. It seems as though you edited the file in 'DOS' mode. You can either create the file directly on a linux machine or run dos2unix on the file to remove the ^M characters. Jesse JaeYong Yoo wrote: > Hi Jesse, > > I have applied according to your instructions and when I open .click file, vim shows these error messages, > > > "multiop.click" 248L, 10339C > Error detected while processing /home/yjaeyong/.vim/syntax/click.vim: > line 5: > E492: Not an editor command: ^M > line 7: > E15: Invalid expression: exists("b:current_syntax")^M > line 339: > E171: Missing :endif > line 6: > E492: Not an editor command: ^M > line 7: > E15: Invalid expression: exists("b:current_syntax")^M > line 339: > E171: Missing :endif > > do you have any clue? > > wishes, > > jaeyong > ________________________________________ > ?? ??: Jesse Brown [jesse.r.brown at lmco.com] > ?? ??: 2010? 3? 17? ??? ?? 7:50 > ?? ??: JaeYong Yoo > ??: click at pdos.csail.mit.edu > ??: Re: [Click] vim syntax highlight of click script > > JaeYong Yoo wrote: > >> Hi, >> >> is there any vim plugin that highlights according to the syntax of click script? >> >> wishes, >> >> jaeyong >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> >> > Hi jaeyong, > > In general, the C syntax is pretty close. Based on that I added the > elements (current as of 1.6.0), support for the '->' and '::' operators > and the elementclass keyword. > > Attached is the syntax file. To use this you would edit your .vimrc to > include the following lines: > > au BufNewFile,BufRead *.click set filetype=click > au! Syntax click source ~/.vim/syntax/click.vim > > And place the attached file in ~/.vim/syntax/click.vim > > I understand that this is pretty crude, but it works well for me. > > Jesse > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From jyyoo at netmedia.gist.ac.kr Wed Mar 17 07:57:23 2010 From: jyyoo at netmedia.gist.ac.kr (JaeYong Yoo) Date: Wed, 17 Mar 2010 20:57:23 +0900 Subject: [Click] =?ks_c_5601-1987?b?yLi9xTogIMi4vcU6ICAgdmltIHN5bnRheCBo?= =?ks_c_5601-1987?q?ighlight_of_click_script?= In-Reply-To: <4BA0C21A.9090701@atl.lmco.com> References: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> <4BA0B3F8.3010402@atl.lmco.com> <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD7A@NML2007.netmedia.kjist.ac.kr>, <4BA0C21A.9090701@atl.lmco.com> Message-ID: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD7B@NML2007.netmedia.kjist.ac.kr> It works!!! thanks a lot Jesse jaeyong ________________________________________ ?? ??: Jesse Brown [jesse.r.brown at lmco.com] ?? ??: 2010? 3? 17? ??? ?? 8:50 ?? ??: JaeYong Yoo ??: click at pdos.csail.mit.edu ??: Re: [Click] ??: vim syntax highlight of click script Hi jaeyong: The ^M characters in your file are causing problems. It seems as though you edited the file in 'DOS' mode. You can either create the file directly on a linux machine or run dos2unix on the file to remove the ^M characters. Jesse JaeYong Yoo wrote: > Hi Jesse, > > I have applied according to your instructions and when I open .click file, vim shows these error messages, > > > "multiop.click" 248L, 10339C > Error detected while processing /home/yjaeyong/.vim/syntax/click.vim: > line 5: > E492: Not an editor command: ^M > line 7: > E15: Invalid expression: exists("b:current_syntax")^M > line 339: > E171: Missing :endif > line 6: > E492: Not an editor command: ^M > line 7: > E15: Invalid expression: exists("b:current_syntax")^M > line 339: > E171: Missing :endif > > do you have any clue? > > wishes, > > jaeyong > ________________________________________ > ?? ??: Jesse Brown [jesse.r.brown at lmco.com] > ?? ??: 2010? 3? 17? ??? ?? 7:50 > ?? ??: JaeYong Yoo > ??: click at pdos.csail.mit.edu > ??: Re: [Click] vim syntax highlight of click script > > JaeYong Yoo wrote: > >> Hi, >> >> is there any vim plugin that highlights according to the syntax of click script? >> >> wishes, >> >> jaeyong >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> >> > Hi jaeyong, > > In general, the C syntax is pretty close. Based on that I added the > elements (current as of 1.6.0), support for the '->' and '::' operators > and the elementclass keyword. > > Attached is the syntax file. To use this you would edit your .vimrc to > include the following lines: > > au BufNewFile,BufRead *.click set filetype=click > au! Syntax click source ~/.vim/syntax/click.vim > > And place the attached file in ~/.vim/syntax/click.vim > > I understand that this is pretty crude, but it works well for me. > > Jesse > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From kohler at cs.ucla.edu Wed Mar 17 11:43:28 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 17 Mar 2010 08:43:28 -0700 Subject: [Click] vim syntax highlight of click script In-Reply-To: <4BA0B3F8.3010402@atl.lmco.com> References: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> <4BA0B3F8.3010402@atl.lmco.com> Message-ID: <4BA0F8A0.6080808@cs.ucla.edu> Neat! Jesse, would you object to this vim script being added to the distribution? Thanks, E Jesse Brown wrote: > JaeYong Yoo wrote: >> Hi, >> >> is there any vim plugin that highlights according to the syntax of >> click script? >> >> wishes, >> >> jaeyong >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> > Hi jaeyong, > > In general, the C syntax is pretty close. Based on that I added the > elements (current as of 1.6.0), support for the '->' and '::' operators > and the elementclass keyword. > > Attached is the syntax file. To use this you would edit your .vimrc to > include the following lines: > > au BufNewFile,BufRead *.click set filetype=click > au! Syntax click source ~/.vim/syntax/click.vim > > And place the attached file in ~/.vim/syntax/click.vim > > I understand that this is pretty crude, but it works well for me. > > Jesse > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Mar 17 12:09:58 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 17 Mar 2010 09:09:58 -0700 Subject: [Click] Weird bridge behavior unpatched 2.6.31.12 In-Reply-To: <22b0d68b1003170402xf874a06hef36a1c0833984bf@mail.gmail.com> References: <22b0d68b1003170402xf874a06hef36a1c0833984bf@mail.gmail.com> Message-ID: <4BA0FED6.8040203@cs.ucla.edu> Lars, I strongly recommend against mixing brctl with Click linuxpatchless. Click REPLACES the bridge hook when it is installed. I have no reason to believe brctl will work. Eddie Lars Bro wrote: > Hi, > > I have a click configuration where I need make a tap on the traffic between > two hosts. Therefore, I have made a simple > "Bridge" element class like below: > /* > * Bridge between two interfaces and send IP packets to output > */ > elementclass Bridge { > \$if1, \$if2 | > FromDevice(\$if1) -> > if1_tee::Tee(); > FromDevice(\$if2) -> > if2_tee::Tee(); > if1_tee\[0\] -> > Queue() -> > ToDevice(\$if2); > if1_tee\[1\] -> > Strip(14) -> > output; > if2_tee\[0\] -> > Queue() -> > ToDevice(\$if1); > if2_tee\[1\] -> > Strip(14) -> > output; > }; > > When the test router is not running, I will of course need the bridging > functionality anyway, so I do > brctl addbr br0 > brctl addif br0 xxx > brctl addif br0 yyy > ip link set up dev br0 > > Before starting the router. I remove the bridge and set the interfaces up > ip link set down dev br0 > brctl delbr br0 > ip link set up dev xxx > ip link set up dev yyy > click-install ... > > This seems not to work, however. It seems that only broadcast traffic (and > maybe also traffic directly for the xxx and yyy > MAC addrees, but I dont know, since I am trying to make a bridge) > > If I try with > ip link set xxx promisc on > ip link set yyy promisc on > > I get "some" data through, still not good enough > > But if I start the router without removing the original bridge, it works > fine as far as I can see. > > Is this as it is supposed to be ? > > > yours, > Lars Bro > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Wed Mar 17 20:08:26 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Wed, 17 Mar 2010 20:08:26 -0400 Subject: [Click] profiling / debugging tools or tips? Message-ID: <4BA16EFA.5020908@eecs.harvard.edu> Hello all, I need to do some debugging and profiling of my click configuration which consists of a large number of both standard and custom (i.e. written by me) elements. Specifically, I would like to get an idea of the CPU usage of each element, or at least know what the biggest consumers are. Are there any tools within click to help me do this, or does anyone have any tips on how to go about this? The best idea that I can come up with is to take a guess at which elements might be the CPU hogs and instrument them with getrusage() calls at every entrance and exit points to the element. Unfortunately this is a bit labor-intensive (and a little error-prone) as there are potentially many such points (e.g. push(), pull(), run_timer(), run_task()). Additionally, the resolution is pretty low (looks like 1ms on my system) so this *may* result in some inaccuracies. Or may not... perhaps over time random chance will even things out so that over long enough periods each element's summed cpu time will be mostly accurate? It would be handy to implement this instead in Click's core instead of in each individual element; you might imagine calling some initialization methods to tell Click which elements to profile for you. However I don't think this is possible currently - although Click should be able to properly track whenever a timer or task fires (and for which element) I don't think click is able to track when a packet (and therefore control) is pushed/pulled from one element to another. If I am wrong about this please correct me. Another half-baked idea I had was something similar to how (some) OSes sample the process scheduler to estimate each process' load average. So the idea would be to somehow "generate an interrupt" every so often and check which element was currently "active" at that time. The active element gets 1 point and each elements "load average" is the fraction of points that it got over some recent time window. But I don't really have an idea of how to actualize this in click; I don't really have an idea of how to do either the "generate an interrupt" part or (especially) the "figure out which element is 'active'" part. Anyhow, before I dove into instrumenting individual elements with getrusage() calls I thought I'd solicit some advice on whether or not the idea made any sense. cheers, - Ian From cliff at meraki.com Wed Mar 17 20:32:50 2010 From: cliff at meraki.com (Cliff Frey) Date: Wed, 17 Mar 2010 17:32:50 -0700 Subject: [Click] profiling / debugging tools or tips? In-Reply-To: <4BA16EFA.5020908@eecs.harvard.edu> References: <4BA16EFA.5020908@eecs.harvard.edu> Message-ID: click already supports exactly what you are talking about! if you configure it with ./configure --enable-stats=2 then every element is given a 'cycles' read handler. However, using generic profiling tools is likely to also give you feedback (with much lower overhead). Perhaps take a look at oprofile as a package for doing this. At the other end of the spectrum, you can use callgrind (which is part of the valgrind package) along with kcachegrind to give you a break down of the exact number of CPU _instructions_ spent in each of your elements, along with per task/stack information. That information can be very colorful and interesting to look at, however it tends not not-very-closely line up with reality because instruction count is not a great proxy for wallclock time. Also, running through callgrind with slow down your application by 50x or so, but it it can still be very interesting to see. Cliff On Wed, Mar 17, 2010 at 5:08 PM, Ian Rose wrote: > Hello all, > > I need to do some debugging and profiling of my click configuration > which consists of a large number of both standard and custom (i.e. > written by me) elements. Specifically, I would like to get an idea of > the CPU usage of each element, or at least know what the biggest > consumers are. > > Are there any tools within click to help me do this, or does anyone have > any tips on how to go about this? The best idea that I can come up with > is to take a guess at which elements might be the CPU hogs and > instrument them with getrusage() calls at every entrance and exit points > to the element. Unfortunately this is a bit labor-intensive (and a > little error-prone) as there are potentially many such points (e.g. > push(), pull(), run_timer(), run_task()). > > Additionally, the resolution is pretty low (looks like 1ms on my system) > so this *may* result in some inaccuracies. Or may not... perhaps over > time random chance will even things out so that over long enough periods > each element's summed cpu time will be mostly accurate? > > It would be handy to implement this instead in Click's core instead of > in each individual element; you might imagine calling some > initialization methods to tell Click which elements to profile for you. > However I don't think this is possible currently - although Click > should be able to properly track whenever a timer or task fires (and for > which element) I don't think click is able to track when a packet (and > therefore control) is pushed/pulled from one element to another. If I > am wrong about this please correct me. > > Another half-baked idea I had was something similar to how (some) OSes > sample the process scheduler to estimate each process' load average. So > the idea would be to somehow "generate an interrupt" every so often and > check which element was currently "active" at that time. The active > element gets 1 point and each elements "load average" is the fraction of > points that it got over some recent time window. But I don't really > have an idea of how to actualize this in click; I don't really have an > idea of how to do either the "generate an interrupt" part or > (especially) the "figure out which element is 'active'" part. > > Anyhow, before I dove into instrumenting individual elements with > getrusage() calls I thought I'd solicit some advice on whether or not > the idea made any sense. > > cheers, > - Ian > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From ianrose at eecs.harvard.edu Wed Mar 17 21:48:29 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Wed, 17 Mar 2010 21:48:29 -0400 Subject: [Click] profiling / debugging tools or tips? In-Reply-To: References: <4BA16EFA.5020908@eecs.harvard.edu> Message-ID: <4BA1866D.3010502@eecs.harvard.edu> Well now, I'm certainly glad I asked first! I just happened to find my current bug leading to the CPU starvation, but when I get a moment I'm interested to try running my configs with this enabled just to see what the overhead is like. I'm running on some moderately weak hardware (Soekris net4826) so I don't have a lot of spare cycles, but my packet rates are also much less than what many Click users probably deal with so maybe it'll still work... thanks for the pointer! - Ian Cliff Frey wrote: > click already supports exactly what you are talking about! > > if you configure it with > ./configure --enable-stats=2 > > then every element is given a 'cycles' read handler. > > However, using generic profiling tools is likely to also give you > feedback (with much lower overhead). Perhaps take a look at oprofile as > a package for doing this. > > At the other end of the spectrum, you can use callgrind (which is part > of the valgrind package) along with kcachegrind to give you a break down > of the exact number of CPU _instructions_ spent in each of your > elements, along with per task/stack information. That information can > be very colorful and interesting to look at, however it tends not > not-very-closely line up with reality because instruction count is not a > great proxy for wallclock time. Also, running through callgrind with > slow down your application by 50x or so, but it it can still be very > interesting to see. > > Cliff > > On Wed, Mar 17, 2010 at 5:08 PM, Ian Rose > wrote: > > Hello all, > > I need to do some debugging and profiling of my click configuration > which consists of a large number of both standard and custom (i.e. > written by me) elements. Specifically, I would like to get an idea of > the CPU usage of each element, or at least know what the biggest > consumers are. > > Are there any tools within click to help me do this, or does anyone have > any tips on how to go about this? The best idea that I can come up with > is to take a guess at which elements might be the CPU hogs and > instrument them with getrusage() calls at every entrance and exit points > to the element. Unfortunately this is a bit labor-intensive (and a > little error-prone) as there are potentially many such points (e.g. > push(), pull(), run_timer(), run_task()). > > Additionally, the resolution is pretty low (looks like 1ms on my system) > so this *may* result in some inaccuracies. Or may not... perhaps over > time random chance will even things out so that over long enough periods > each element's summed cpu time will be mostly accurate? > > It would be handy to implement this instead in Click's core instead of > in each individual element; you might imagine calling some > initialization methods to tell Click which elements to profile for you. > However I don't think this is possible currently - although Click > should be able to properly track whenever a timer or task fires (and for > which element) I don't think click is able to track when a packet (and > therefore control) is pushed/pulled from one element to another. If I > am wrong about this please correct me. > > Another half-baked idea I had was something similar to how (some) OSes > sample the process scheduler to estimate each process' load average. So > the idea would be to somehow "generate an interrupt" every so often and > check which element was currently "active" at that time. The active > element gets 1 point and each elements "load average" is the fraction of > points that it got over some recent time window. But I don't really > have an idea of how to actualize this in click; I don't really have an > idea of how to do either the "generate an interrupt" part or > (especially) the "figure out which element is 'active'" part. > > Anyhow, before I dove into instrumenting individual elements with > getrusage() calls I thought I'd solicit some advice on whether or not > the idea made any sense. > > cheers, > - Ian > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > From jesse.r.brown at lmco.com Thu Mar 18 09:58:17 2010 From: jesse.r.brown at lmco.com (Jesse Brown) Date: Thu, 18 Mar 2010 09:58:17 -0400 Subject: [Click] vim syntax highlight of click script In-Reply-To: <4BA0F8A0.6080808@cs.ucla.edu> References: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> <4BA0B3F8.3010402@atl.lmco.com> <4BA0F8A0.6080808@cs.ucla.edu> Message-ID: <4BA23179.1070701@atl.lmco.com> Hi Eddie, That would be great! Thanks, Jesse Eddie Kohler wrote: > Neat! Jesse, would you object to this vim script being added to the distribution? > > Thanks, > E > > > Jesse Brown wrote: > >> JaeYong Yoo wrote: >> >>> Hi, >>> >>> is there any vim plugin that highlights according to the syntax of >>> click script? >>> >>> wishes, >>> >>> jaeyong >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >>> >>> >> Hi jaeyong, >> >> In general, the C syntax is pretty close. Based on that I added the >> elements (current as of 1.6.0), support for the '->' and '::' operators >> and the elementclass keyword. >> >> Attached is the syntax file. To use this you would edit your .vimrc to >> include the following lines: >> >> au BufNewFile,BufRead *.click set filetype=click >> au! Syntax click source ~/.vim/syntax/click.vim >> >> And place the attached file in ~/.vim/syntax/click.vim >> >> I understand that this is pretty crude, but it works well for me. >> >> Jesse >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > From lbro at pulz8.com Thu Mar 18 06:46:47 2010 From: lbro at pulz8.com (Lars Bro) Date: Thu, 18 Mar 2010 11:46:47 +0100 Subject: [Click] Weird bridge behavior unpatched 2.6.31.12 In-Reply-To: <4BA0FED6.8040203@cs.ucla.edu> References: <22b0d68b1003170402xf874a06hef36a1c0833984bf@mail.gmail.com> <4BA0FED6.8040203@cs.ucla.edu> Message-ID: <22b0d68b1003180346h72212b38r7200bf8950963dd7@mail.gmail.com> Hi, Eddie FromDevice() has a PROMISC option, sorry. I did not notice that, and I will try it. It was just that "ip link set promisc on..." did not function correctly, FromDevice() only returned some of the packets. I will let you know when I have tested it Btw, It seems to work fine installing and uninstalling Click "on top of" a brctl bridge. so click-uninstall recovers the bridge functionality correctly when click is leaving. I do not use brctl on devices in use by a running Click router. yours, Lars Bro On Wed, Mar 17, 2010 at 5:09 PM, Eddie Kohler wrote: > Lars, > > I strongly recommend against mixing brctl with Click linuxpatchless. Click > REPLACES the bridge hook when it is installed. I have no reason to believe > brctl will work. > > Eddie > > > Lars Bro wrote: > >> Hi, >> >> I have a click configuration where I need make a tap on the traffic >> between >> two hosts. Therefore, I have made a simple >> "Bridge" element class like below: >> /* >> * Bridge between two interfaces and send IP packets to output >> */ >> elementclass Bridge { >> \$if1, \$if2 | >> FromDevice(\$if1) -> >> if1_tee::Tee(); >> FromDevice(\$if2) -> >> if2_tee::Tee(); >> if1_tee\[0\] -> >> Queue() -> >> ToDevice(\$if2); >> if1_tee\[1\] -> >> Strip(14) -> >> output; >> if2_tee\[0\] -> >> Queue() -> >> ToDevice(\$if1); >> if2_tee\[1\] -> >> Strip(14) -> >> output; >> }; >> >> When the test router is not running, I will of course need the bridging >> functionality anyway, so I do >> brctl addbr br0 >> brctl addif br0 xxx >> brctl addif br0 yyy >> ip link set up dev br0 >> >> Before starting the router. I remove the bridge and set the interfaces up >> ip link set down dev br0 >> brctl delbr br0 >> ip link set up dev xxx >> ip link set up dev yyy >> click-install ... >> >> This seems not to work, however. It seems that only broadcast traffic (and >> maybe also traffic directly for the xxx and yyy >> MAC addrees, but I dont know, since I am trying to make a bridge) >> >> If I try with >> ip link set xxx promisc on >> ip link set yyy promisc on >> >> I get "some" data through, still not good enough >> >> But if I start the router without removing the original bridge, it works >> fine as far as I can see. >> >> Is this as it is supposed to be ? >> >> >> yours, >> Lars Bro >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > From kohler at cs.ucla.edu Thu Mar 18 12:37:09 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 18 Mar 2010 09:37:09 -0700 Subject: [Click] vim syntax highlight of click script In-Reply-To: <4BA23179.1070701@atl.lmco.com> References: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDD79@NML2007.netmedia.kjist.ac.kr> <4BA0B3F8.3010402@atl.lmco.com> <4BA0F8A0.6080808@cs.ucla.edu> <4BA23179.1070701@atl.lmco.com> Message-ID: <4BA256B5.6000103@cs.ucla.edu> Great, thanks! It is added. E Jesse Brown wrote: > Hi Eddie, > > That would be great! > > Thanks, > > Jesse > > Eddie Kohler wrote: >> Neat! Jesse, would you object to this vim script being added to the >> distribution? >> >> Thanks, >> E >> >> >> Jesse Brown wrote: >> >>> JaeYong Yoo wrote: >>> >>>> Hi, >>>> >>>> is there any vim plugin that highlights according to the syntax of >>>> click script? >>>> >>>> wishes, >>>> >>>> jaeyong >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>> >>>> >>> Hi jaeyong, >>> >>> In general, the C syntax is pretty close. Based on that I added the >>> elements (current as of 1.6.0), support for the '->' and '::' >>> operators and the elementclass keyword. >>> >>> Attached is the syntax file. To use this you would edit your .vimrc >>> to include the following lines: >>> >>> au BufNewFile,BufRead *.click set filetype=click >>> au! Syntax click source ~/.vim/syntax/click.vim >>> >>> And place the attached file in ~/.vim/syntax/click.vim >>> >>> I understand that this is pretty crude, but it works well for me. >>> >>> Jesse >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> > > From ianrose at eecs.harvard.edu Thu Mar 18 23:06:17 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Thu, 18 Mar 2010 23:06:17 -0400 Subject: [Click] _iters_per_os in routerthread Message-ID: <4BA2EA29.7010105@eecs.harvard.edu> Hi all - In lib/routerthread.cc there is the following code: #if CLICK_USERLEVEL _iters_per_os = 64; /* iterations per select() */ #else _iters_per_os = 2; /* iterations per OS schedule() */ #endif I'm curious if there is a particular rationale behind the value 64 for userlevel click. Is it simply the case that this value works pretty well for most of the typical click configurations that were tested? In my (admittedly brief) testing, it appears that this parameter choice imposes a CPU overhead of ~3x for [some?] select-heavy applications, by which I mean configs that spend most of their time calling selected() on elements, rather executing tasks or timers. For example, my particular app uses around 15-20% CPU with the above values, but if I change the 64 to a 2, the CPU usage drops to 5-6%. Obviously this might simply be a case of the default parameters not being particularly good for my specific situation, but I thought I'd check since the performance difference seemed pretty significant. cheers, - Ian From kohler at cs.ucla.edu Fri Mar 19 13:05:12 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 19 Mar 2010 10:05:12 -0700 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <4BA2EA29.7010105@eecs.harvard.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> Message-ID: <4BA3AEC8.1060105@cs.ucla.edu> Hi Ian, (1) I would completely appreciate seeing your config, just to see if there's anything that might cause the extra CPU usage. BUT: (2) _iters_per_os is set that way just, I think, as a random guess. ANd that guess is at least 5 years old and probably more. I think it would be OK to set it to 2 for everyone. Eddie On 3/18/10 8:06 PM, Ian Rose wrote: > Hi all - > > In lib/routerthread.cc there is the following code: > > #if CLICK_USERLEVEL > _iters_per_os = 64; /* iterations per select() */ > #else > _iters_per_os = 2; /* iterations per OS schedule() */ > #endif > > I'm curious if there is a particular rationale behind the value 64 for > userlevel click. Is it simply the case that this value works pretty > well for most of the typical click configurations that were tested? In > my (admittedly brief) testing, it appears that this parameter choice > imposes a CPU overhead of ~3x for [some?] select-heavy applications, by > which I mean configs that spend most of their time calling selected() on > elements, rather executing tasks or timers. For example, my particular > app uses around 15-20% CPU with the above values, but if I change the 64 > to a 2, the CPU usage drops to 5-6%. > > Obviously this might simply be a case of the default parameters not > being particularly good for my specific situation, but I thought I'd > check since the performance difference seemed pretty significant. > > cheers, > - Ian > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Fri Mar 19 13:45:47 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Fri, 19 Mar 2010 13:45:47 -0400 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <4BA3AEC8.1060105@cs.ucla.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> <4BA3AEC8.1060105@cs.ucla.edu> Message-ID: <4BA3B84B.5050807@eecs.harvard.edu> Hi Eddie, I'd be more than glad to send along my "real" config, but its really big and uses quite a lot of custom elements that won't mean anything to you without the source code. However, just for testing these changes I used: FromDevice(ath1, ENCAP 802_11_RADIO, PROMISC true, HEADROOM 196) -> Discard; I am seeing about a 2x CPU usage difference when I use _iters_per_os = 2 vs 64. - Ian Eddie Kohler wrote: > Hi Ian, > > (1) I would completely appreciate seeing your config, just to see if > there's anything that might cause the extra CPU usage. BUT: > > (2) _iters_per_os is set that way just, I think, as a random guess. ANd > that guess is at least 5 years old and probably more. I think it would > be OK to set it to 2 for everyone. > > Eddie > > > On 3/18/10 8:06 PM, Ian Rose wrote: >> Hi all - >> >> In lib/routerthread.cc there is the following code: >> >> #if CLICK_USERLEVEL >> _iters_per_os = 64; /* iterations per select() */ >> #else >> _iters_per_os = 2; /* iterations per OS schedule() */ >> #endif >> >> I'm curious if there is a particular rationale behind the value 64 for >> userlevel click. Is it simply the case that this value works pretty >> well for most of the typical click configurations that were tested? In >> my (admittedly brief) testing, it appears that this parameter choice >> imposes a CPU overhead of ~3x for [some?] select-heavy applications, by >> which I mean configs that spend most of their time calling selected() on >> elements, rather executing tasks or timers. For example, my particular >> app uses around 15-20% CPU with the above values, but if I change the 64 >> to a 2, the CPU usage drops to 5-6%. >> >> Obviously this might simply be a case of the default parameters not >> being particularly good for my specific situation, but I thought I'd >> check since the performance difference seemed pretty significant. >> >> cheers, >> - Ian >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Fri Mar 19 13:49:47 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 19 Mar 2010 10:49:47 -0700 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <4BA3B84B.5050807@eecs.harvard.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> <4BA3AEC8.1060105@cs.ucla.edu> <4BA3B84B.5050807@eecs.harvard.edu> Message-ID: <4BA3B93B.4060809@cs.ucla.edu> Ian, What OS is this running on? Are you using pcap? Eddie On 3/19/10 10:45 AM, Ian Rose wrote: > Hi Eddie, > > I'd be more than glad to send along my "real" config, but its really big > and uses quite a lot of custom elements that won't mean anything to you > without the source code. > > However, just for testing these changes I used: > > FromDevice(ath1, ENCAP 802_11_RADIO, PROMISC true, HEADROOM 196) -> > Discard; > > I am seeing about a 2x CPU usage difference when I use _iters_per_os = 2 > vs 64. > > - Ian > > > Eddie Kohler wrote: >> Hi Ian, >> >> (1) I would completely appreciate seeing your config, just to see if >> there's anything that might cause the extra CPU usage. BUT: >> >> (2) _iters_per_os is set that way just, I think, as a random guess. >> ANd that guess is at least 5 years old and probably more. I think it >> would be OK to set it to 2 for everyone. >> >> Eddie >> >> >> On 3/18/10 8:06 PM, Ian Rose wrote: >>> Hi all - >>> >>> In lib/routerthread.cc there is the following code: >>> >>> #if CLICK_USERLEVEL >>> _iters_per_os = 64; /* iterations per select() */ >>> #else >>> _iters_per_os = 2; /* iterations per OS schedule() */ >>> #endif >>> >>> I'm curious if there is a particular rationale behind the value 64 for >>> userlevel click. Is it simply the case that this value works pretty >>> well for most of the typical click configurations that were tested? In >>> my (admittedly brief) testing, it appears that this parameter choice >>> imposes a CPU overhead of ~3x for [some?] select-heavy applications, by >>> which I mean configs that spend most of their time calling selected() on >>> elements, rather executing tasks or timers. For example, my particular >>> app uses around 15-20% CPU with the above values, but if I change the 64 >>> to a 2, the CPU usage drops to 5-6%. >>> >>> Obviously this might simply be a case of the default parameters not >>> being particularly good for my specific situation, but I thought I'd >>> check since the performance difference seemed pretty significant. >>> >>> cheers, >>> - Ian >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Fri Mar 19 13:53:38 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Fri, 19 Mar 2010 13:53:38 -0400 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <4BA3B93B.4060809@cs.ucla.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> <4BA3AEC8.1060105@cs.ucla.edu> <4BA3B84B.5050807@eecs.harvard.edu> <4BA3B93B.4060809@cs.ucla.edu> Message-ID: <4BA3BA22.5090809@eecs.harvard.edu> Sorry yeah should have specified that - I forgot that FromDevice is different on Linux. I am on FreeBSD 7.2-STABLE. Also, I am using Click v1.7.0rc1, but I compared FromDevice.u and the relevant portions of routerthread.cc to HEAD and didn't see anything different. - Ian Eddie Kohler wrote: > Ian, > > What OS is this running on? Are you using pcap? > > Eddie > > > On 3/19/10 10:45 AM, Ian Rose wrote: >> Hi Eddie, >> >> I'd be more than glad to send along my "real" config, but its really big >> and uses quite a lot of custom elements that won't mean anything to you >> without the source code. >> >> However, just for testing these changes I used: >> >> FromDevice(ath1, ENCAP 802_11_RADIO, PROMISC true, HEADROOM 196) -> >> Discard; >> >> I am seeing about a 2x CPU usage difference when I use _iters_per_os = 2 >> vs 64. >> >> - Ian >> >> >> Eddie Kohler wrote: >>> Hi Ian, >>> >>> (1) I would completely appreciate seeing your config, just to see if >>> there's anything that might cause the extra CPU usage. BUT: >>> >>> (2) _iters_per_os is set that way just, I think, as a random guess. >>> ANd that guess is at least 5 years old and probably more. I think it >>> would be OK to set it to 2 for everyone. >>> >>> Eddie >>> >>> >>> On 3/18/10 8:06 PM, Ian Rose wrote: >>>> Hi all - >>>> >>>> In lib/routerthread.cc there is the following code: >>>> >>>> #if CLICK_USERLEVEL >>>> _iters_per_os = 64; /* iterations per select() */ >>>> #else >>>> _iters_per_os = 2; /* iterations per OS schedule() */ >>>> #endif >>>> >>>> I'm curious if there is a particular rationale behind the value 64 for >>>> userlevel click. Is it simply the case that this value works pretty >>>> well for most of the typical click configurations that were tested? In >>>> my (admittedly brief) testing, it appears that this parameter choice >>>> imposes a CPU overhead of ~3x for [some?] select-heavy applications, by >>>> which I mean configs that spend most of their time calling >>>> selected() on >>>> elements, rather executing tasks or timers. For example, my particular >>>> app uses around 15-20% CPU with the above values, but if I change >>>> the 64 >>>> to a 2, the CPU usage drops to 5-6%. >>>> >>>> Obviously this might simply be a case of the default parameters not >>>> being particularly good for my specific situation, but I thought I'd >>>> check since the performance difference seemed pretty significant. >>>> >>>> cheers, >>>> - Ian >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Fri Mar 19 14:31:23 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 19 Mar 2010 11:31:23 -0700 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <4BA3BA22.5090809@eecs.harvard.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> <4BA3AEC8.1060105@cs.ucla.edu> <4BA3B84B.5050807@eecs.harvard.edu> <4BA3B93B.4060809@cs.ucla.edu> <4BA3BA22.5090809@eecs.harvard.edu> Message-ID: <4BA3C2FB.1080202@cs.ucla.edu> Ian, That is quite weird. Here's how pcap dispatching is supposed to work. - When the fd is selected, pcap_dispatch() is called. - pcap_dispatch() calls a FromDevice callback function, which actually emits the packets. - pcap_dispatch() returns an integer that says exactly how many packets were emitted. - If that integer is > 0, FromDevice schedules a task. - The task goes through the same steps, *only rescheduling itself when there is more work to do*. So I really don't see why the setting of _iters_per_os would matter here. Do you have any idea what is taking up the CPU -- maybe calls to Timestamp::now()? Is pcap_dispatch() returning nonzero even if no packets were emitted? E On 3/19/10 10:53 AM, Ian Rose wrote: > Sorry yeah should have specified that - I forgot that FromDevice is > different on Linux. > > I am on FreeBSD 7.2-STABLE. > > Also, I am using Click v1.7.0rc1, but I compared FromDevice.u and the > relevant portions of routerthread.cc to HEAD and didn't see anything > different. > > - Ian > > Eddie Kohler wrote: >> Ian, >> >> What OS is this running on? Are you using pcap? >> >> Eddie >> >> >> On 3/19/10 10:45 AM, Ian Rose wrote: >>> Hi Eddie, >>> >>> I'd be more than glad to send along my "real" config, but its really big >>> and uses quite a lot of custom elements that won't mean anything to you >>> without the source code. >>> >>> However, just for testing these changes I used: >>> >>> FromDevice(ath1, ENCAP 802_11_RADIO, PROMISC true, HEADROOM 196) -> >>> Discard; >>> >>> I am seeing about a 2x CPU usage difference when I use _iters_per_os = 2 >>> vs 64. >>> >>> - Ian >>> >>> >>> Eddie Kohler wrote: >>>> Hi Ian, >>>> >>>> (1) I would completely appreciate seeing your config, just to see if >>>> there's anything that might cause the extra CPU usage. BUT: >>>> >>>> (2) _iters_per_os is set that way just, I think, as a random guess. >>>> ANd that guess is at least 5 years old and probably more. I think it >>>> would be OK to set it to 2 for everyone. >>>> >>>> Eddie >>>> >>>> >>>> On 3/18/10 8:06 PM, Ian Rose wrote: >>>>> Hi all - >>>>> >>>>> In lib/routerthread.cc there is the following code: >>>>> >>>>> #if CLICK_USERLEVEL >>>>> _iters_per_os = 64; /* iterations per select() */ >>>>> #else >>>>> _iters_per_os = 2; /* iterations per OS schedule() */ >>>>> #endif >>>>> >>>>> I'm curious if there is a particular rationale behind the value 64 for >>>>> userlevel click. Is it simply the case that this value works pretty >>>>> well for most of the typical click configurations that were tested? In >>>>> my (admittedly brief) testing, it appears that this parameter choice >>>>> imposes a CPU overhead of ~3x for [some?] select-heavy >>>>> applications, by >>>>> which I mean configs that spend most of their time calling >>>>> selected() on >>>>> elements, rather executing tasks or timers. For example, my particular >>>>> app uses around 15-20% CPU with the above values, but if I change >>>>> the 64 >>>>> to a 2, the CPU usage drops to 5-6%. >>>>> >>>>> Obviously this might simply be a case of the default parameters not >>>>> being particularly good for my specific situation, but I thought I'd >>>>> check since the performance difference seemed pretty significant. >>>>> >>>>> cheers, >>>>> - Ian >>>>> _______________________________________________ >>>>> click mailing list >>>>> click at amsterdam.lcs.mit.edu >>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From hall.692 at osu.edu Mon Mar 22 11:28:47 2010 From: hall.692 at osu.edu (Seth Hall) Date: Mon, 22 Mar 2010 11:28:47 -0400 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <4BA3C2FB.1080202@cs.ucla.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> <4BA3AEC8.1060105@cs.ucla.edu> <4BA3B84B.5050807@eecs.harvard.edu> <4BA3B93B.4060809@cs.ucla.edu> <4BA3BA22.5090809@eecs.harvard.edu> <4BA3C2FB.1080202@cs.ucla.edu> Message-ID: <00A89CC8-ABF7-4E1E-A929-5FEA4FF09C2A@osu.edu> On Mar 19, 2010, at 2:31 PM, Eddie Kohler wrote: > That is quite weird. Here's how pcap dispatching is supposed to work. > > - When the fd is selected, pcap_dispatch() is called. There is a bug with nonblocking libpcap in released versions of FreeBSD. That could be a contributing factor. http://www.freebsd.org/cgi/query-pr.cgi?pr=143855&cat= .Seth --- Seth Hall Network Security - Office of the CIO The Ohio State University Phone: 614-292-9721 From ianrose at eecs.harvard.edu Mon Mar 22 11:48:38 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Mon, 22 Mar 2010 11:48:38 -0400 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <00A89CC8-ABF7-4E1E-A929-5FEA4FF09C2A@osu.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> <4BA3AEC8.1060105@cs.ucla.edu> <4BA3B84B.5050807@eecs.harvard.edu> <4BA3B93B.4060809@cs.ucla.edu> <4BA3BA22.5090809@eecs.harvard.edu> <4BA3C2FB.1080202@cs.ucla.edu> <00A89CC8-ABF7-4E1E-A929-5FEA4FF09C2A@osu.edu> Message-ID: <4BA79156.9060804@eecs.harvard.edu> Hi Seth, Although that's certainly useful for me to know in general (thanks for the pointer!), I don't think it applies in this case because FromDevice always enables IMMMEDIATE mode and as I understand that bug report it only applies when bpf is *not* in IMMEDIATE mode. - Ian Seth Hall wrote: > > On Mar 19, 2010, at 2:31 PM, Eddie Kohler wrote: > >> That is quite weird. Here's how pcap dispatching is supposed to work. >> >> - When the fd is selected, pcap_dispatch() is called. > > > There is a bug with nonblocking libpcap in released versions of > FreeBSD. That could be a contributing factor. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=143855&cat= > > .Seth > > --- > Seth Hall > Network Security - Office of the CIO > The Ohio State University > Phone: 614-292-9721 From ianrose at eecs.harvard.edu Mon Mar 22 11:50:41 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Mon, 22 Mar 2010 11:50:41 -0400 Subject: [Click] _iters_per_os in routerthread In-Reply-To: <4BA3C2FB.1080202@cs.ucla.edu> References: <4BA2EA29.7010105@eecs.harvard.edu> <4BA3AEC8.1060105@cs.ucla.edu> <4BA3B84B.5050807@eecs.harvard.edu> <4BA3B93B.4060809@cs.ucla.edu> <4BA3BA22.5090809@eecs.harvard.edu> <4BA3C2FB.1080202@cs.ucla.edu> Message-ID: <4BA791D1.4060308@eecs.harvard.edu> Hi Eddie, I've been a bit bogged down with other work but plan to look into this a bit more and respond to your email in more depth as soon as I can. Superficially, at least, it seems to me that the difference between _iters_per_os = 2 and 64 is that in the '2' case, work is being done on (approx) every other iteration through the driver_loop in routerthread. By "work" I mean "kevent() is called, then selected() is called on the FromDevice element, which calls pcap_dispatch() with cnt=1, etc.". In the case where _iters_per_os=64, this work is only being done every 1/64 loops. So the question is whether enough bookkeeping-type stuff occurs in every single loop iteration (e.g. checking for signals, pending tasks, timer, calculating scheduling, etc.) for it to make sense that these "idle" iterations could account for the added CPU usage. I don't yet have a deep enough understanding of all of these bookkeeping items to say whether or not that explanation seems plausible to me. - Ian Eddie Kohler wrote: > Ian, > > That is quite weird. Here's how pcap dispatching is supposed to work. > > - When the fd is selected, pcap_dispatch() is called. > - pcap_dispatch() calls a FromDevice callback function, which actually > emits the packets. > - pcap_dispatch() returns an integer that says exactly how many packets > were emitted. > - If that integer is > 0, FromDevice schedules a task. > - The task goes through the same steps, *only rescheduling itself when > there is more work to do*. > > So I really don't see why the setting of _iters_per_os would matter > here. Do you have any idea what is taking up the CPU -- maybe calls to > Timestamp::now()? Is pcap_dispatch() returning nonzero even if no > packets were emitted? > > E > > > On 3/19/10 10:53 AM, Ian Rose wrote: >> Sorry yeah should have specified that - I forgot that FromDevice is >> different on Linux. >> >> I am on FreeBSD 7.2-STABLE. >> >> Also, I am using Click v1.7.0rc1, but I compared FromDevice.u and the >> relevant portions of routerthread.cc to HEAD and didn't see anything >> different. >> >> - Ian >> >> Eddie Kohler wrote: >>> Ian, >>> >>> What OS is this running on? Are you using pcap? >>> >>> Eddie >>> >>> >>> On 3/19/10 10:45 AM, Ian Rose wrote: >>>> Hi Eddie, >>>> >>>> I'd be more than glad to send along my "real" config, but its really >>>> big >>>> and uses quite a lot of custom elements that won't mean anything to you >>>> without the source code. >>>> >>>> However, just for testing these changes I used: >>>> >>>> FromDevice(ath1, ENCAP 802_11_RADIO, PROMISC true, HEADROOM 196) -> >>>> Discard; >>>> >>>> I am seeing about a 2x CPU usage difference when I use _iters_per_os >>>> = 2 >>>> vs 64. >>>> >>>> - Ian >>>> >>>> >>>> Eddie Kohler wrote: >>>>> Hi Ian, >>>>> >>>>> (1) I would completely appreciate seeing your config, just to see if >>>>> there's anything that might cause the extra CPU usage. BUT: >>>>> >>>>> (2) _iters_per_os is set that way just, I think, as a random guess. >>>>> ANd that guess is at least 5 years old and probably more. I think it >>>>> would be OK to set it to 2 for everyone. >>>>> >>>>> Eddie >>>>> >>>>> >>>>> On 3/18/10 8:06 PM, Ian Rose wrote: >>>>>> Hi all - >>>>>> >>>>>> In lib/routerthread.cc there is the following code: >>>>>> >>>>>> #if CLICK_USERLEVEL >>>>>> _iters_per_os = 64; /* iterations per select() */ >>>>>> #else >>>>>> _iters_per_os = 2; /* iterations per OS schedule() */ >>>>>> #endif >>>>>> >>>>>> I'm curious if there is a particular rationale behind the value 64 >>>>>> for >>>>>> userlevel click. Is it simply the case that this value works pretty >>>>>> well for most of the typical click configurations that were >>>>>> tested? In >>>>>> my (admittedly brief) testing, it appears that this parameter choice >>>>>> imposes a CPU overhead of ~3x for [some?] select-heavy >>>>>> applications, by >>>>>> which I mean configs that spend most of their time calling >>>>>> selected() on >>>>>> elements, rather executing tasks or timers. For example, my >>>>>> particular >>>>>> app uses around 15-20% CPU with the above values, but if I change >>>>>> the 64 >>>>>> to a 2, the CPU usage drops to 5-6%. >>>>>> >>>>>> Obviously this might simply be a case of the default parameters not >>>>>> being particularly good for my specific situation, but I thought I'd >>>>>> check since the performance difference seemed pretty significant. >>>>>> >>>>>> cheers, >>>>>> - Ian >>>>>> _______________________________________________ >>>>>> click mailing list >>>>>> click at amsterdam.lcs.mit.edu >>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From ianrose at eecs.harvard.edu Mon Mar 22 16:06:35 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Mon, 22 Mar 2010 16:06:35 -0400 Subject: [Click] RandomSource patch Message-ID: <4BA7CDCB.5060404@eecs.harvard.edu> Howdy - Attached is a candidate patch to update RandomSource include all of the nice bells and whistles that InfiniteSource already has (e.g. LIMITs, a settable ACTIVE parameter, etc). I did this by changing RandomSource to inherit from InfiniteSource, overriding the parts that need to be different. I tried to keep things as consistent as possible between the two elements since they are nearly identical in intended functionality with the exception of how packets are created. - Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: randomsource.cc.patch Type: text/x-diff Size: 4252 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100322/3b54dde9/attachment.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: randomsource.hh.patch Type: text/x-diff Size: 2943 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100322/3b54dde9/attachment-0001.patch From fanyang.scu at gmail.com Mon Mar 22 23:36:52 2010 From: fanyang.scu at gmail.com (Jimmy) Date: Mon, 22 Mar 2010 23:36:52 -0400 Subject: [Click] generate random interval source packets Message-ID: <2fe59bbc1003222036s277bcfbdvff606cf0621748e1@mail.gmail.com> Hi all, I have checked randomsource element, which can generate random length packets. So what is the interval if using this element. In this code, click_random() is used to generate a random number, which document includes this function? I am considering generate packets whose time interval is random. I checked timedsource element's original codes, it seems very hard to change since the _interval is specified by INTERVAL. Can anybody give me some clue on how to implement random interval source? Also, I include math.h in the element codes. It has some problems when compiling, so how to fix this? Thanks. -- Best Regards, Jimmy From ianrose at eecs.harvard.edu Tue Mar 23 08:22:13 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Tue, 23 Mar 2010 08:22:13 -0400 Subject: [Click] generate random interval source packets In-Reply-To: <2fe59bbc1003222036s277bcfbdvff606cf0621748e1@mail.gmail.com> References: <2fe59bbc1003222036s277bcfbdvff606cf0621748e1@mail.gmail.com> Message-ID: <4BA8B275.20703@eecs.harvard.edu> click_random is defined in glue.hh (which is where most of the click_xxx utility-type methods are found). As far as your app requirements go, I don't see any existing elements that do exactly what you want, but you could maybe create the general behavior with a combination of TimedSource and RandomSample? It would be a little inefficient (since many of the packets that TimedSource creates would just be immediately destroyed by RandomSample) but as long as your data rates are not too high this probably wouldn't be a big problem. Is click cannot find math.h then that header file is not in the default search path for include files. When you run configure to initially set up click you can tell it about additional directories to search in. For example, when I configure click I include the following argument: > CXXFLAGS="-I/usr/local/include -I$(HOME)/include" This ensures that each time I compile click it also looks for header files in /usr/local/include/ and $(HOME)/include/. - Ian Jimmy wrote: > Hi all, > > I have checked randomsource element, which can generate random length > packets. So what is the interval if using this element. In this code, > click_random() is used to generate a random number, which document > includes this function? > > I am considering generate packets whose time interval is random. I > checked timedsource element's original codes, it seems very hard to > change since the _interval is specified by INTERVAL. > > Can anybody give me some clue on how to implement random interval source? > > Also, I include math.h in the element codes. It has some problems when > compiling, so how to fix this? > > Thanks. > From lbro at pulz8.com Wed Mar 24 10:16:13 2010 From: lbro at pulz8.com (Lars Bro) Date: Wed, 24 Mar 2010 15:16:13 +0100 Subject: [Click] redirecting stderr Message-ID: <22b0d68b1003240716i5ec6f08ena15cf6487570fc7e@mail.gmail.com> Hi, It seems that when I do click-install -u router.click 2>/tmp/logfile then, the system hangs completely But if I just do click-install -u router.click it works as expected yours, Lars Bro From kohler at cs.ucla.edu Wed Mar 24 12:00:46 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 24 Mar 2010 09:00:46 -0700 Subject: [Click] RandomSource patch In-Reply-To: <4BA7CDCB.5060404@eecs.harvard.edu> References: <4BA7CDCB.5060404@eecs.harvard.edu> Message-ID: <4BAA372E.5060304@cs.ucla.edu> Ian, Excellent! Thanks, this is applied. It might be interesting long term to create a common ancestor or something -- although it would be a microscopic shame to slow down InfiniteSource itself, which is often used for performance tests. Eddie Ian Rose wrote: > Howdy - > > Attached is a candidate patch to update RandomSource include all of the > nice bells and whistles that InfiniteSource already has (e.g. LIMITs, a > settable ACTIVE parameter, etc). I did this by changing RandomSource to > inherit from InfiniteSource, overriding the parts that need to be > different. I tried to keep things as consistent as possible between the > two elements since they are nearly identical in intended functionality > with the exception of how packets are created. > > - Ian > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Mar 24 12:36:46 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 24 Mar 2010 09:36:46 -0700 Subject: [Click] generate random interval source packets In-Reply-To: <4BA8B275.20703@eecs.harvard.edu> References: <2fe59bbc1003222036s277bcfbdvff606cf0621748e1@mail.gmail.com> <4BA8B275.20703@eecs.harvard.edu> Message-ID: <4BAA3F9E.9020403@cs.ucla.edu> Hey, I agree with everything that Ian said, with one exception. If you are compiling code for the user-level driver, should work just fine with no extra FLAGS settings. But if you are compiling code destined for the kernel, WILL NEVER WORK. Functions from are simply not available in the kernel. Eddie Ian Rose wrote: > click_random is defined in glue.hh (which is where most of the click_xxx > utility-type methods are found). > > As far as your app requirements go, I don't see any existing elements > that do exactly what you want, but you could maybe create the general > behavior with a combination of TimedSource and RandomSample? It would > be a little inefficient (since many of the packets that TimedSource > creates would just be immediately destroyed by RandomSample) but as long > as your data rates are not too high this probably wouldn't be a big problem. > > Is click cannot find math.h then that header file is not in the default > search path for include files. When you run configure to initially set > up click you can tell it about additional directories to search in. For > example, when I configure click I include the following argument: >> CXXFLAGS="-I/usr/local/include -I$(HOME)/include" > > This ensures that each time I compile click it also looks for header > files in /usr/local/include/ and $(HOME)/include/. > > - Ian > > > Jimmy wrote: >> Hi all, >> >> I have checked randomsource element, which can generate random length >> packets. So what is the interval if using this element. In this code, >> click_random() is used to generate a random number, which document >> includes this function? >> >> I am considering generate packets whose time interval is random. I >> checked timedsource element's original codes, it seems very hard to >> change since the _interval is specified by INTERVAL. >> >> Can anybody give me some clue on how to implement random interval source? >> >> Also, I include math.h in the element codes. It has some problems when >> compiling, so how to fix this? >> >> Thanks. >> > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From fanyang.scu at gmail.com Wed Mar 24 19:40:18 2010 From: fanyang.scu at gmail.com (Jimmy) Date: Wed, 24 Mar 2010 19:40:18 -0400 Subject: [Click] generate random interval source packets In-Reply-To: <4BAA3F9E.9020403@cs.ucla.edu> References: <2fe59bbc1003222036s277bcfbdvff606cf0621748e1@mail.gmail.com> <4BA8B275.20703@eecs.harvard.edu> <4BAA3F9E.9020403@cs.ucla.edu> Message-ID: <2fe59bbc1003241640u5d526aa1h272f3f4acda18c6d@mail.gmail.com> Thanks Ian and Eddie, I have already solved the problem and now I am able to create a source element which can send packets based on exponential random time interval. J. On Wed, Mar 24, 2010 at 12:36 PM, Eddie Kohler wrote: > Hey, > > I agree with everything that Ian said, with one exception. ?If you are > compiling code for the user-level driver, should work just fine > with no extra FLAGS settings. ?But if you are compiling code destined for > the kernel, WILL NEVER WORK. ?Functions from are simply > not available in the kernel. > > Eddie > > > Ian Rose wrote: >> >> click_random is defined in glue.hh (which is where most of the click_xxx >> utility-type methods are found). >> >> As far as your app requirements go, I don't see any existing elements that >> do exactly what you want, but you could maybe create the general behavior >> with a combination of TimedSource and RandomSample? ?It would be a little >> inefficient (since many of the packets that TimedSource creates would just >> be immediately destroyed by RandomSample) but as long as your data rates are >> not too high this probably wouldn't be a big problem. >> >> Is click cannot find math.h then that header file is not in the default >> search path for include files. ?When you run configure to initially set up >> click you can tell it about additional directories to search in. ?For >> example, when I configure click I include the following argument: >>> >>> CXXFLAGS="-I/usr/local/include -I$(HOME)/include" >> >> This ensures that each time I compile click it also looks for header files >> in /usr/local/include/ and $(HOME)/include/. >> >> - Ian >> >> >> Jimmy wrote: >>> >>> Hi all, >>> >>> I have checked randomsource element, which can generate random length >>> packets. So what is the interval if using this element. In this code, >>> click_random() is used to generate a random number, which document >>> includes this function? >>> >>> I am considering generate packets whose time interval is random. I >>> checked timedsource element's original codes, it seems very hard to >>> change since the _interval is specified by INTERVAL. >>> >>> Can anybody give me some clue on how to implement random interval source? >>> >>> Also, I include math.h in the element codes. It has some problems when >>> compiling, so how to fix this? >>> >>> Thanks. >>> >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > -- Best Regards, Jimmy From ravula at iitg.ernet.in Fri Mar 26 08:37:35 2010 From: ravula at iitg.ernet.in (ravula at iitg.ernet.in) Date: Fri, 26 Mar 2010 18:07:35 +0530 (IST) Subject: [Click] Regarding Click Message-ID: <38469.172.16.25.193.1269607055.squirrel@202.141.80.21> Respected Professor, I am a student of Indian Institute of Technology, Guwahati. I am currently into my final year of my undergraduate program in Computer Science and Engineering. And my Bachelors Project is "Implementation of a M-OLSR protocol for Wireless Mesh Networks using Click Modular Router". M-OLSR is an OLSR equivalent for wireless mesh networks. I came across the OLSR support at github -PATS research group. I am currently willing to check out the working of OLSR for MANETS by installing and using nsclick. But, I don't find much nsclick support online. I could find the click configuration script and related code at github, but I did not find any corresponding tcl script so that I could run it on nsclick and check the working of the protocol. I plan to observe the code and then modify it according to my protocol. Is it possible to run the OLSR using nsclick? Could you please tell if there is a tcl script so that I could run OLSR in nsclick? In case it is not there, could you please tell me how easy/difficult would it be to write the tcl script? I would be really glad if you could help me on this. I am really sorry for the long mail, but I really need this help as it would assist me to a great extent in implementing my protocol. Thanks and Regards, Anirudh Ravula From lbro at pulz8.com Wed Mar 24 18:23:59 2010 From: lbro at pulz8.com (Lars Bro) Date: Wed, 24 Mar 2010 23:23:59 +0100 Subject: [Click] Click unpatched problems Message-ID: <22b0d68b1003241523g3b81f80ft113cfe31c2365cad@mail.gmail.com> Hi, List I have a few problems running Click on an unpatched kernel. (the latest from git today) 1) Broadcom devices (bnx) dont seem to work. A simple script (bnx.click) generates an error in the kernel. I attach the error and dmesg. 2) It seems that sometimes, click-install hangs the system. This has nothing to do with redirecting stderr as I have reported before, but since the system hangs completely, I cannot tell what goes on. I attach the click file (for what it is worth, I guess that it is fairly uninteresting) but a small two-lines script will not provoke the error. I use igb devices, and the router does its job correctly when the system is not hung. I do not use bridging. I enclose "ip link show" and "lsmod" output. The router runs OK in user mode (ToHost exchanged with Socket). Sometimes, I can do click-install and click-uninstall one to two times before it happens, other times, it hangs first tim I install the router. It does not seem to help setting all devices down, then up, and it does not seem to help loading another click configuration inbetween. Thanks a lot. -------------- next part -------------- Module Size Used by nls_utf8 1536 1 nls_cp437 5336 1 vfat 9072 1 fat 43784 1 vfat usb_storage 49008 1 ppdev 5816 0 parport_pc 22620 0 lp 8064 0 parport 31280 3 ppdev,parport_pc,lp ipv6 223272 32 powernow_k8 11920 0 cpufreq_conservative 6444 0 cpufreq_stats 3684 0 cpufreq_userspace 2692 0 cpufreq_powersave 1308 0 cpufreq_ondemand 6260 8 freq_table 4052 3 powernow_k8,cpufreq_stats,cpufreq_ondemand loop 13512 0 dcdbas 6684 0 psmouse 38044 0 pcspkr 2204 0 serio_raw 4772 0 evdev 8308 2 button 5148 0 shpchp 27160 0 processor 34804 1 powernow_k8 pci_hotplug 24444 1 shpchp i2c_nforce2 6180 0 i2c_core 20104 1 i2c_nforce2 ext3 107544 1 jbd 41584 1 ext3 mbcache 7008 1 ext3 sd_mod 24948 4 usbhid 32948 0 hid 57496 1 usbhid sg 25040 0 sr_mod 13392 0 cdrom 30332 1 sr_mod sata_nv 19924 0 igb 74560 0 ata_generic 4364 0 dca 5820 1 igb libata 152256 2 sata_nv,ata_generic ide_pci_generic 3652 0 e1000e 105968 0 ide_core 89120 1 ide_pci_generic mptsas 34652 2 mptscsih 21332 1 mptsas bnx2 57732 0 mptbase 58472 2 mptsas,mptscsih scsi_transport_sas 24488 1 mptsas ohci_hcd 20000 0 ehci_hcd 31008 0 scsi_mod 137096 8 usb_storage,sd_mod,sg,sr_mod,libata,mptsas,mptscsih,scsi_transport_sas usbcore 128200 5 usb_storage,usbhid,ohci_hcd,ehci_hcd nls_base 6784 5 nls_utf8,nls_cp437,vfat,fat,usbcore thermal 12692 0 fan 4064 0 thermal_sys 12280 3 processor,thermal,fan -------------- next part -------------- A non-text attachment was scrubbed... Name: bnx.click Type: application/octet-stream Size: 103 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100324/f6a86110/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: error_and_dmesg Type: application/octet-stream Size: 81560 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100324/f6a86110/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: user_router_sample.ck Type: application/octet-stream Size: 21513 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100324/f6a86110/attachment-0005.obj -------------- next part -------------- 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: bnx2_0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:22:19:d2:34:f3 brd ff:ff:ff:ff:ff:ff 3: bnx2_1: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:22:19:d2:34:f5 brd ff:ff:ff:ff:ff:ff 4: bnx2_2: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:22:19:d2:3e:0a brd ff:ff:ff:ff:ff:ff 5: bnx2_3: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:22:19:d2:3e:0c brd ff:ff:ff:ff:ff:ff 6: e1000e_0: mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:15:17:97:e9:ab brd ff:ff:ff:ff:ff:ff 7: igb_0: mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:1b:21:58:88:28 brd ff:ff:ff:ff:ff:ff 8: e1000e_1: mtu 1500 qdisc pfifo_fast state UP qlen 10 link/ether 00:15:17:97:ea:7a brd ff:ff:ff:ff:ff:ff 9: igb_1: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:1b:21:58:88:29 brd ff:ff:ff:ff:ff:ff 10: igb_2: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:1b:21:58:88:2c brd ff:ff:ff:ff:ff:ff 11: igb_3: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:1b:21:58:88:2d brd ff:ff:ff:ff:ff:ff 12: igb_4: mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:1b:21:58:88:90 brd ff:ff:ff:ff:ff:ff 13: igb_5: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:1b:21:58:88:91 brd ff:ff:ff:ff:ff:ff 14: igb_6: mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:1b:21:58:88:94 brd ff:ff:ff:ff:ff:ff 15: igb_7: mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:1b:21:58:88:95 brd ff:ff:ff:ff:ff:ff From jing-yuan at northwestern.edu Fri Mar 26 14:17:33 2010 From: jing-yuan at northwestern.edu (=?utf-8?B?SmluZyBZdWFu?=) Date: Fri, 26 Mar 2010 13:17:33 -0500 Subject: [Click] =?utf-8?q?Question_about_Ethernet_Switch_Configuration?= References: <201001172304489214300@northwestern.edu>, <201001181709317811875@northwestern.edu> Message-ID: <201003261317321406534@northwestern.edu> Hi Eddie Thank you very much for your help. It is very useful for me. But I still have some questions. maybe very naive, but I am a rookie in this filed. Hope you can understand I have read the example given by you, but I am comfused with something. from_port0, from_port1 :: FromDevice...; to_port0, to_port1 :: ToDevice...; span_tree :: EtherSpanTree(00-1f-29-4d-f8-31, in_supp, out_supp, switch); switch :: EtherSwitch; in_supp, out_supp :: Suppressor; from_port0 -> c0 :: Classifier(14/4242, -); from_port1 -> c1 :: Classifier(14/4242, -); q0 :: Queue -> to_port0; q1 :: Queue -> to_port1; c0 [0] -> [0] span_tree [0] -> q0; c1 [0] -> [1] span_tree [1] -> q1; c0 [1] -> [0] in_supp [0] -> [0] switch [0] -> [0] out_supp [0] -> q0; c1 [1] -> [1] in_supp [1] -> [1] switch [1] -> [1] out_supp [1] -> q1; 1 In this example, the switch has two ports. This means switch has two NICs, right? If I want to use one PC as a switch and suppose this switch has 8 ports, Does the PC I used actually need 8 NICs? 2 Can I use these ethernet switch relational elements on userlevel to implement some protocols designed by myself? Thanks very much. I do need help and appreciate your answers a lot. Looking forward to your help. -Jing 2010-03-26 Jing Yuan ???? Eddie Kohler ????? 2010-02-16 17:45:45 ???? Jing Yuan ??? Beyers Cronje; click ??? Re: [Click] Question about Ethernet Switch Configuration Hi Jing, This element wasn't ever documented, but I've just added some documentation. Hopefully you will find it useful. http://read.cs.ucla.edu/gitweb?p=click;a=blob;f=elements/etherswitch/spantree.hh Eddie Jing Yuan wrote: > Thank Beyers for your quick help. > > I still have some problems. > > 1 For example, when I want to build a spanning tree among many(more than 2)switches based on Click. How can I generate the BPDU packet? Does the Switch still get the packet from the device and modify it to BPDU frame format and then broadcast the modified packet(BPDU)? I have no clear idea to configure this work. How does the EtherSpanTree element work when switch is building a spanning tree among themselves? When configure a Ethernet Switch, does each switch need an EtherSpanTree element? I have little knowledge on Click and I am totally confused. > > 2 I still do not know the exact meanings of the parameter in EtherSpanTree. Can anybody give me a detailed discription about this element? For example, in st::EtherSpanTree(00:02:03:04:05:06, in, out, s), Does "00:02:03:04:05:06"represent the MAC address of the switch? > > Best regards?Looking forward to your reply. I do appreciate your help very much! > > -Jing > > 2010-01-18 > > > > Jing Yuan > > > > ???? Beyers Cronje > ????? 2010-01-18 01:12:01 > ???? Jing Yuan > ??? click > ??? Re: [Click] Question about Ethernet Switch Configuration > > Hi Jing, > > Look on page 69/70 of http://pdos.csail.mit.edu/papers/click:kohler-phd/thesis.pdf for an explanation and example of a Ethernet Switch configuration that includes EtherSpanTree. There's also an example in click/conf directory called kswitch.ipb > > Hope that helps. > > Beyers Cronje > > > On Mon, Jan 18, 2010 at 7:04 AM, Jing Yuan wrote: > > Dear Click developers and users > > As I am familiarizing myself with Click and using Click worked as Ethernet Switch to implement a protocol like SPT(Spanning Tree Protocol), I have some questions about Click > > 1 I have designed a protocol and want to implement it on switch. So should I install Click in some PCs (more than two) and use Click to configure them as switch respectively? > > 2 My protocol is similar to STP. So I think maybe I can modify the EtherSpanTree element, but there is no description about this element. Does anybody have some experiences or examples about this element or some instances of Ethernet switch which is configured with elements, such as Supperssor, EtherSwitch and EtherSpanTree. > > I do need some detailed introductions and examples about EtherSpanTree element. Can anybody help me and give me a > clear explanation on these questions? Thanks very much! > > All the best wishes for you! > Looking forward to your reply! > > -Jing > > 2010-01-17 > > > > Jing Yuan > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1662 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100326/4d2a7e3f/attachment.gif From kohler at cs.ucla.edu Fri Mar 26 14:26:47 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 26 Mar 2010 14:26:47 -0400 Subject: [Click] Question about Ethernet Switch Configuration In-Reply-To: <201003261317321406534@northwestern.edu> References: <201001172304489214300@northwestern.edu>, <201001181709317811875@northwestern.edu> <201003261317321406534@northwestern.edu> Message-ID: <4BACFC67.7030009@cs.ucla.edu> 1. Yes, 2. Yes if you can make it work (if it works for you). E Jing Yuan wrote: > Hi Eddie > > Thank you very much for your help. It is very useful for me. But I still > have some questions. maybe very naive, but I am a rookie in this filed. > Hope you can understand > > I have read the example given by you, but I am comfused with something. > > from_port0, from_port1 :: FromDevice...; > to_port0, to_port1 :: ToDevice...; > > span_tree :: EtherSpanTree(00-1f-29-4d-f8-31, in_supp, out_supp, switch); > switch :: EtherSwitch; > in_supp, out_supp :: Suppressor; > > from_port0 -> c0 :: Classifier(14/4242, -); > from_port1 -> c1 :: Classifier(14/4242, -); > > q0 :: Queue -> to_port0; > q1 :: Queue -> to_port1; > > c0 [0] -> [0] span_tree [0] -> q0; > c1 [0] -> [1] span_tree [1] -> q1; > > c0 [1] -> [0] in_supp [0] -> [0] switch [0] -> [0] out_supp [0] -> q0; > c1 [1] -> [1] in_supp [1] -> [1] switch [1] -> [1] out_supp [1] -> q1; > > 1 In this example, the switch has two ports. This means switch has two > NICs, right? If I want to use one PC as a switch and suppose this > switch has 8 ports, Does the PC I used actually need 8 NICs? > > 2 Can I use these ethernet switch relational elements on userlevel to > implement some protocols designed by myself? > > Thanks very much. I do need help and appreciate your answers a lot. > > Looking forward to your help. > > -Jing > > 2010-03-26 > ------------------------------------------------------------------------ > Jing Yuan > ------------------------------------------------------------------------ > *????* Eddie Kohler > *?????* 2010-02-16 17:45:45 > *????* Jing Yuan > *???* Beyers Cronje; click > *???* Re: [Click] Question about Ethernet Switch Configuration > Hi Jing, > This element wasn't ever documented, but I've just added some documentation. > Hopefully you will find it useful. > http://read.cs.ucla.edu/gitweb?p=click;a=blob;f=elements/etherswitch/spantree.hh > Eddie > Jing Yuan wrote: > > Thank Beyers for your quick help. > > > > I still have some problems. > > > > 1 For example, when I want to build a spanning tree among many(more than 2)switches based on Click. How can I generate the BPDU packet? Does the Switch still get the packet from the device and modify it to BPDU frame format and then broadcast the modified packet(BPDU)? I have no clear idea to configure this work. How does the EtherSpanTree element work when switch is building a spanning tree among themselves? When configure a Ethernet Switch, does each switch need an EtherSpanTree element? I have little knowledge on Click and I am totally confused. > > > > 2 I still do not know the exact meanings of the parameter in EtherSpanTree. Can anybody give me a detailed discription about this element? For example, in st::EtherSpanTree(00:02:03:04:05:06, in, out, s), Does "00:02:03:04:05:06"represent the MAC address of the switch? > > > > Best regards? > Looking forward to your reply. I do appreciate your help very much! > > > > -Jing > > > > 2010-01-18 > > > > > > > > Jing Yuan > > > > > > > > ???? Beyers Cronje > > ????? 2010-01-18 01:12:01 > > ???? Jing Yuan > > ??? click > > ??? Re: [Click] Question about Ethernet Switch Configuration > > > > Hi Jing, > > > > Look on page 69/70 of http://pdos.csail.mit.edu/papers/click:kohler-phd/thesis.pdf for an explanation and example of a Ethernet Switch configuration that includes EtherSpanTree. There's also an example in click/conf directory called kswitch.ipb > > > > Hope that helps. > > > > Beyers Cronje > > > > > > On Mon, Jan 18, 2010 at 7:04 AM, Jing Yuan wrote: > > > > Dear Click developers and users > > > > As I am familiarizing myself with Click and using Click worked as Ethernet Switch to implement a protocol like SPT(Spanning Tree Protocol), I have some questions about Click > > > > 1 I have designed a protocol and want to implement it on switch. So should I install Click in some PCs (more than two) and use Click to configure them as switch respectively? > > > > 2 My protocol is similar to STP. So I think maybe I can modify the EtherSpanTree element, but there is no description about this element. Does anybody have some experiences or examples about this element or some instances of Ethernet switch which is configured with elements, such as Supperssor, EtherSwitch and EtherSpanTree. > > > > I do need some detailed introductions and examples about EtherSpanTree element. Can anybody help me and give me a > > clear explanation on these questions? Thanks very much! > > > > All the best wishes for you! > > Looking forward to your reply! > > > > -Jing > > > > 2010-01-17 > > > > > > > > Jing Yuan > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From jing-yuan at northwestern.edu Fri Mar 26 15:05:36 2010 From: jing-yuan at northwestern.edu (=?utf-8?B?SmluZyBZdWFu?=) Date: Fri, 26 Mar 2010 14:05:36 -0500 Subject: [Click] =?utf-8?q?Question_about_Ethernet_Switch_Configuration?= References: <201001172304489214300@northwestern.edu>, <201001181709317811875@northwestern.edu>, <201003261317321406534@northwestern.edu>, <4BACFC67.7030009@cs.ucla.edu> Message-ID: <201003261405361717815@northwestern.edu> Hi Eddie Thank you very much for your quick reply. one more question , if a switch has 8 ports and 8 NICs, meanwhile it has 8 MAC addresses right? I just need to choose one of them as the unique ID or address of Switch ? Thanks, appreciate your help a lot! Best Regards -Jing 2010-03-26 Jing Yuan ???? Eddie Kohler ????? 2010-03-26 13:27:10 ???? Jing Yuan ??? Beyers Cronje; click ??? Re: [Click] Question about Ethernet Switch Configuration 1. Yes, 2. Yes if you can make it work (if it works for you). E Jing Yuan wrote: > Hi Eddie > > Thank you very much for your help. It is very useful for me. But I still > have some questions. maybe very naive, but I am a rookie in this filed. > Hope you can understand > > I have read the example given by you, but I am comfused with something. > > from_port0, from_port1 :: FromDevice...; > to_port0, to_port1 :: ToDevice...; > > span_tree :: EtherSpanTree(00-1f-29-4d-f8-31, in_supp, out_supp, switch); > switch :: EtherSwitch; > in_supp, out_supp :: Suppressor; > > from_port0 -> c0 :: Classifier(14/4242, -); > from_port1 -> c1 :: Classifier(14/4242, -); > > q0 :: Queue -> to_port0; > q1 :: Queue -> to_port1; > > c0 [0] -> [0] span_tree [0] -> q0; > c1 [0] -> [1] span_tree [1] -> q1; > > c0 [1] -> [0] in_supp [0] -> [0] switch [0] -> [0] out_supp [0] -> q0; > c1 [1] -> [1] in_supp [1] -> [1] switch [1] -> [1] out_supp [1] -> q1; > > 1 In this example, the switch has two ports. This means switch has two > NICs, right? If I want to use one PC as a switch and suppose this > switch has 8 ports, Does the PC I used actually need 8 NICs? > > 2 Can I use these ethernet switch relational elements on userlevel to > implement some protocols designed by myself? > > Thanks very much. I do need help and appreciate your answers a lot. > > Looking forward to your help. > > -Jing > > 2010-03-26 > ------------------------------------------------------------------------ > Jing Yuan > ------------------------------------------------------------------------ > *????* Eddie Kohler > *?????* 2010-02-16 17:45:45 > *????* Jing Yuan > *???* Beyers Cronje; click > *???* Re: [Click] Question about Ethernet Switch Configuration > Hi Jing, > This element wasn't ever documented, but I've just added some documentation. > Hopefully you will find it useful. > http://read.cs.ucla.edu/gitweb?p=click;a=blob;f=elements/etherswitch/spantree.hh > Eddie > Jing Yuan wrote: > > Thank Beyers for your quick help. > > > > I still have some problems. > > > > 1 For example, when I want to build a spanning tree among many(more than 2)switches based on Click. How can I generate the BPDU packet? Does the Switch still get the packet from the device and modify it to BPDU frame format and then broadcast the modified packet(BPDU)? I have no clear idea to configure this work. How does the EtherSpanTree element work when switch is building a spanning tree among themselves? When configure a Ethernet Switch, does each switch need an EtherSpanTree element? I have little knowledge on Click and I am totally confused. > > > > 2 I still do not know the exact meanings of the parameter in EtherSpanTree. Can anybody give me a detailed discription about this element? For example, in st::EtherSpanTree(00:02:03:04:05:06, in, out, s), Does "00:02:03:04:05:06"represent the MAC address of the switch? > > > > Best regards? > Looking forward to your reply. I do appreciate your help very much! > > > > -Jing > > > > 2010-01-18 > > > > > > > > Jing Yuan > > > > > > > > ???? Beyers Cronje > > ????? 2010-01-18 01:12:01 > > ???? Jing Yuan > > ??? click > > ??? Re: [Click] Question about Ethernet Switch Configuration > > > > Hi Jing, > > > > Look on page 69/70 of http://pdos.csail.mit.edu/papers/click:kohler-phd/thesis.pdf for an explanation and example of a Ethernet Switch configuration that includes EtherSpanTree. There's also an example in click/conf directory called kswitch.ipb > > > > Hope that helps. > > > > Beyers Cronje > > > > > > On Mon, Jan 18, 2010 at 7:04 AM, Jing Yuan wrote: > > > > Dear Click developers and users > > > > As I am familiarizing myself with Click and using Click worked as Ethernet Switch to implement a protocol like SPT(Spanning Tree Protocol), I have some questions about Click > > > > 1 I have designed a protocol and want to implement it on switch. So should I install Click in some PCs (more than two) and use Click to configure them as switch respectively? > > > > 2 My protocol is similar to STP. So I think maybe I can modify the EtherSpanTree element, but there is no description about this element. Does anybody have some experiences or examples about this element or some instances of Ethernet switch which is configured with elements, such as Supperssor, EtherSwitch and EtherSpanTree. > > > > I do need some detailed introductions and examples about EtherSpanTree element. Can anybody help me and give me a > > clear explanation on these questions? Thanks very much! > > > > All the best wishes for you! > > Looking forward to your reply! > > > > -Jing > > > > 2010-01-17 > > > > > > > > Jing Yuan > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Fri Mar 26 15:13:48 2010 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 26 Mar 2010 15:13:48 -0400 Subject: [Click] Question about Ethernet Switch Configuration In-Reply-To: <201003261405361717815@northwestern.edu> References: <201001172304489214300@northwestern.edu>, <201001181709317811875@northwestern.edu>, <201003261317321406534@northwestern.edu>, <4BACFC67.7030009@cs.ucla.edu> <201003261405361717815@northwestern.edu> Message-ID: <4BAD076C.70309@cs.ucla.edu> I don't know what you mean. An 8-port switch generally has 8 mac addresses, yes. Jing Yuan wrote: > Hi Eddie > > Thank you very much for your quick reply. > > one more question , if a switch has 8 ports and 8 NICs, meanwhile it > has 8 MAC addresses right? I just need to choose one of them as the > unique ID or address of Switch ? Thanks, appreciate your help a lot! > > Best Regards > > -Jing > > > 2010-03-26 > ------------------------------------------------------------------------ > Jing Yuan > ------------------------------------------------------------------------ > *????* Eddie Kohler > *?????* 2010-03-26 13:27:10 > *????* Jing Yuan > *???* Beyers Cronje; click > *???* Re: [Click] Question about Ethernet Switch Configuration > 1. Yes, 2. Yes if you can make it work (if it works for you). > E > Jing Yuan wrote: > > Hi Eddie > > > > Thank you very much for your help. It is very useful for me. But I still > > have some questions. maybe very naive, but I am a rookie in this filed. > > Hope you can understand > > > > I have read the example given by you, but I am comfused with something. > > > > from_port0, from_port1 :: FromDevice...; > > to_port0, to_port1 :: ToDevice...; > > > > span_tree :: EtherSpanTree(00-1f-29-4d-f8-31, in_supp, out_supp, switch); > > switch :: EtherSwitch; > > in_supp, out_supp :: Suppressor; > > > > from_port0 -> c0 :: Classifier(14/4242, -); > > from_port1 -> c1 :: Classifier(14/4242, -); > > > > q0 :: Queue -> to_port0; > > q1 :: Queue -> to_port1; > > > > c0 [0] -> [0] span_tree [0] -> q0; > > c1 [0] -> [1] span_tree [1] -> q1; > > > > c0 [1] -> [0] in_supp [0] -> [0] switch [0] -> [0] out_supp [0] -> q0; > > c1 [1] -> [1] in_supp [1] -> [1] switch [1] -> [1] out_supp [1] -> q1; > > > > 1 In this example, the switch has two ports. This means switch has two > > NICs, right? If I want to use one PC as a switch and suppose this > > switch has 8 ports, Does the PC I used actually need 8 NICs? > > > > 2 Can I use these ethernet switch relational elements on userlevel to > > implement some protocols designed by myself? > > > > Thanks very much. I do need help and appreciate your answers a lot. > > > > Looking forward to your help. > > > > -Jing > > > > 2010-03-26 > > ------------------------------------------------------------------------ > > Jing Yuan > > ------------------------------------------------------------------------ > > *????* Eddie Kohler > > *?????* 2010-02-16 17:45:45 > > *????* Jing Yuan > > *???* Beyers Cronje; click > > *???* Re: [Click] Question about Ethernet Switch Configuration > > Hi Jing, > > This element wasn't ever documented, but I've just added some documentation. > > Hopefully you will find it useful. > > http://read.cs.ucla.edu/gitweb?p=click;a=blob;f=elements/etherswitch/spantree.hh > > Eddie > > Jing Yuan wrote: > > > Thank Beyers for your quick help. > > > > > > I still have some problems. > > > > > > 1 For example, when I want to build a spanning tree among many(more than 2)switches based on Click. How can I generate the BPDU packet? Does the Switch still get the packet from the device and modify it to BPDU frame format and then broadcast the modified packet(BPDU)? I have no clear idea to configure this work. How does the EtherSpanTree element work when switch is building a spanning tree among themselves? When configure a Ethernet Switch, does each switch need an EtherSpanTree element? I have little knowledge on Click and I am totally confused. > > > > > > 2 I still do not know the exact meanings of the parameter in EtherSpanTree. Can anybody give me a detailed discription about this element? For example, in st::EtherSpanTree(00:02:03:04:05:06, in, out, s), Does "00:02:03:04:05:06"represent the MAC address of the switch? > > > > > > Best regards? > > Looking forward to your reply. I do appreciate your help very much! > > > > > > -Jing > > > > > > 2010-01-18 > > > > > > > > > > > > Jing Yuan > > > > > > > > > > > > ???? Beyers Cronje > > > ????? 2010-01-18 01:12:01 > > > ???? Jing Yuan > > > ??? click > > > ??? Re: [Click] Question about Ethernet Switch Configuration > > > > > > Hi Jing, > > > > > > Look on page 69/70 of http://pdos.csail.mit.edu/papers/click:kohler-phd/thesis.pdf for an explanation and example of a Ethernet Switch configuration that includes EtherSpanTree. There's also an example in click/conf directory called kswitch.ipb > > > > > > Hope that helps. > > > > > > Beyers Cronje > > > > > > > > > On Mon, Jan 18, 2010 at 7:04 AM, Jing Yuan wrote: > > > > > > Dear Click developers and users > > > > > > As I am familiarizing myself with Click and using Click worked as Ethernet Switch to implement a protocol like SPT(Spanning Tree Protocol), I have some questions about Click > > > > > > 1 I have designed a protocol and want to implement it on switch. So should I install Click in some PCs (more than two) and use Click to configure them as switch respectively? > > > > > > 2 My protocol is similar to STP. So I think maybe I can modify the EtherSpanTree element, but there is no description about this element. Does anybody have some experiences or examples about this element or some instances of Ethernet switch which is configured with elements, such as Supperssor, EtherSwitch and EtherSpanTree. > > > > > > I do need some detailed introductions and examples about EtherSpanTree element. Can anybody help me and give me a > > > clear explanation on these questions? Thanks very much! > > > > > > All the best wishes for you! > > > Looking forward to your reply! > > > > > > -Jing > > > > > > 2010-01-17 > > > > > > > > > > > > Jing Yuan > > > _______________________________________________ > > > click mailing list > > > click at amsterdam.lcs.mit.edu > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > _______________________________________________ > > > click mailing list > > > click at amsterdam.lcs.mit.edu > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From jing-yuan at northwestern.edu Fri Mar 26 15:45:26 2010 From: jing-yuan at northwestern.edu (=?utf-8?B?SmluZyBZdWFu?=) Date: Fri, 26 Mar 2010 14:45:26 -0500 Subject: [Click] =?utf-8?q?Question_about_Ethernet_Switch_Configuration?= References: <201001172304489214300@northwestern.edu>, <201001181709317811875@northwestern.edu>, <201003261317321406534@northwestern.edu>, <4BACFC67.7030009@cs.ucla.edu>, <201003261405361717815@northwestern.edu> Message-ID: <201003261445266876551@northwestern.edu> Hi Eddie I am very sorry Maybe I do not describe my problem clearly. This is the "EtherSpanTree" Element description: EtherSpanTree(ADDR, INPUT_SUPPRESSOR, OUTPUT_SUPPRESSOR, SWITCH) and in this example: span_tree :: EtherSpanTree(00-1f-29-4d-f8-31, in_supp, out_supp, switch); "00-1f-29-4d-f8-31" is the mac address of the switch. If I want to use "EtherSpanTree" Element, do I just need to choose one of the 8 mac addresses of 8-ports switch as the parameter "ADDR"? Thanks Best Regards -Jing 2010-03-26 Jing Yuan ???? Eddie Kohler ????? 2010-03-26 14:14:10 ???? Jing Yuan ??? Beyers Cronje; click ??? Re: [Click] Question about Ethernet Switch Configuration I don't know what you mean. An 8-port switch generally has 8 mac addresses, yes. Jing Yuan wrote: > Hi Eddie > > Thank you very much for your quick reply. > > one more question , if a switch has 8 ports and 8 NICs, meanwhile it > has 8 MAC addresses right? I just need to choose one of them as the > unique ID or address of Switch ? Thanks, appreciate your help a lot! > > Best Regards > > -Jing > > > 2010-03-26 > ------------------------------------------------------------------------ > Jing Yuan > ------------------------------------------------------------------------ > *????* Eddie Kohler > *?????* 2010-03-26 13:27:10 > *????* Jing Yuan > *???* Beyers Cronje; click > *???* Re: [Click] Question about Ethernet Switch Configuration > 1. Yes, 2. Yes if you can make it work (if it works for you). > E > Jing Yuan wrote: > > Hi Eddie > > > > Thank you very much for your help. It is very useful for me. But I still > > have some questions. maybe very naive, but I am a rookie in this filed. > > Hope you can understand > > > > I have read the example given by you, but I am comfused with something. > > > > from_port0, from_port1 :: FromDevice...; > > to_port0, to_port1 :: ToDevice...; > > > > span_tree :: EtherSpanTree(00-1f-29-4d-f8-31, in_supp, out_supp, switch); > > switch :: EtherSwitch; > > in_supp, out_supp :: Suppressor; > > > > from_port0 -> c0 :: Classifier(14/4242, -); > > from_port1 -> c1 :: Classifier(14/4242, -); > > > > q0 :: Queue -> to_port0; > > q1 :: Queue -> to_port1; > > > > c0 [0] -> [0] span_tree [0] -> q0; > > c1 [0] -> [1] span_tree [1] -> q1; > > > > c0 [1] -> [0] in_supp [0] -> [0] switch [0] -> [0] out_supp [0] -> q0; > > c1 [1] -> [1] in_supp [1] -> [1] switch [1] -> [1] out_supp [1] -> q1; > > > > 1 In this example, the switch has two ports. This means switch has two > > NICs, right? If I want to use one PC as a switch and suppose this > > switch has 8 ports, Does the PC I used actually need 8 NICs? > > > > 2 Can I use these ethernet switch relational elements on userlevel to > > implement some protocols designed by myself? > > > > Thanks very much. I do need help and appreciate your answers a lot. > > > > Looking forward to your help. > > > > -Jing > > > > 2010-03-26 > > ------------------------------------------------------------------------ > > Jing Yuan > > ------------------------------------------------------------------------ > > *????* Eddie Kohler > > *?????* 2010-02-16 17:45:45 > > *????* Jing Yuan > > *???* Beyers Cronje; click > > *???* Re: [Click] Question about Ethernet Switch Configuration > > Hi Jing, > > This element wasn't ever documented, but I've just added some documentation. > > Hopefully you will find it useful. > > http://read.cs.ucla.edu/gitweb?p=click;a=blob;f=elements/etherswitch/spantree.hh > > Eddie > > Jing Yuan wrote: > > > Thank Beyers for your quick help. > > > > > > I still have some problems. > > > > > > 1 For example, when I want to build a spanning tree among many(more than 2)switches based on Click. How can I generate the BPDU packet? Does the Switch still get the packet from the device and modify it to BPDU frame format and then broadcast the modified packet(BPDU)? I have no clear idea to configure this work. How does the EtherSpanTree element work when switch is building a spanning tree among themselves? When configure a Ethernet Switch, does each switch need an EtherSpanTree element? I have little knowledge on Click and I am totally confused. > > > > > > 2 I still do not know the exact meanings of the parameter in EtherSpanTree. Can anybody give me a detailed discription about this element? For example, in st::EtherSpanTree(00:02:03:04:05:06, in, out, s), Does "00:02:03:04:05:06"represent the MAC address of the switch? > > > > > > Best regards? > > Looking forward to your reply. I do appreciate your help very much! > > > > > > -Jing > > > > > > 2010-01-18 > > > > > > > > > > > > Jing Yuan > > > > > > > > > > > > ???? Beyers Cronje > > > ????? 2010-01-18 01:12:01 > > > ???? Jing Yuan > > > ??? click > > > ??? Re: [Click] Question about Ethernet Switch Configuration > > > > > > Hi Jing, > > > > > > Look on page 69/70 of http://pdos.csail.mit.edu/papers/click:kohler-phd/thesis.pdf for an explanation and example of a Ethernet Switch configuration that includes EtherSpanTree. There's also an example in click/conf directory called kswitch.ipb > > > > > > Hope that helps. > > > > > > Beyers Cronje > > > > > > > > > On Mon, Jan 18, 2010 at 7:04 AM, Jing Yuan wrote: > > > > > > Dear Click developers and users > > > > > > As I am familiarizing myself with Click and using Click worked as Ethernet Switch to implement a protocol like SPT(Spanning Tree Protocol), I have some questions about Click > > > > > > 1 I have designed a protocol and want to implement it on switch. So should I install Click in some PCs (more than two) and use Click to configure them as switch respectively? > > > > > > 2 My protocol is similar to STP. So I think maybe I can modify the EtherSpanTree element, but there is no description about this element. Does anybody have some experiences or examples about this element or some instances of Ethernet switch which is configured with elements, such as Supperssor, EtherSwitch and EtherSpanTree. > > > > > > I do need some detailed introductions and examples about EtherSpanTree element. Can anybody help me and give me a > > > clear explanation on these questions? Thanks very much! > > > > > > All the best wishes for you! > > > Looking forward to your reply! > > > > > > -Jing > > > > > > 2010-01-17 > > > > > > > > > > > > Jing Yuan > > > _______________________________________________ > > > click mailing list > > > click at amsterdam.lcs.mit.edu > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > _______________________________________________ > > > click mailing list > > > click at amsterdam.lcs.mit.edu > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From jensdewit at gmail.com Sat Mar 27 19:00:18 2010 From: jensdewit at gmail.com (Jens De Wit) Date: Sun, 28 Mar 2010 00:00:18 +0100 Subject: [Click] proposition for a tcpipsend update Message-ID: <217154321003271600x7e7ade3bq8c1164441e89feb@mail.gmail.com> Hi Eddie, I'm still working on my FireSim project which you will probably remember from SyClick. I've reworked my scripts a bit in a way that they can now smoothly terminate themselves instead of some dirty polling trick with handlers I used till now. However, to stop the scripts in cases where I generate tcp traffic with the TCPIPSend element I needed a stop parameter for the send write handler. I also liked the idea of being able to send multiple copies of the same tcp packet for testing purposes, just like you can do for udp en icmp by using InfiniteSource in combination with UDPIPEncap or ICMPIPencap. So, I've updated the write handler of the TCPIPSend element and now I was wondering if you would consider adding this small change to the Click standard. If you have any remarks, please let me know. Regards, Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: tcpipsend.cc Type: text/x-c++src Size: 3786 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20100328/77661763/attachment.cc From ianrose at eecs.harvard.edu Tue Mar 30 02:09:30 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Tue, 30 Mar 2010 02:09:30 -0400 Subject: [Click] line numbers in click binary symbol table Message-ID: <4BB1959A.2030704@eecs.harvard.edu> Hi list, This may or may not be specific to Click, so apologies in advance if I am off topic. I am attempting to do some debugging of my (userlevel) click app and I am finding that the symbol table of the resulting click binary has very few line numbers in it (as viewed by 'nm -l -C bin/click'). This is a problem for me because it means that basically every address that I pass to addr2line returns '??:0' for the file and line number. I've also had some problems getting useful information out of coredumps (which is why I am messing about with addr2line instead of just gdb), perhaps for the same reason? My knowledge is rather limited as far as compiling and linking go, so my question is whether this is somehow Click's doing (perhaps its stripping most of the line numbers?) or whether this is normal gcc/ld behavior that I'm just unfamiliar with. Other than click, I pretty much exclusively use C over C++ so if there is some different behavior for C++ code I wouldn't know it. I've tried digging through the click Makefiles but I haven't found anything incriminating. Also, I've confirmed that I am compiling with -g and I have tried both with and without -O2 with no noticeable difference. Many thanks for any tips! - Ian From rchertov at cs.ucsb.edu Tue Mar 30 02:28:46 2010 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Mon, 29 Mar 2010 23:28:46 -0700 Subject: [Click] line numbers in click binary symbol table In-Reply-To: <4BB1959A.2030704@eecs.harvard.edu> References: <4BB1959A.2030704@eecs.harvard.edu> Message-ID: <4BB19A1E.5060600@cs.ucsb.edu> Ian, When you are compiling for debugging, do not use the O2 flag is it makes it hard to match the program with the code (gcc can move instructions about). An easy way to see if you have debugging symbols in the code is to place a break point in your code. If you can't see your code at the break point, you don't have debugging symbols (you will probably have problems placing the break point in the first place). Make sure that the -g option is passed to the compiler and the linker. Also, rebuild the whole project to ensure that you get debugging information built in. I've done this in past with click, but it takes a bit of mucking around with the make file. Roman Ian Rose wrote: > Hi list, > > This may or may not be specific to Click, so apologies in advance if I > am off topic. I am attempting to do some debugging of my (userlevel) > click app and I am finding that the symbol table of the resulting click > binary has very few line numbers in it (as viewed by 'nm -l -C > bin/click'). This is a problem for me because it means that basically > every address that I pass to addr2line returns '??:0' for the file and > line number. I've also had some problems getting useful information out > of coredumps (which is why I am messing about with addr2line instead of > just gdb), perhaps for the same reason? > > My knowledge is rather limited as far as compiling and linking go, so my > question is whether this is somehow Click's doing (perhaps its stripping > most of the line numbers?) or whether this is normal gcc/ld behavior > that I'm just unfamiliar with. Other than click, I pretty much > exclusively use C over C++ so if there is some different behavior for > C++ code I wouldn't know it. I've tried digging through the click > Makefiles but I haven't found anything incriminating. Also, I've > confirmed that I am compiling with -g and I have tried both with and > without -O2 with no noticeable difference. > > Many thanks for any tips! > - Ian > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From jyyoo at netmedia.gist.ac.kr Tue Mar 30 03:36:04 2010 From: jyyoo at netmedia.gist.ac.kr (JaeYong Yoo) Date: Tue, 30 Mar 2010 16:36:04 +0900 Subject: [Click] Is there anyone trying to install Click in Android? Message-ID: <0145D5DF1C56174FABB6EB834BC4909CB88ECCDDA8@NML2007.netmedia.kjist.ac.kr> Hi all, Since Android is quite hot these a days (Google's vision is to install Android in all small devices including laptops!!!), I think it is good to test that Click is available on Android. Also, there are some people try to install Android on labtop. http://digital.venturebeat.com/2009/01/01/android-netbooks-on-their-way-likely-by-2010/ Best, jaeyong From ianrose at eecs.harvard.edu Tue Mar 30 08:04:32 2010 From: ianrose at eecs.harvard.edu (Ian Rose) Date: Tue, 30 Mar 2010 08:04:32 -0400 Subject: [Click] line numbers in click binary symbol table In-Reply-To: <4BB19A1E.5060600@cs.ucsb.edu> References: <4BB1959A.2030704@eecs.harvard.edu> <4BB19A1E.5060600@cs.ucsb.edu> Message-ID: <4BB1E8D0.8050503@eecs.harvard.edu> Roman - Doh! The -g option was the trick - I included it in CFLAGS but not CXXFLAGS. :( Thanks much, Ian Roman Chertov wrote: > Ian, > > When you are compiling for debugging, do not use the O2 flag is it makes > it hard to match the program with the code (gcc can move instructions > about). An easy way to see if you have debugging symbols in the code is > to place a break point in your code. If you can't see your code at the > break point, you don't have debugging symbols (you will probably have > problems placing the break point in the first place). > > Make sure that the -g option is passed to the compiler and the linker. > Also, rebuild the whole project to ensure that you get debugging > information built in. I've done this in past with click, but it takes a > bit of mucking around with the make file. > > Roman > > Ian Rose wrote: >> Hi list, >> >> This may or may not be specific to Click, so apologies in advance if I >> am off topic. I am attempting to do some debugging of my (userlevel) >> click app and I am finding that the symbol table of the resulting click >> binary has very few line numbers in it (as viewed by 'nm -l -C >> bin/click'). This is a problem for me because it means that basically >> every address that I pass to addr2line returns '??:0' for the file and >> line number. I've also had some problems getting useful information out >> of coredumps (which is why I am messing about with addr2line instead of >> just gdb), perhaps for the same reason? >> >> My knowledge is rather limited as far as compiling and linking go, so my >> question is whether this is somehow Click's doing (perhaps its stripping >> most of the line numbers?) or whether this is normal gcc/ld behavior >> that I'm just unfamiliar with. Other than click, I pretty much >> exclusively use C over C++ so if there is some different behavior for >> C++ code I wouldn't know it. I've tried digging through the click >> Makefiles but I haven't found anything incriminating. Also, I've >> confirmed that I am compiling with -g and I have tried both with and >> without -O2 with no noticeable difference. >> >> Many thanks for any tips! >> - Ian >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>