From harald at net.t-labs.tu-berlin.de Mon Nov 2 07:46:17 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Mon, 02 Nov 2009 13:46:17 +0100 Subject: [Click] click autoconf seems somewhat bugged Message-ID: <4AEED499.9000303@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 very wired behaviour of the git-sources on ubuntu-karmic: harald at harald-vbox:~/src/click$ ./configure '--prefix=/home/harald/local/DIR/click' '--enable-userlevel' '--enable-local' '--enable-wifi' '--disable-linuxmodule' checking build system type... i686-pc-linux-gnu [...] config.status: executing default-1 commands everything fine so far harald at harald-vbox:~/src/click$ make -j3 cd . && : && autoconf /bin/bash ./configure '--prefix=/home/harald/local/DIR/click' '--enable-userlevel' '--enable-local' '--en able-wifi' '--disable-linuxmodule' checking build system type... i686-pc-linux-gnu [...] checking for expat.h... yes checking for XML_ParserCreateNS in -lexpat... yes ./configure: line 12359: syntax error: unexpected end of file make: *** [config.status] Error 2 tried with default autoconf (2.64) and 2.59, same results. re-running ./configure from this point on will fail. probably it's not autoconf's fault, but maybe I'm missing some dependency, but I feel unable to find out what it could possibly be. bottom line: after running autoconf, configure won't run anymore.... apt-get remove autoconf -> click will build just fine. - -- 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 iD8DBQFK7tSYy8wrZ9OvkU0RAivqAJ0QYiu2iEyncbv1/43T8h2+LBE3mgCfbFkZ zk+0/5Rr4754ezW8Ul6jYSg= =tU0M -----END PGP SIGNATURE----- From jetever at gmail.com Mon Nov 2 08:27:42 2009 From: jetever at gmail.com (Yongheng Qi) Date: Mon, 2 Nov 2009 21:27:42 +0800 Subject: [Click] 11n monitor mode NOT answer ACK Message-ID: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> Dear all? Do you know atheros Ar92xx card monitor mode can answer ACK? I write a program do monitor mode send packet, but the receiver don't answer ACK. how to do can let monitor mode answer ACK? Thanks From jetever at gmail.com Mon Nov 2 08:27:42 2009 From: jetever at gmail.com (Yongheng Qi) Date: Mon, 2 Nov 2009 21:27:42 +0800 Subject: [Click] 11n monitor mode NOT answer ACK Message-ID: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> Dear all? Do you know atheros Ar92xx card monitor mode can answer ACK? I write a program do monitor mode send packet, but the receiver don't answer ACK. how to do can let monitor mode answer ACK? Thanks From amckinley03 at googlemail.com Mon Nov 2 09:09:18 2009 From: amckinley03 at googlemail.com (Alastair McKinley) Date: Mon, 2 Nov 2009 14:09:18 +0000 Subject: [Click] packet data compression? Message-ID: <6c6bb6f90911020609x661f527ma1430eef88a06497@mail.gmail.com> Hi everyone, Does anyone have any experience with compressing packet data from within or with click elements? I had a quick search and didn't see anything, and just wanted to ask before possibly re-inventing the wheel. Is this a feature that other people might be interested in? Best regards, Alastair From javier.recacha at gmail.com Mon Nov 2 10:00:50 2009 From: javier.recacha at gmail.com (=?ISO-8859-1?Q?Javier_S=E1nchez?=) Date: Mon, 2 Nov 2009 16:00:50 +0100 Subject: [Click] click autoconf seems somewhat bugged In-Reply-To: <4AEED499.9000303@net.t-labs.tu-berlin.de> References: <4AEED499.9000303@net.t-labs.tu-berlin.de> Message-ID: Hi, I experienced something similar, current git doesn?t compile well on ubuntu-karmic (i didnt? tried other distros) i am using click git from 6 moths ago and it is fine. Regards Javier 2009/11/2 Harald Schi?berg > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > very wired behaviour of the git-sources on ubuntu-karmic: > > harald at harald-vbox:~/src/click$ ./configure > '--prefix=/home/harald/local/DIR/click' '--enable-userlevel' > '--enable-local' '--enable-wifi' '--disable-linuxmodule' > checking build system type... i686-pc-linux-gnu > [...] > config.status: executing default-1 commands > > everything fine so far > > harald at harald-vbox:~/src/click$ make -j3 > cd . && : && autoconf > /bin/bash ./configure '--prefix=/home/harald/local/DIR/click' > '--enable-userlevel' '--enable-local' '--en > able-wifi' '--disable-linuxmodule' > checking build system type... i686-pc-linux-gnu > [...] > checking for expat.h... yes > checking for XML_ParserCreateNS in -lexpat... yes > ./configure: line 12359: syntax error: unexpected end of file > make: *** [config.status] Error 2 > > tried with default autoconf (2.64) and 2.59, same results. > re-running ./configure from this point on will fail. > > probably it's not autoconf's fault, but maybe I'm missing some > dependency, but I feel unable to find out what it could possibly be. > > bottom line: after running autoconf, configure won't run anymore.... > > apt-get remove autoconf -> > click will build just fine. > > > - -- > 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 > > iD8DBQFK7tSYy8wrZ9OvkU0RAivqAJ0QYiu2iEyncbv1/43T8h2+LBE3mgCfbFkZ > zk+0/5Rr4754ezW8Ul6jYSg= > =tU0M > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From javier.recacha at gmail.com Mon Nov 2 10:23:20 2009 From: javier.recacha at gmail.com (=?ISO-8859-1?Q?Javier_S=E1nchez?=) Date: Mon, 2 Nov 2009 16:23:20 +0100 Subject: [Click] 11n monitor mode NOT answer ACK In-Reply-To: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> Message-ID: it was working fine on 802.11g ? or is the first time you try? Have you tried something like this? ... define($IP_ADR 6.0.0.1/8) define($MAC_ADR 00:00:00:00:00:01) //use your real hw mac FromHost(fake1, $IP_ADR, ETHER $MAC_ADR) ... Regards Javier S?nchez On Mon, Nov 2, 2009 at 2:27 PM, Yongheng Qi wrote: > Dear all? > > Do you know atheros Ar92xx card monitor mode can answer ACK? > > I write a program do monitor mode send packet, but the receiver don't > answer ACK. > > how to do can let monitor mode answer ACK? > > Thanks > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From jetever at gmail.com Mon Nov 2 10:30:33 2009 From: jetever at gmail.com (Yongheng Qi) Date: Mon, 2 Nov 2009 23:30:33 +0800 Subject: [Click] 11n monitor mode NOT answer ACK In-Reply-To: References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> Message-ID: <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> yes, 802.11g is OK. I use roofnet on 802.11g. the click.config like you give. the same config explant to 802.11n. other function all is ok but the noack. Thanks 2009/11/2 Javier S?nchez > it was working fine on 802.11g ? or is the first time you try? > > Have you tried something like this? > > ... > define($IP_ADR 6.0.0.1/8) > define($MAC_ADR 00:00:00:00:00:01) //use your real hw mac > > FromHost(fake1, $IP_ADR, ETHER $MAC_ADR) > ... > > Regards > Javier S?nchez > > On Mon, Nov 2, 2009 at 2:27 PM, Yongheng Qi wrote: > >> Dear all? >> >> Do you know atheros Ar92xx card monitor mode can answer ACK? >> >> I write a program do monitor mode send packet, but the receiver don't >> answer ACK. >> >> how to do can let monitor mode answer ACK? >> >> Thanks >> _______________________________________________ >> click mailing list >> click at amsterdam.lcs.mit.edu >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > > -- Yongheng Qi Mobile: +86 1390 119 7481 From javier.recacha at gmail.com Mon Nov 2 10:45:27 2009 From: javier.recacha at gmail.com (=?ISO-8859-1?Q?Javier_S=E1nchez?=) Date: Mon, 2 Nov 2009 16:45:27 +0100 Subject: [Click] 11n monitor mode NOT answer ACK In-Reply-To: <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> Message-ID: I have no idea then. Is the packet being transmited correctly from the source device (you can use dump on 802.11n monitor device to verify) ? What driver are u using? u can try to look at the code (packet injection code), may be ack flag is desactivated on packet injection ?? on madwifi, ack can be desactivated like this if (IEEE80211_IS_MULTICAST(wh->i_addr1)) { flags |= HAL_TXDESC_NOACK; /* no ack on broad/multicast */ sc->sc_stats.ast_tx_noack++; try0 = 1; } Regards Javier 2009/11/2 Yongheng Qi > yes, 802.11g is OK. > > I use roofnet on 802.11g. the click.config like you give. > > the same config explant to 802.11n. other function all is ok but the > noack. > > Thanks > > 2009/11/2 Javier S?nchez > > it was working fine on 802.11g ? or is the first time you try? >> >> Have you tried something like this? >> >> ... >> define($IP_ADR 6.0.0.1/8) >> define($MAC_ADR 00:00:00:00:00:01) //use your real hw mac >> >> FromHost(fake1, $IP_ADR, ETHER $MAC_ADR) >> ... >> >> Regards >> Javier S?nchez >> >> On Mon, Nov 2, 2009 at 2:27 PM, Yongheng Qi wrote: >> >>> Dear all? >>> >>> Do you know atheros Ar92xx card monitor mode can answer ACK? >>> >>> I write a program do monitor mode send packet, but the receiver don't >>> answer ACK. >>> >>> how to do can let monitor mode answer ACK? >>> >>> Thanks >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > From javier.recacha at gmail.com Mon Nov 2 10:45:50 2009 From: javier.recacha at gmail.com (=?ISO-8859-1?Q?Javier_S=E1nchez?=) Date: Mon, 2 Nov 2009 16:45:50 +0100 Subject: [Click] 11n monitor mode NOT answer ACK In-Reply-To: <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> Message-ID: I have no idea then. Is the packet being transmited correctly from the source device (you can use dump on 802.11n monitor device to verify) ? What driver are u using? u can try to look at the code (packet injection code), may be ack flag is desactivated on packet injection ?? on madwifi, ack can be desactivated like this if (IEEE80211_IS_MULTICAST(wh->i_ addr1)) { flags |= HAL_TXDESC_NOACK; /* no ack on broad/multicast */ sc->sc_stats.ast_tx_noack++; try0 = 1; } Regards Javier 2009/11/2 Yongheng Qi > yes, 802.11g is OK. > > I use roofnet on 802.11g. the click.config like you give. > > the same config explant to 802.11n. other function all is ok but the > noack. > > Thanks > > 2009/11/2 Javier S?nchez > > it was working fine on 802.11g ? or is the first time you try? >> >> Have you tried something like this? >> >> ... >> define($IP_ADR 6.0.0.1/8) >> define($MAC_ADR 00:00:00:00:00:01) //use your real hw mac >> >> FromHost(fake1, $IP_ADR, ETHER $MAC_ADR) >> ... >> >> Regards >> Javier S?nchez >> >> On Mon, Nov 2, 2009 at 2:27 PM, Yongheng Qi wrote: >> >>> Dear all? >>> >>> Do you know atheros Ar92xx card monitor mode can answer ACK? >>> >>> I write a program do monitor mode send packet, but the receiver don't >>> answer ACK. >>> >>> how to do can let monitor mode answer ACK? >>> >>> Thanks >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > From jetever at gmail.com Mon Nov 2 10:54:09 2009 From: jetever at gmail.com (Yongheng Qi) Date: Mon, 2 Nov 2009 23:54:09 +0800 Subject: [Click] 11n monitor mode NOT answer ACK In-Reply-To: References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> Message-ID: <3958ac680911020754q391fec0cucfc5871d1fe0016b@mail.gmail.com> yes, I use the atheros 11n sdk, and port it to our madwifi. the HAL_TXDESC_NOACK flags, I have use it send the multicast packets. but the not multicast packets, have i_addr packets can't get return ACK. I use Omnipeek get the packets. not find any problem. I don't know if the sdk HAL in monitor mode can't answer ACk. Thanks 2009/11/2 Javier S?nchez > I have no idea then. > > Is the packet being transmited correctly from the source device (you can > use dump on 802.11n monitor device to verify) ? > > What driver are u using? u can try to look at the code (packet injection > code), may be ack flag is desactivated on packet injection ?? > > on madwifi, ack can be desactivated like this > > if (IEEE80211_IS_MULTICAST(wh->i_addr1)) { > flags |= HAL_TXDESC_NOACK; /* no ack on broad/multicast */ > sc->sc_stats.ast_tx_noack++; > try0 = 1; > } > > Regards > Javier > > 2009/11/2 Yongheng Qi > > yes, 802.11g is OK. >> >> I use roofnet on 802.11g. the click.config like you give. >> >> the same config explant to 802.11n. other function all is ok but the >> noack. >> >> Thanks >> >> 2009/11/2 Javier S?nchez >> >> it was working fine on 802.11g ? or is the first time you try? >>> >>> Have you tried something like this? >>> >>> ... >>> define($IP_ADR 6.0.0.1/8) >>> define($MAC_ADR 00:00:00:00:00:01) //use your real hw mac >>> >>> FromHost(fake1, $IP_ADR, ETHER $MAC_ADR) >>> ... >>> >>> Regards >>> Javier S?nchez >>> >>> On Mon, Nov 2, 2009 at 2:27 PM, Yongheng Qi wrote: >>> >>>> Dear all? >>>> >>>> Do you know atheros Ar92xx card monitor mode can answer ACK? >>>> >>>> I write a program do monitor mode send packet, but the receiver don't >>>> answer ACK. >>>> >>>> how to do can let monitor mode answer ACK? >>>> >>>> Thanks >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>> >>> >>> >> >> >> -- >> Yongheng Qi >> >> Mobile: +86 1390 119 7481 >> > > -- Yongheng Qi Mobile: +86 1390 119 7481 From javier.recacha at gmail.com Mon Nov 2 11:02:02 2009 From: javier.recacha at gmail.com (=?ISO-8859-1?Q?Javier_S=E1nchez?=) Date: Mon, 2 Nov 2009 17:02:02 +0100 Subject: [Click] 11n monitor mode NOT answer ACK In-Reply-To: <3958ac680911020754q391fec0cucfc5871d1fe0016b@mail.gmail.com> References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> <3958ac680911020754q391fec0cucfc5871d1fe0016b@mail.gmail.com> Message-ID: Sorry, i have no idea what is the problem then. 2009/11/2 Yongheng Qi > yes, I use the atheros 11n sdk, and port it to our madwifi. > > the HAL_TXDESC_NOACK flags, I have use it send the multicast packets. > > but the not multicast packets, have i_addr packets can't get return ACK. > > I use Omnipeek get the packets. not find any problem. > > I don't know if the sdk HAL in monitor mode can't answer ACk. > > > Thanks > > 2009/11/2 Javier S?nchez > >> I have no idea then. >> >> Is the packet being transmited correctly from the source device (you can >> use dump on 802.11n monitor device to verify) ? >> >> What driver are u using? u can try to look at the code (packet injection >> code), may be ack flag is desactivated on packet injection ?? >> >> on madwifi, ack can be desactivated like this >> >> if (IEEE80211_IS_MULTICAST(wh->i_addr1)) { >> flags |= HAL_TXDESC_NOACK; /* no ack on broad/multicast */ >> sc->sc_stats.ast_tx_noack++; >> try0 = 1; >> } >> >> Regards >> Javier >> >> 2009/11/2 Yongheng Qi >> >> yes, 802.11g is OK. >>> >>> I use roofnet on 802.11g. the click.config like you give. >>> >>> the same config explant to 802.11n. other function all is ok but the >>> noack. >>> >>> Thanks >>> >>> 2009/11/2 Javier S?nchez >>> >>> it was working fine on 802.11g ? or is the first time you try? >>>> >>>> Have you tried something like this? >>>> >>>> ... >>>> define($IP_ADR 6.0.0.1/8) >>>> define($MAC_ADR 00:00:00:00:00:01) //use your real hw mac >>>> >>>> FromHost(fake1, $IP_ADR, ETHER $MAC_ADR) >>>> ... >>>> >>>> Regards >>>> Javier S?nchez >>>> >>>> On Mon, Nov 2, 2009 at 2:27 PM, Yongheng Qi wrote: >>>> >>>>> Dear all? >>>>> >>>>> Do you know atheros Ar92xx card monitor mode can answer ACK? >>>>> >>>>> I write a program do monitor mode send packet, but the receiver don't >>>>> answer ACK. >>>>> >>>>> how to do can let monitor mode answer ACK? >>>>> >>>>> Thanks >>>>> _______________________________________________ >>>>> click mailing list >>>>> click at amsterdam.lcs.mit.edu >>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>>> >>>> >>>> >>> >>> >>> -- >>> Yongheng Qi >>> >>> Mobile: +86 1390 119 7481 >>> >> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > From jetever at gmail.com Mon Nov 2 11:13:43 2009 From: jetever at gmail.com (Yongheng Qi) Date: Tue, 3 Nov 2009 00:13:43 +0800 Subject: [Click] 11n monitor mode NOT answer ACK In-Reply-To: References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> <3958ac680911020730t1f40c2f4r1c167c930ecedc87@mail.gmail.com> <3958ac680911020754q391fec0cucfc5871d1fe0016b@mail.gmail.com> Message-ID: <3958ac680911020813t502f4a2aq14694d8818ce2ac0@mail.gmail.com> Thank you very much, I don't ath9k in monitor mode wether have the problem. But the ath9k have not support our card very well. On 11/3/09, Javier S?nchez wrote: > Sorry, i have no idea what is the problem then. > > 2009/11/2 Yongheng Qi > >> yes, I use the atheros 11n sdk, and port it to our madwifi. >> >> the HAL_TXDESC_NOACK flags, I have use it send the multicast packets. >> >> but the not multicast packets, have i_addr packets can't get return ACK. >> >> I use Omnipeek get the packets. not find any problem. >> >> I don't know if the sdk HAL in monitor mode can't answer ACk. >> >> >> Thanks >> >> 2009/11/2 Javier S?nchez >> >>> I have no idea then. >>> >>> Is the packet being transmited correctly from the source device (you can >>> use dump on 802.11n monitor device to verify) ? >>> >>> What driver are u using? u can try to look at the code (packet injection >>> code), may be ack flag is desactivated on packet injection ?? >>> >>> on madwifi, ack can be desactivated like this >>> >>> if (IEEE80211_IS_MULTICAST(wh->i_addr1)) { >>> flags |= HAL_TXDESC_NOACK; /* no ack on broad/multicast */ >>> sc->sc_stats.ast_tx_noack++; >>> try0 = 1; >>> } >>> >>> Regards >>> Javier >>> >>> 2009/11/2 Yongheng Qi >>> >>> yes, 802.11g is OK. >>>> >>>> I use roofnet on 802.11g. the click.config like you give. >>>> >>>> the same config explant to 802.11n. other function all is ok but the >>>> noack. >>>> >>>> Thanks >>>> >>>> 2009/11/2 Javier S?nchez >>>> >>>> it was working fine on 802.11g ? or is the first time you try? >>>>> >>>>> Have you tried something like this? >>>>> >>>>> ... >>>>> define($IP_ADR 6.0.0.1/8) >>>>> define($MAC_ADR 00:00:00:00:00:01) //use your real hw mac >>>>> >>>>> FromHost(fake1, $IP_ADR, ETHER $MAC_ADR) >>>>> ... >>>>> >>>>> Regards >>>>> Javier S?nchez >>>>> >>>>> On Mon, Nov 2, 2009 at 2:27 PM, Yongheng Qi wrote: >>>>> >>>>>> Dear all? >>>>>> >>>>>> Do you know atheros Ar92xx card monitor mode can answer ACK? >>>>>> >>>>>> I write a program do monitor mode send packet, but the receiver don't >>>>>> answer ACK. >>>>>> >>>>>> how to do can let monitor mode answer ACK? >>>>>> >>>>>> Thanks >>>>>> _______________________________________________ >>>>>> click mailing list >>>>>> click at amsterdam.lcs.mit.edu >>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Yongheng Qi >>>> >>>> Mobile: +86 1390 119 7481 >>>> >>> >>> >> >> >> -- >> Yongheng Qi >> >> Mobile: +86 1390 119 7481 >> > -- Sent from my mobile device Yongheng Qi Mobile: +86 1390 119 7481 From dennis_d at yahoo.cn Tue Nov 3 02:03:08 2009 From: dennis_d at yahoo.cn (=?gb2312?B?tsXJ0PbOICA=?=) Date: Tue, 3 Nov 2009 15:03:08 +0800 (CST) Subject: [Click] about: some error on running click on my pc Message-ID: <898849.79188.qm@web92411.mail.cnh.yahoo.com> hi, everyone, I have complie the click (userlevel) with the roofnet on my pc. but when i run the click, something error message shows up as the click runing, [root at Dennis clickPC]# ./dd_testclick sr2.click expensive Packet::push; have 12 wanted 32 expensive Packet::push; have 12 wanted 32 ToDevice(wlan1) send: Message too long expensive Packet::push; have 12 wanted 32 ToDevice(wlan1) send: Message too long expensive Packet::push; have 12 wanted 32 ToDevice(wlan1) send: Message too long expensive Packet::push; have 12 wanted 32 ToDevice(wlan1) send: Message too long ToDevice(wlan1) send: Message too long ToDevice(wlan1) send: Message too long ToDevice(wlan1) send: Message too long ToDevice(wlan1) send: Message too long The wlan1 is my usb wireless adapter, linksys WUSB54 GC with driver ralink rt73, and it does support monitor mode. Does any body know, what's wrong with it? pls tell me, THX A LOT. ________________________________ ??? Du Shangxin Wireless Information Security Lab Department of Information Security Shanghai Jiao Tong University Shanghai, 200240, China Tel:+8613918145825 Email: dennis_d at yahoo.cn ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ From remi.clavier at orange-ftgroup.com Tue Nov 3 07:16:35 2009 From: remi.clavier at orange-ftgroup.com (remi.clavier at orange-ftgroup.com) Date: Tue, 3 Nov 2009 13:16:35 +0100 Subject: [Click] SNMP issues In-Reply-To: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> References: <3958ac680911020527o1a296c96v8c8720a359052a80@mail.gmail.com> Message-ID: I'm very interessed on SNMP facilities offered by the click elements provided in the packge. Unfortunatly, after many tries, I'm not able to have a correct behaviour of elements. Perhaps, because the description of elements don't have exemples easy to understand... Any working exemple will be welcome... Both at the click side and at the mSNMP manager side. Especialy interested to use SNMP elements to trap some changes in the network. Another question... are click datas "exported" by SNMP writable from an external SNMP agent or only readable? In other wordd, my I use SNMP elements to interact with the router... Any help will be appreciated Remi From roberto.riggio at create-net.org Tue Nov 3 13:54:50 2009 From: roberto.riggio at create-net.org (Roberto Riggio) Date: Tue, 03 Nov 2009 19:54:50 +0100 Subject: [Click] Broadcast frame injection with ath5k Message-ID: <4AF07C7A.8090704@create-net.org> Hi, I'm trying to inject broadcast frames with click using the ath5k driver. The script that I'm using is the following: InfiniteSource(DATASIZE 1000) -> UDPIPEncap(1.0.0.2, 1234, 2.0.0.2, 1234) -> EtherEncap(0x0800, 1:1:1:1:1:1, ff:ff:ff:ff:ff:ff) -> WifiEncap(0x0, 00:00:00:00:00:00) -> SetTXRate(RATE 2) -> RadiotapEncap() -> Print() -> ToDevice(moni); The problem is that this configuration does not actually sends any traffic. In fact another laptop running wireshark and sniffing on another monitor interface does not receive anything. The following script instead produces some traffic at the receiver: InfiniteSource(DATASIZE 1000) -> UDPIPEncap(1.0.0.2, 1234, 2.0.0.2, 1234) -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2) -> WifiEncap(0x0, 00:00:00:00:00:00) -> SetTXRate(RATE 2) -> RadiotapEncap() -> Print() -> ToDevice(moni); Am I missing something? Is there anybody that can successfully inject broadcast frames with ath5k or ath9k? thanks R. From amckinley03 at googlemail.com Thu Nov 5 06:19:38 2009 From: amckinley03 at googlemail.com (Alastair McKinley) Date: Thu, 5 Nov 2009 11:19:38 +0000 Subject: [Click] hashcode confusion Message-ID: <6c6bb6f90911050319k7ac9a12fldc076dee608fb611@mail.gmail.com> Hi Everyone, I am writing an element for analysing wifi traffic and realised in the process that I was implementing the same class as EtherPair in roofnet/analysis/wificounter.hh. class EtherPair { public: EtherAddress _src; EtherAddress _dst; EtherPair() { } EtherPair(EtherAddress src, EtherAddress dst) { _src = src; _dst = dst; } inline bool operator==(EtherPair other) { return _src == other._src && _dst == other._dst; } inline size_t hashcode() const; }; inline size_t EtherPair::hashcode() const { return CLICK_NAME(hashcode)(_src) + CLICK_NAME(hashcode)(_dst); } Can someone explain how the hashcode member function works in the this example? Best regards, Alastair From harald at net.t-labs.tu-berlin.de Thu Nov 5 07:39:41 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Thu, 05 Nov 2009 13:39:41 +0100 Subject: [Click] dynamic_cast ? Message-ID: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 does anyone know whether this is safe to do in click ? class Foo : public Element { ... } class FooBar : public Foo { ... } Foo::some_method() { Element downstream; downstream = output[0].element(); if ( dynamic_cast(e) ) { ... e is a foo ... } else { .... e is not a foo ... } } I currently have no linuxkernel installation, so I can't check for this case, but I see potential breakage, since this requires a bit of compiler magic. - -- 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 iD8DBQFK8seMy8wrZ9OvkU0RAhuhAJ0eYpMbgkXBKCOHpwThJhAIrz+AxwCfYWmn /6Ym0puh/5mvuSVz6OwYvuc= =2o3a -----END PGP SIGNATURE----- From mneufeld at bbn.com Thu Nov 5 08:49:21 2009 From: mneufeld at bbn.com (Michael Neufeld) Date: Thu, 05 Nov 2009 08:49:21 -0500 Subject: [Click] dynamic_cast ? In-Reply-To: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> References: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> Message-ID: <4AF2D7E1.2010309@bbn.com> Last time I looked Linux kernel mode Click disables RTTI (as well as exceptions), so I wouldn't expect dynamic_cast to work in the Linux kernel. -Mike Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > does anyone know whether this is safe to do in click ? > > class Foo : public Element { ... } > class FooBar : public Foo { ... } > > Foo::some_method() { > Element downstream; > downstream = output[0].element(); > > if ( dynamic_cast(e) ) { > ... e is a foo ... > } else { > .... e is not a foo ... > } > } > > I currently have no linuxkernel installation, so I can't check for this > case, but I see potential breakage, since this requires a bit of > compiler magic. > > - -- > 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 > > iD8DBQFK8seMy8wrZ9OvkU0RAhuhAJ0eYpMbgkXBKCOHpwThJhAIrz+AxwCfYWmn > /6Ym0puh/5mvuSVz6OwYvuc= > =2o3a > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > -- ************************* Michael J. Neufeld, Ph.D. Network Scientist BBN Technologies 10 Moulton St. Cambridge, MA 02138 mneufeld at bbn.com 617-873-1898 http://www.bbn.com ************************** From harald at net.t-labs.tu-berlin.de Thu Nov 5 09:47:27 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Thu, 05 Nov 2009 15:47:27 +0100 Subject: [Click] dynamic_cast ? In-Reply-To: <4AF2D7E1.2010309@bbn.com> References: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> <4AF2D7E1.2010309@bbn.com> Message-ID: <4AF2E57F.6060604@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Neufeld wrote: > Last time I looked Linux kernel mode Click disables RTTI (as well as > exceptions), so I wouldn't expect dynamic_cast to work in the Linux kernel. > > -Mike Thanks, that's what I almost anticipated. Is there any other solution that does the same thing in click, some method of Element that one can use? Basically I need to find out at initialization time whether my neighbor elements are derived from a special subclass of element. The "dirty" way would be to implement a "i_am_foo" handler and check for it's existence.... harald > > Harald Schi?berg wrote: > does anyone know whether this is safe to do in click ? > > class Foo : public Element { ... } > class FooBar : public Foo { ... } > > Foo::some_method() { > Element downstream; > downstream = output[0].element(); > > if ( dynamic_cast(e) ) { > ... e is a foo ... > } else { > .... e is not a foo ... > } > } > > I currently have no linuxkernel installation, so I can't check for this > case, but I see potential breakage, since this requires a bit of > compiler magic. > >> _______________________________________________ click mailing list click at amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> - -- 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 iD8DBQFK8uV/y8wrZ9OvkU0RAlQKAJ455Y1L/Dpjg6rJGsMdQjBNU/H+QQCgy68X KNaJEw1BRaQ1y27PPzaaR5o= =pIrY -----END PGP SIGNATURE----- From kohler at cs.ucla.edu Thu Nov 5 11:12:08 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 05 Nov 2009 08:12:08 -0800 Subject: [Click] dynamic_cast ? In-Reply-To: <4AF2E57F.6060604@net.t-labs.tu-berlin.de> References: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> <4AF2D7E1.2010309@bbn.com> <4AF2E57F.6060604@net.t-labs.tu-berlin.de> Message-ID: <4AF2F958.3070604@cs.ucla.edu> Hi Harald, Click already provides a cast() method on Element that should do what you want. http://www.read.cs.ucla.edu/click/doxygen/classElement.html#e19904c6060f3d4411e32cba0dd2e3c1 So something like Foo *foo = (Foo *) output(0).element()->cast("Foo"); Eddie Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Neufeld wrote: >> Last time I looked Linux kernel mode Click disables RTTI (as well as >> exceptions), so I wouldn't expect dynamic_cast to work in the Linux kernel. >> >> -Mike > > Thanks, that's what I almost anticipated. Is there any other solution > that does the same thing in click, some method of Element that one can > use? Basically I need to find out at initialization time whether my > neighbor elements are derived from a special subclass of element. > > The "dirty" way would be to implement a "i_am_foo" handler and check for > it's existence.... > > harald > >> Harald Schi?berg wrote: >> does anyone know whether this is safe to do in click ? >> >> class Foo : public Element { ... } >> class FooBar : public Foo { ... } >> >> Foo::some_method() { >> Element downstream; >> downstream = output[0].element(); >> >> if ( dynamic_cast(e) ) { >> ... e is a foo ... >> } else { >> .... e is not a foo ... >> } >> } >> >> I currently have no linuxkernel installation, so I can't check for this >> case, but I see potential breakage, since this requires a bit of >> compiler magic. >> > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > - -- > 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 > > iD8DBQFK8uV/y8wrZ9OvkU0RAlQKAJ455Y1L/Dpjg6rJGsMdQjBNU/H+QQCgy68X > KNaJEw1BRaQ1y27PPzaaR5o= > =pIrY > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From nweaver at ICSI.Berkeley.EDU Thu Nov 5 14:02:04 2009 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Thu, 5 Nov 2009 11:02:04 -0800 Subject: [Click] Weird behavior under OSX Snow Leopard... Message-ID: <870845C6-EF7B-4733-BD4C-D79C1351C2B6@ICSI.Berkeley.EDU> I'm seeing some very weird behavior under OSX on FromDevice... The very simple code: FromDevice(en0, PROMISC true) -> Print("en0") -> Queue -> ToDevice(en1); What happens is no packets are received by the Print command until some internal buffer in the FromDevice fills up, and then they are all delivered at once in a big burst, through the queue, and out the en1 interface. Suggestions? From bart.braem at ua.ac.be Fri Nov 6 07:32:11 2009 From: bart.braem at ua.ac.be (Bart Braem) Date: Fri, 6 Nov 2009 13:32:11 +0100 Subject: [Click] packet data compression? In-Reply-To: <6c6bb6f90911020609x661f527ma1430eef88a06497@mail.gmail.com> References: <6c6bb6f90911020609x661f527ma1430eef88a06497@mail.gmail.com> Message-ID: <4E1BA1CA-3A83-41A1-B8B8-97E4E728F606@ua.ac.be> Hi, On 02 Nov 2009, at 15:09, Alastair McKinley wrote: > Does anyone have any experience with compressing packet data from > within or > with click elements? > I had a quick search and didn't see anything, and just wanted to ask > before > possibly re-inventing the wheel. > Is this a feature that other people might be interested in? I do not think much elements exist that perform compression. It will not be easy, as you will want to perform in-place compression to avoid expensive payload copies. But I guess with the right take calls on the packet you will get there. It would be interesting to see an implementation of this, especially an efficient one. Best regards, Bart -- Bart Braem PATS research group - IBBT Dept. of Mathematics and Computer Sciences University of Antwerp Campus Middelheim, G3.27 Middelheimlaan 1 B-2020 Antwerpen, Belgium Phone: +32 (0)3 265.38.82 Fax: +32 (0)3 265.37.77 Web: www.pats.ua.ac.be From bart.braem at ua.ac.be Fri Nov 6 07:37:33 2009 From: bart.braem at ua.ac.be (Bart Braem) Date: Fri, 6 Nov 2009 13:37:33 +0100 Subject: [Click] hashcode confusion In-Reply-To: <6c6bb6f90911050319k7ac9a12fldc076dee608fb611@mail.gmail.com> References: <6c6bb6f90911050319k7ac9a12fldc076dee608fb611@mail.gmail.com> Message-ID: On 05 Nov 2009, at 12:19, Alastair McKinley wrote: > inline size_t EtherPair::hashcode() const { > return CLICK_NAME(hashcode)(_src) + CLICK_NAME(hashcode)(_dst); > > } > > Can someone explain how the hashcode member function works in the > this example? Sure. CLICK_NAME(name) is a macro to do scoping, especially in the ns version of Click. In all other cases, it generates ::name So after macro processing, the line reads: return ::hashcode(_src) + ::hashcode(_dst); and those calls are on the hashcode method of EtherAddress, which can be found in include/click/etheraddress.hh Regards, Bart Braem -- Bart Braem PATS research group - IBBT Dept. of Mathematics and Computer Sciences University of Antwerp Campus Middelheim, G3.27 Middelheimlaan 1 B-2020 Antwerpen, Belgium Phone: +32 (0)3 265.38.82 Fax: +32 (0)3 265.37.77 Web: www.pats.ua.ac.be From sombrutz at informatik.hu-berlin.de Fri Nov 6 08:57:22 2009 From: sombrutz at informatik.hu-berlin.de (Robert Sombrutzki) Date: Fri, 6 Nov 2009 14:57:22 +0100 Subject: [Click] packet data compression? In-Reply-To: <4E1BA1CA-3A83-41A1-B8B8-97E4E728F606@ua.ac.be> References: <6c6bb6f90911020609x661f527ma1430eef88a06497@mail.gmail.com> <4E1BA1CA-3A83-41A1-B8B8-97E4E728F606@ua.ac.be> Message-ID: <200911061457.22794.sombrutz@informatik.hu-berlin.de> Hi, i started to implement such an element some weeks ago. It uses LZW for compression. In the archive, there is a element called packetcompression and a click-file for testing. I agree with Bart, that in-place compression is faster than my current implementation, but the problem is, that the lzw-compression can result in bigger packets and so you would overwrite the data you want to compress. Maybe, it is possible to seperate the comression-part of the click-element in an extra element (like a plugin), so that it can be replace by other method (bzip2,....). Please let me know if you have a implementation of other compression-methods, which can be used for click-element. And also if you have an in-place compression ! Oh, and send an email, if something is not working. Best regards, Robert On Freitag, 6. November 2009, Bart Braem wrote: > Hi, > > On 02 Nov 2009, at 15:09, Alastair McKinley wrote: > > Does anyone have any experience with compressing packet data from > > within or > > with click elements? > > I had a quick search and didn't see anything, and just wanted to ask > > before > > possibly re-inventing the wheel. > > Is this a feature that other people might be interested in? > > I do not think much elements exist that perform compression. > It will not be easy, as you will want to perform in-place compression > to avoid expensive payload copies. But I guess with the right take > calls on the packet you will get there. > It would be interesting to see an implementation of this, especially > an efficient one. > > Best regards, > Bart -------------- next part -------------- A non-text attachment was scrubbed... Name: compression.tar.bz2 Type: application/x-tbz Size: 14061 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091106/9d8c31a2/attachment-0001.bin From harald at net.t-labs.tu-berlin.de Fri Nov 6 10:11:09 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Fri, 06 Nov 2009 16:11:09 +0100 Subject: [Click] dynamic_cast ? In-Reply-To: <4AF2F958.3070604@cs.ucla.edu> References: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> <4AF2D7E1.2010309@bbn.com> <4AF2E57F.6060604@net.t-labs.tu-berlin.de> <4AF2F958.3070604@cs.ucla.edu> Message-ID: <4AF43C8D.7000005@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eddie Kohler wrote: > Hi Harald, > > Click already provides a cast() method on Element that should do what > you want. Thanks a lot, apparently I'm to blind to see the obvious. yet (completly off-topic) this segfaults: int MultiFlowDispatcher::initialize(ErrorHandler * errh ) { int i; for (i=0; i<=1; i++){ if ( input(i).element()->cast("MultiFlowDispatcher") ){ and the debugger tells me that the input has no element (gdb) p input(0) $1 = (const Element::Port &) @0x826d324: {_e = 0x0, _port = -1} are the neighbors not known at initialization time? Is there anything better than this really ugly thing: MultiFlowDispatcher::push( ) { if (!_neighbor_config) do_neighbor_config() } - -- 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 iD8DBQFK9DyNy8wrZ9OvkU0RAsl+AJ4+8Y5EP/j8ZlOt7dG78svoqE+uZgCfbmBu 6CCRyQO7iXU0u1R39ce5nx0= =D1SM -----END PGP SIGNATURE----- From kohler at cs.ucla.edu Mon Nov 9 00:54:50 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sun, 08 Nov 2009 21:54:50 -0800 Subject: [Click] dynamic_cast ? In-Reply-To: <4AF43C8D.7000005@net.t-labs.tu-berlin.de> References: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> <4AF2D7E1.2010309@bbn.com> <4AF2E57F.6060604@net.t-labs.tu-berlin.de> <4AF2F958.3070604@cs.ucla.edu> <4AF43C8D.7000005@net.t-labs.tu-berlin.de> Message-ID: <4AF7AEAA.7080803@cs.ucla.edu> Hi Harald, Click elements don't know what element(s) are connected to a push input port, or a pull output port. This is because it is valid for one or more elements to connect there. So if e->input_is_push(i), then e->input(i).element() == 0. To find the element or elements connected to a push input port, use Router functions to traverse the element graph. I've just checked in a rework of this functionality that should help you. On current mainline, you could say: #include ... ElementNeighborTracker tracker(router()); router()->visit_upstream(this, 0, &tracker); tracker.elements() // is a vector containing exactly those elements // that are connected to [0]this Does this make sense? Eddie Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eddie Kohler wrote: >> Hi Harald, >> >> Click already provides a cast() method on Element that should do what >> you want. > > Thanks a lot, apparently I'm to blind to see the obvious. > > yet (completly off-topic) this segfaults: > > int > MultiFlowDispatcher::initialize(ErrorHandler * errh ) { > > int i; > for (i=0; i<=1; i++){ > if ( input(i).element()->cast("MultiFlowDispatcher") ){ > > > and the debugger tells me that the input has no element > > (gdb) p input(0) > $1 = (const Element::Port &) @0x826d324: {_e = 0x0, _port = -1} > > are the neighbors not known at initialization time? > Is there anything better than this really ugly thing: > > MultiFlowDispatcher::push( ) { > if (!_neighbor_config) > do_neighbor_config() > } > > > - -- > 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 > > iD8DBQFK9DyNy8wrZ9OvkU0RAsl+AJ4+8Y5EP/j8ZlOt7dG78svoqE+uZgCfbmBu > 6CCRyQO7iXU0u1R39ce5nx0= > =D1SM > -----END PGP SIGNATURE----- From harald at net.t-labs.tu-berlin.de Mon Nov 9 06:12:13 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Mon, 09 Nov 2009 12:12:13 +0100 Subject: [Click] dynamic_cast ? In-Reply-To: <4AF7AEAA.7080803@cs.ucla.edu> References: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> <4AF2D7E1.2010309@bbn.com> <4AF2E57F.6060604@net.t-labs.tu-berlin.de> <4AF2F958.3070604@cs.ucla.edu> <4AF43C8D.7000005@net.t-labs.tu-berlin.de> <4AF7AEAA.7080803@cs.ucla.edu> Message-ID: <4AF7F90D.3020207@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eddie Kohler wrote: > Hi Harald, > > Click elements don't know what element(s) are connected to a push input > port, or a pull output port. This is because it is valid for one or > more elements to connect there. > > So if e->input_is_push(i), then e->input(i).element() == 0. > > To find the element or elements connected to a push input port, use > Router functions to traverse the element graph. I've just checked in a > rework of this functionality that should help you. On current mainline, > you could say: > > #include > ... > ElementNeighborTracker tracker(router()); > router()->visit_upstream(this, 0, &tracker); > tracker.elements() // is a vector containing exactly those elements > // that are connected to [0]this > > Does this make sense? Thanks a lot, works and makes perfect sense. attached a small patch that I found very useful when using that stuff... 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 iD8DBQFK9/kNy8wrZ9OvkU0RAhdPAJ9AsxLZpBnJGxxcZ7lbj7AiDcy6NQCgvliE B0JdVik2y+79tH655btbJBI= =zGnz -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: elementtracker_clear.diff Type: text/x-diff Size: 981 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091109/de07819c/attachment.diff From kohler at cs.ucla.edu Mon Nov 9 10:48:09 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Mon, 09 Nov 2009 07:48:09 -0800 Subject: [Click] dynamic_cast ? In-Reply-To: <4AF7F90D.3020207@net.t-labs.tu-berlin.de> References: <4AF2C78D.4020905@net.t-labs.tu-berlin.de> <4AF2D7E1.2010309@bbn.com> <4AF2E57F.6060604@net.t-labs.tu-berlin.de> <4AF2F958.3070604@cs.ucla.edu> <4AF43C8D.7000005@net.t-labs.tu-berlin.de> <4AF7AEAA.7080803@cs.ucla.edu> <4AF7F90D.3020207@net.t-labs.tu-berlin.de> Message-ID: <4AF839B9.4020700@cs.ucla.edu> Harald, thanks -- I'll check a variant of this in! But clear() functions generally return void, and so will this one. Eddie Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eddie Kohler wrote: >> Hi Harald, >> >> Click elements don't know what element(s) are connected to a push input >> port, or a pull output port. This is because it is valid for one or >> more elements to connect there. >> >> So if e->input_is_push(i), then e->input(i).element() == 0. >> >> To find the element or elements connected to a push input port, use >> Router functions to traverse the element graph. I've just checked in a >> rework of this functionality that should help you. On current mainline, >> you could say: >> >> #include >> ... >> ElementNeighborTracker tracker(router()); >> router()->visit_upstream(this, 0, &tracker); >> tracker.elements() // is a vector containing exactly those elements >> // that are connected to [0]this >> >> Does this make sense? > > Thanks a lot, works and makes perfect sense. > > attached a small patch that I found very useful when using that stuff... > > 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 > > iD8DBQFK9/kNy8wrZ9OvkU0RAhdPAJ9AsxLZpBnJGxxcZ7lbj7AiDcy6NQCgvliE > B0JdVik2y+79tH655btbJBI= > =zGnz > -----END PGP SIGNATURE----- > From kohler at cs.ucla.edu Mon Nov 9 20:02:28 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Mon, 09 Nov 2009 17:02:28 -0800 Subject: [Click] very strange compilation error In-Reply-To: <4AE85231.4020604@net.t-labs.tu-berlin.de> References: <4AE85231.4020604@net.t-labs.tu-berlin.de> Message-ID: <4AF8BBA4.2010006@cs.ucla.edu> Hi Harald, What you're missing is "friend class Master" in class Timer. So the compiler should totally allow this. It's very odd if it doesn't. There is a miniscule chance that adding "class Master;" to the top of the timer.hh header, after the other "class" mentions, would help. Eddie Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > this looks really strange: (userlevel build for mips) > > In file included from ../lib/task.cc:26: > ../include/click/master.hh: In member function `void > Master::timer_place::operator()(Timer**)': > ../include/click/timer.hh:253: error: `int Timer::_schedpos1' is private > ../include/click/master.hh:147: error: within this context > > the compiler is totally right here, so why did that always work for me > in the first place ? Or am I just completely stupid ? > Tested with a few recent versions from git. > > > 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 > > iD8DBQFK6FIxy8wrZ9OvkU0RAqF5AKDjkukQzacMZEj1FF4JX5HrcZ/hcACg2Snp > 2HrZssFRrNOUkxuITUrQtF4= > =Rspg > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Mon Nov 9 22:48:10 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Mon, 09 Nov 2009 19:48:10 -0800 Subject: [Click] [resend] [PATCH] Add OFFSET to CheckIP6Header In-Reply-To: <200908151646.24337.buchholz@cs.tu-berlin.de> References: <200908151646.24337.buchholz@cs.tu-berlin.de> Message-ID: <4AF8E27A.1090609@cs.ucla.edu> Hi Robert, Thanks so much for your patience -- I finally applied this patch. I edited it very slightly: in one place, you need to cast plen to unsigned to catch all error situations. Again, thanks!! Eddie Robert Buchholz wrote: > Patch that I sent in in April, still applies fine. > > > Robert > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Nov 10 04:46:49 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Tue, 10 Nov 2009 10:46:49 +0100 Subject: [Click] very strange compilation error In-Reply-To: <4AF8BBA4.2010006@cs.ucla.edu> References: <4AE85231.4020604@net.t-labs.tu-berlin.de> <4AF8BBA4.2010006@cs.ucla.edu> Message-ID: <4AF93689.50401@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eddie Kohler wrote: > Hi Harald, > > What you're missing is "friend class Master" in class Timer. So the > compiler should totally allow this. It's very odd if it doesn't. indeed it is. probably some strange bug of gcc3.4.6 that openwrt uses to build for the ancient wrt54gl. interesting though: this is the only breakage in all of click, making _schedpos1 public allows a clean build. don't fix upstream, we'll work around in this specific configuration. > There is a miniscule chance that adding "class Master;" to the top of > the timer.hh header, after the other "class" mentions, would help. nope, doesn't help. thanks for your effort, harald side note: that hardware starts to drive me crazy, completely odd behavior of userlevel click in FromDevice(eth0.1, CAPTURE LINUX) in conjunction with the broken proprietary drivers for the internal broadcom vlan switch. need get new hardware even for teaching ;-) - -- 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 iD8DBQFK+TaIy8wrZ9OvkU0RAj0WAJ9BZFORTP6zOyKCfPu5oNdwR3SuIgCdGmLD Im3ZgciCxi8RMWltiFSSS54= =+YTU -----END PGP SIGNATURE----- From kirchho at cs.uni-bonn.de Thu Nov 12 05:27:56 2009 From: kirchho at cs.uni-bonn.de (Jonathan Kirchhoff) Date: Thu, 12 Nov 2009 11:27:56 +0100 Subject: [Click] NSClick performance issues Message-ID: <4AFBE32C.7050401@cs.uni-bonn.de> Hi, I'm doing simulations of wireless ad-hoc routing protocols using nsclick. Everything appears to be working just fine, but in comparison to native NS-2 simulations, the ones using nsclick seem to be taking ages to finish. Here's an example: Native : 02:14min Nsclick: 12:34min Same protocol, scenario and simulated time. Is this something to be expected, or is the reason more likely to be found in my protocol implementation or simulation setup? Thanks! Regards Jonathan From sombrutz at informatik.hu-berlin.de Thu Nov 12 07:28:55 2009 From: sombrutz at informatik.hu-berlin.de (Robert Sombrutzki) Date: Thu, 12 Nov 2009 13:28:55 +0100 Subject: [Click] NSClick performance issues In-Reply-To: <4AFBE32C.7050401@cs.uni-bonn.de> References: <4AFBE32C.7050401@cs.uni-bonn.de> Message-ID: <200911121328.55268.sombrutz@informatik.hu-berlin.de> Hi, i attach 1 patch which can improve the performance (patch for the scheduler). Please take a look for detailed information. Please let me know, whether it helps in your case (if you use it). Best regards, Robert Last thing: the patch is for ns-2.30 (ns-allinone-2.30). On Donnerstag, 12. November 2009, Jonathan Kirchhoff wrote: > Hi, > > I'm doing simulations of wireless ad-hoc routing protocols using > nsclick. Everything appears to be working just fine, but in comparison > to native NS-2 simulations, the ones using nsclick seem to be taking > ages to finish. Here's an example: > > Native : 02:14min > Nsclick: 12:34min > > Same protocol, scenario and simulated time. > > Is this something to be expected, or is the reason more likely to be > found in my protocol implementation or simulation setup? > > Thanks! > > Regards > Jonathan > _______________________________________________ > 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: ns-2.30-001-scheduler.patch Type: text/x-diff Size: 10592 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091112/9cbd7016/attachment.patch From kirchho at cs.uni-bonn.de Fri Nov 13 05:05:46 2009 From: kirchho at cs.uni-bonn.de (Jonathan Kirchhoff) Date: Fri, 13 Nov 2009 11:05:46 +0100 Subject: [Click] NSClick performance issues In-Reply-To: <200911121328.55268.sombrutz@informatik.hu-berlin.de> References: <4AFBE32C.7050401@cs.uni-bonn.de> <200911121328.55268.sombrutz@informatik.hu-berlin.de> Message-ID: <4AFD2F7A.4020808@cs.uni-bonn.de> Hi Robert, Apperently, the changes described in your patch are already part of NS-2.33, which I am currently using. By the way, I'm using a recent git checkout of Click. Thank you for sending the patch, though! Regards Jonathan Am 12.11.09 13:28, schrieb Robert Sombrutzki: > Hi, > i attach 1 patch which can improve the performance (patch for the scheduler). > Please take a look for detailed information. Please let me know, whether it > helps in your case (if you use it). > > Best regards, > Robert > > Last thing: the patch is for ns-2.30 (ns-allinone-2.30). > > On Donnerstag, 12. November 2009, Jonathan Kirchhoff wrote: >> Hi, >> >> I'm doing simulations of wireless ad-hoc routing protocols using >> nsclick. Everything appears to be working just fine, but in comparison >> to native NS-2 simulations, the ones using nsclick seem to be taking >> ages to finish. Here's an example: >> >> Native : 02:14min >> Nsclick: 12:34min >> >> Same protocol, scenario and simulated time. >> >> Is this something to be expected, or is the reason more likely to be >> found in my protocol implementation or simulation setup? >> >> Thanks! >> >> Regards >> Jonathan >> _______________________________________________ >> 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 Nov 13 17:12:09 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 13 Nov 2009 14:12:09 -0800 Subject: [Click] click autoconf seems somewhat bugged In-Reply-To: <4AEED499.9000303@net.t-labs.tu-berlin.de> References: <4AEED499.9000303@net.t-labs.tu-berlin.de> Message-ID: <4AFDD9B9.7020205@cs.ucla.edu> Hi Harald, It turns out this si a problem caused by a small behavior change in autoconf-2.64. It's fixed in http://www.read.cs.ucla.edu/gitweb?p=click;a=commit;h=71cf387f681707a0d2ea8ad8b30f758c4100b3b2 Thanks! Eddie Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > very wired behaviour of the git-sources on ubuntu-karmic: > > harald at harald-vbox:~/src/click$ ./configure > '--prefix=/home/harald/local/DIR/click' '--enable-userlevel' > '--enable-local' '--enable-wifi' '--disable-linuxmodule' > checking build system type... i686-pc-linux-gnu > [...] > config.status: executing default-1 commands > > everything fine so far > > harald at harald-vbox:~/src/click$ make -j3 > cd . && : && autoconf > /bin/bash ./configure '--prefix=/home/harald/local/DIR/click' > '--enable-userlevel' '--enable-local' '--en > able-wifi' '--disable-linuxmodule' > checking build system type... i686-pc-linux-gnu > [...] > checking for expat.h... yes > checking for XML_ParserCreateNS in -lexpat... yes > ./configure: line 12359: syntax error: unexpected end of file > make: *** [config.status] Error 2 > > tried with default autoconf (2.64) and 2.59, same results. > re-running ./configure from this point on will fail. > > probably it's not autoconf's fault, but maybe I'm missing some > dependency, but I feel unable to find out what it could possibly be. > > bottom line: after running autoconf, configure won't run anymore.... > > apt-get remove autoconf -> > click will build just fine. > > > - -- > 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 > > iD8DBQFK7tSYy8wrZ9OvkU0RAivqAJ0QYiu2iEyncbv1/43T8h2+LBE3mgCfbFkZ > zk+0/5Rr4754ezW8Ul6jYSg= > =tU0M > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Sun Nov 15 09:51:13 2009 From: harald at net.t-labs.tu-berlin.de (Harald Schioeberg) Date: Sun, 15 Nov 2009 15:51:13 +0100 Subject: [Click] StoreIPAddress not 64bit safe Message-ID: <4B001561.5050508@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 this segfaults on amd64 in StoreIPAddress::simple_action RatedSource("some data", 1, 1, STOP true) -> UDPIPEncap(1.0.0.1, 1234, 2.0.0.2, 1234) -> StoreIPAddress(3.0.0.3, dst) -> CheckIPHeader -> // verify that incremental csum still work IPPrint -> Discard ; the attached patch makes the thing work as expected: $ ./userlevel/click ./conf/storeip.click 1258295906.133130: 1.0.0.1.1234 > 3.0.0.3.1234: udp 17 harald ps. "_offset = (unsigned) -16" ... interesting magic ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksAFWEACgkQy8wrZ9OvkU2bmwCgnootnZagzBTcZ2+uSWJ1pXLs 7kEAn0VrgtbM6S/9L/CxUQhCZwNZNdjT =CvEk -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: storeip_64bit.patch Type: text/x-patch Size: 623 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091115/2a67c70c/attachment.bin From kohler at cs.ucla.edu Sun Nov 15 18:32:08 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Sun, 15 Nov 2009 15:32:08 -0800 Subject: [Click] StoreIPAddress not 64bit safe In-Reply-To: <4B001561.5050508@net.t-labs.tu-berlin.de> References: <4B001561.5050508@net.t-labs.tu-berlin.de> Message-ID: <4B008F78.9070202@cs.ucla.edu> Ouch, thanks! A version of this patch is applied -- it actually goes ahead and makes _offset an integer variable. E Harald Schioeberg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > this segfaults on amd64 in StoreIPAddress::simple_action > > RatedSource("some data", 1, 1, STOP true) -> > UDPIPEncap(1.0.0.1, 1234, 2.0.0.2, 1234) -> > StoreIPAddress(3.0.0.3, dst) -> > CheckIPHeader -> // verify that incremental csum still work > IPPrint -> > Discard ; > > > the attached patch makes the thing work as expected: > > $ ./userlevel/click ./conf/storeip.click > 1258295906.133130: 1.0.0.1.1234 > 3.0.0.3.1234: udp 17 > > harald > > ps. "_offset = (unsigned) -16" ... interesting magic ;-) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAksAFWEACgkQy8wrZ9OvkU2bmwCgnootnZagzBTcZ2+uSWJ1pXLs > 7kEAn0VrgtbM6S/9L/CxUQhCZwNZNdjT > =CvEk > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From amckinley03 at googlemail.com Mon Nov 16 19:46:45 2009 From: amckinley03 at googlemail.com (Alastair McKinley) Date: Tue, 17 Nov 2009 00:46:45 +0000 Subject: [Click] [PATCH]: radiotapdecap.cc: pull the correct amount of bytes on big-endian Message-ID: <6c6bb6f90911161646x3045b984lf8a3214393ae7a7@mail.gmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Pull-the-correct-amount-of-bytes-on-big-endian.patch Type: text/x-patch Size: 799 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091117/58acb33e/attachment.bin From dennis_d at yahoo.cn Wed Nov 18 08:14:00 2009 From: dennis_d at yahoo.cn (=?gb2312?B?tsXJ0PbOICA=?=) Date: Wed, 18 Nov 2009 21:14:00 +0800 (CST) Subject: [Click] complie error of roofnet packages Message-ID: <869677.51931.qm@web92413.mail.cnh.yahoo.com> when I complie the click use the configure "--enable-roofnet", it comes error like this: fragmentresender.o: In function `~FragmentResender': /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:96: undefined reference to `Vector::~Vector()' /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:96: undefined reference to `Vector::~Vector()' /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:96: undefined reference to `Vector::~Vector()' fragmentresender.o: In function `bubble_sort(Vector*)': /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:57: undefined reference to `Vector::Vector(Vector const&)' /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:57: undefined reference to `Vector::~Vector()' /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:57: undefined reference to `Vector::~Vector()' fragmentresender.o: In function `FragmentResender::print_window()': /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:249: undefined reference to `Vector::Vector(Vector const&)' /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:249: undefined reference to `Vector::~Vector()' /home/dennis/clickPC/userlevel/../elements/roofnet/frag/fragmentresender.cc:249: undefined reference to `Vector::~Vector()' Does anybody have any idea about what's goning wrong? thx a lot. ________________________________ Du Shangxin Wireless Information Security Lab Department of Information Security Shanghai Jiao Tong University Shanghai, 200240, China Tel:+8613918145825 Email: dennis_d at yahoo.cn ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ From roberto.riggio at create-net.org Wed Nov 18 13:31:15 2009 From: roberto.riggio at create-net.org (Roberto Riggio) Date: Wed, 18 Nov 2009 19:31:15 +0100 Subject: [Click] Problem with KernetTun Message-ID: <4B043D73.9040006@create-net.org> Hi, after the last commit to KernelTun i'm getting the following error when I try to cross-compile click with openwrt (both ixp4xx and x86 targets). CXX ../elements/userlevel/kerneltun.cc ../elements/userlevel/kerneltun.cc: In member function 'int KernelTun::updown(IPAddress, IPAddress, ErrorHandler*)': ../elements/userlevel/kerneltun.cc:262: error: array bound is not an integer constant gcc version is 4.1.2. From luca.belforte at student.uclouvain.be Wed Nov 18 15:08:06 2009 From: luca.belforte at student.uclouvain.be (Luca Belforte) Date: Wed, 18 Nov 2009 21:08:06 +0100 Subject: [Click] Using userlevel-click to forward packet Message-ID: <4B045426.3000204@student.uclouvain.be> Hello, i have a xorp+click installation, who works, click receive the correct routes. But if i want to do a ping, or traceroute it still use the kernel route informations. I tried to disable the SNIFFING mode, but without success. How can i use click to route packet coming from the system? Thanks in advance Luca From gautam.h.thaker at lmco.com Wed Nov 18 16:37:01 2009 From: gautam.h.thaker at lmco.com (Gautam Thaker) Date: Wed, 18 Nov 2009 16:37:01 -0500 Subject: [Click] using click scripts in "ns" simulator Message-ID: <4B0468FD.3060306@atl.lmco.com> I am running ns-2.34 w/ the patch that permits click configurations to be tested under "ns". It appears that only nodes of types Node/MobileNode/ClickNode can be used. Does anyone know if this restriction would be very hard to overcome? Would this be a huge effort ( I could try it if well scoped.) Thanks. GHT From bcronje at gmail.com Thu Nov 19 02:17:43 2009 From: bcronje at gmail.com (Beyers Cronje) Date: Thu, 19 Nov 2009 09:17:43 +0200 Subject: [Click] Using userlevel-click to forward packet In-Reply-To: <4B045426.3000204@student.uclouvain.be> References: <4B045426.3000204@student.uclouvain.be> Message-ID: <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> Hi Luca, Theoretically using FromDevice with "SNIFFER false" then the kernel should not process the packets. Beyers On Wed, Nov 18, 2009 at 10:08 PM, Luca Belforte < luca.belforte at student.uclouvain.be> wrote: > Hello, > > i have a xorp+click installation, who works, click receive the correct > routes. > But if i want to do a ping, or traceroute it still use the kernel route > informations. > I tried to disable the SNIFFING mode, but without success. > > How can i use click to route packet coming from the system? > > Thanks in advance > > Luca > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From luca.belforte at student.uclouvain.be Thu Nov 19 11:35:07 2009 From: luca.belforte at student.uclouvain.be (Luca Belforte) Date: Thu, 19 Nov 2009 17:35:07 +0100 Subject: [Click] Using userlevel-click to forward packet In-Reply-To: <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> References: <4B045426.3000204@student.uclouvain.be> <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> Message-ID: <4B0573BB.3090200@student.uclouvain.be> Hi Beyers, yes theoretically, but my problem is different. If y delete all the ip route in the kernel (ip route flush all) so I'm sure the kernel can't help. Then ping command doesn't work. My question is more how force click to process the who coming from the system itself? (like a ping or traceroute command) Or opposite how to be sure that click process it? thanks Luca Beyers Cronje wrote: > Hi Luca, > > Theoretically using FromDevice with "SNIFFER false" then the kernel > should not process the packets. > > Beyers > > On Wed, Nov 18, 2009 at 10:08 PM, Luca Belforte > > wrote: > > Hello, > > i have a xorp+click installation, who works, click receive the correct > routes. > But if i want to do a ping, or traceroute it still use the kernel > route > informations. > I tried to disable the SNIFFING mode, but without success. > > How can i use click to route packet coming from the system? > > Thanks in advance > > Luca > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > From luca.belforte at student.uclouvain.be Thu Nov 19 13:10:31 2009 From: luca.belforte at student.uclouvain.be (Luca Belforte) Date: Thu, 19 Nov 2009 19:10:31 +0100 Subject: [Click] Using userlevel-click to forward packet In-Reply-To: <4B0573BB.3090200@student.uclouvain.be> References: <4B045426.3000204@student.uclouvain.be> <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> <4B0573BB.3090200@student.uclouvain.be> Message-ID: <4B058A17.8080703@student.uclouvain.be> I put here my click configuration I'm using click 1.7 because the 1.6 doesn't work with xorp // // Generated by XORP FEA // // Shared IPv4 input path and routing table _xorp_ip4 :: Strip(14) -> CheckIPHeader(INTERFACES 10.10.10.11/24 10.30.30.10/24) -> _xorp_rt4 :: LinearIPLookup(10.10.10.11/32 2, 10.30.30.10/32 2); // ARP responses are copied to each ARPQuerier and the host. _xorp_arpt :: Tee(3); // Input and output paths for eth1 FromDevice(eth1, SNIFFER false) -> _xorp_c0 :: Classifier( 12/0800, // [0] IPv4 packet 12/0806 20/0001, // [1] ARP request 12/0806 20/0002, // [2] ARP reply 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment 12/86dd, // [5] IPv6 packet -) // [6] Unsupported protocol; _xorp_out0 :: Queue(200) -> _xorp_to_device0 :: ToDevice(eth1); // IPv4 _xorp_c0[0] -> Paint(1) -> _xorp_ip4; _xorp_c0[1] -> ARPResponder(10.10.10.11 8:0:27:23:1a:29) -> _xorp_out0; _xorp_arpq0 :: ARPQuerier(10.10.10.11, 8:0:27:23:1a:29) -> _xorp_out0; _xorp_c0[2] -> _xorp_arpt; _xorp_arpt[0] -> [1]_xorp_arpq0; // Discard IPv6 _xorp_c0[5] -> Discard; _xorp_c0[3] -> Discard; _xorp_c0[4] -> Discard; // Unknown protocol _xorp_c0[6] -> Print("eth1 unknown protocol") -> Discard; // Input and output paths for eth2 FromDevice(eth2, SNIFFER false) -> _xorp_c1 :: Classifier( 12/0800, // [0] IPv4 packet 12/0806 20/0001, // [1] ARP request 12/0806 20/0002, // [2] ARP reply 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment 12/86dd, // [5] IPv6 packet -) // [6] Unsupported protocol; _xorp_out1 :: Queue(200) -> _xorp_to_device1 :: ToDevice(eth2); // IPv4 _xorp_c1[0] -> Paint(2) -> _xorp_ip4; _xorp_c1[1] -> ARPResponder(10.30.30.10 8:0:27:2b:ed:3f) -> _xorp_out1; _xorp_arpq1 :: ARPQuerier(10.30.30.10, 8:0:27:2b:ed:3f) -> _xorp_out1; _xorp_c1[2] -> _xorp_arpt; _xorp_arpt[1] -> [1]_xorp_arpq1; // Discard IPv6 _xorp_c1[5] -> Discard; _xorp_c1[3] -> Discard; _xorp_c1[4] -> Discard; // Unknown protocol _xorp_c1[6] -> Print("eth2 unknown protocol") -> Discard; // Local delivery _xorp_toh :: Discard; // IPv4 _xorp_rt4[2] -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2) -> _xorp_toh; _xorp_arpt[2] -> _xorp_toh; // Forwarding path for eth1 // IPv4 _xorp_rt4[0] -> DropBroadcasts -> _xorp_cp0 :: PaintTee(1) -> _xorp_gio0 :: IPGWOptions(10.10.10.11) -> FixIPSrc(10.10.10.11) -> _xorp_dt0 :: DecIPTTL -> _xorp_fr0 :: IPFragmenter(1500) -> [0]_xorp_arpq0; _xorp_dt0[1] -> ICMPError(10.10.10.11, timeexceeded) -> _xorp_rt4; _xorp_fr0[1] -> ICMPError(10.10.10.11, unreachable, needfrag) -> _xorp_rt4; _xorp_gio0[1] -> ICMPError(10.10.10.11, parameterproblem) -> _xorp_rt4; _xorp_cp0[1] -> ICMPError(10.10.10.11, redirect, host) -> _xorp_rt4; // Forwarding path for eth2 // IPv4 _xorp_rt4[1] -> DropBroadcasts -> _xorp_cp1 :: PaintTee(2) -> _xorp_gio1 :: IPGWOptions(10.30.30.10) -> FixIPSrc(10.30.30.10) -> _xorp_dt1 :: DecIPTTL -> _xorp_fr1 :: IPFragmenter(1500) -> [0]_xorp_arpq1; _xorp_dt1[1] -> ICMPError(10.30.30.10, timeexceeded) -> _xorp_rt4; _xorp_fr1[1] -> ICMPError(10.30.30.10, unreachable, needfrag) -> _xorp_rt4; _xorp_gio1[1] -> ICMPError(10.30.30.10, parameterproblem) -> _xorp_rt4; _xorp_cp1[1] -> ICMPError(10.30.30.10, redirect, host) -> _xorp_rt4; And here we can see the correct routing table: 10.10.10.11/32 - 2 10.30.30.10/32 - 2 10.10.10.0/24 - 0 10.30.30.0/24 - 1 10.20.20.0/24 10.10.10.10 0 (the subnet 10.20.20.0/24 come from the other router connected) So click know it. But if i do a : ping 10.20.20.10 (who exist) i have the following message: connect: Network is unreachable The connect command doesn't know the click route :( I really don't know what do Thanks Luca Luca Belforte wrote: > Hi Beyers, > > yes theoretically, but my problem is different. If y delete all the ip > route in the kernel (ip route flush all) so I'm sure the kernel can't > help. Then ping command doesn't work. > > My question is more how force click to process the who coming from the > system itself? (like a ping or traceroute command) > > Or opposite how to be sure that click process it? > > thanks > > Luca > > Beyers Cronje wrote: > >> Hi Luca, >> >> Theoretically using FromDevice with "SNIFFER false" then the kernel >> should not process the packets. >> >> Beyers >> >> On Wed, Nov 18, 2009 at 10:08 PM, Luca Belforte >> > > wrote: >> >> Hello, >> >> i have a xorp+click installation, who works, click receive the correct >> routes. >> But if i want to do a ping, or traceroute it still use the kernel >> route >> informations. >> I tried to disable the SNIFFING mode, but without success. >> >> How can i use click to route packet coming from the system? >> >> Thanks in advance >> >> Luca >> _______________________________________________ >> 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 Thu Nov 19 13:34:10 2009 From: cliff at meraki.com (Cliff Frey) Date: Thu, 19 Nov 2009 10:34:10 -0800 Subject: [Click] Using userlevel-click to forward packet In-Reply-To: <4B058A17.8080703@student.uclouvain.be> References: <4B045426.3000204@student.uclouvain.be> <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> <4B0573BB.3090200@student.uclouvain.be> <4B058A17.8080703@student.uclouvain.be> Message-ID: Luca, You need to add a FromHost element to your config which will receive packets from Linux, and a ToHost element that will deliver packets to Linux. Cliff On Thu, Nov 19, 2009 at 10:10 AM, Luca Belforte < luca.belforte at student.uclouvain.be> wrote: > I put here my click configuration > > I'm using click 1.7 because the 1.6 doesn't work with xorp > > // > // Generated by XORP FEA > // > > > // Shared IPv4 input path and routing table > > _xorp_ip4 :: Strip(14) > -> CheckIPHeader(INTERFACES 10.10.10.11/24 10.30.30.10/24) > -> _xorp_rt4 :: LinearIPLookup(10.10.10.11/32 2, 10.30.30.10/32 2); > > > // ARP responses are copied to each ARPQuerier and the host. > > _xorp_arpt :: Tee(3); > > > // Input and output paths for eth1 > > FromDevice(eth1, SNIFFER false) -> _xorp_c0 :: Classifier( > 12/0800, // [0] IPv4 packet > 12/0806 20/0001, // [1] ARP request > 12/0806 20/0002, // [2] ARP reply > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment > 12/86dd, // [5] IPv6 packet > -) // [6] Unsupported protocol; > _xorp_out0 :: Queue(200) -> _xorp_to_device0 :: ToDevice(eth1); > > // IPv4 > _xorp_c0[0] -> Paint(1) -> _xorp_ip4; > _xorp_c0[1] -> ARPResponder(10.10.10.11 8:0:27:23:1a:29) -> _xorp_out0; > _xorp_arpq0 :: ARPQuerier(10.10.10.11, 8:0:27:23:1a:29) -> _xorp_out0; > _xorp_c0[2] -> _xorp_arpt; > _xorp_arpt[0] -> [1]_xorp_arpq0; > > // Discard IPv6 > _xorp_c0[5] -> Discard; > _xorp_c0[3] -> Discard; > _xorp_c0[4] -> Discard; > > // Unknown protocol > _xorp_c0[6] -> Print("eth1 unknown protocol") -> Discard; > > > // Input and output paths for eth2 > > FromDevice(eth2, SNIFFER false) -> _xorp_c1 :: Classifier( > 12/0800, // [0] IPv4 packet > 12/0806 20/0001, // [1] ARP request > 12/0806 20/0002, // [2] ARP reply > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment > 12/86dd, // [5] IPv6 packet > -) // [6] Unsupported protocol; > _xorp_out1 :: Queue(200) -> _xorp_to_device1 :: ToDevice(eth2); > > // IPv4 > _xorp_c1[0] -> Paint(2) -> _xorp_ip4; > _xorp_c1[1] -> ARPResponder(10.30.30.10 8:0:27:2b:ed:3f) -> _xorp_out1; > _xorp_arpq1 :: ARPQuerier(10.30.30.10, 8:0:27:2b:ed:3f) -> _xorp_out1; > _xorp_c1[2] -> _xorp_arpt; > _xorp_arpt[1] -> [1]_xorp_arpq1; > > // Discard IPv6 > _xorp_c1[5] -> Discard; > _xorp_c1[3] -> Discard; > _xorp_c1[4] -> Discard; > > // Unknown protocol > _xorp_c1[6] -> Print("eth2 unknown protocol") -> Discard; > > > // Local delivery > > _xorp_toh :: Discard; > > // IPv4 > _xorp_rt4[2] -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2) -> > _xorp_toh; > _xorp_arpt[2] -> _xorp_toh; > > > // Forwarding path for eth1 > > // IPv4 > _xorp_rt4[0] -> DropBroadcasts > -> _xorp_cp0 :: PaintTee(1) > -> _xorp_gio0 :: IPGWOptions(10.10.10.11) > -> FixIPSrc(10.10.10.11) > -> _xorp_dt0 :: DecIPTTL > -> _xorp_fr0 :: IPFragmenter(1500) > -> [0]_xorp_arpq0; > _xorp_dt0[1] -> ICMPError(10.10.10.11, timeexceeded) -> _xorp_rt4; > _xorp_fr0[1] -> ICMPError(10.10.10.11, unreachable, needfrag) -> > _xorp_rt4; > _xorp_gio0[1] -> ICMPError(10.10.10.11, parameterproblem) -> _xorp_rt4; > _xorp_cp0[1] -> ICMPError(10.10.10.11, redirect, host) -> _xorp_rt4; > > > // Forwarding path for eth2 > > // IPv4 > _xorp_rt4[1] -> DropBroadcasts > -> _xorp_cp1 :: PaintTee(2) > -> _xorp_gio1 :: IPGWOptions(10.30.30.10) > -> FixIPSrc(10.30.30.10) > -> _xorp_dt1 :: DecIPTTL > -> _xorp_fr1 :: IPFragmenter(1500) > -> [0]_xorp_arpq1; > _xorp_dt1[1] -> ICMPError(10.30.30.10, timeexceeded) -> _xorp_rt4; > _xorp_fr1[1] -> ICMPError(10.30.30.10, unreachable, needfrag) -> > _xorp_rt4; > _xorp_gio1[1] -> ICMPError(10.30.30.10, parameterproblem) -> _xorp_rt4; > _xorp_cp1[1] -> ICMPError(10.30.30.10, redirect, host) -> _xorp_rt4; > > > And here we can see the correct routing table: > 10.10.10.11/32 - 2 > 10.30.30.10/32 - 2 > 10.10.10.0/24 - 0 > 10.30.30.0/24 - 1 > 10.20.20.0/24 10.10.10.10 0 > > (the subnet 10.20.20.0/24 come from the other router connected) > > So click know it. > > But if i do a : > > ping 10.20.20.10 (who exist) i have the following message: > connect: Network is unreachable > > The connect command doesn't know the click route :( > > I really don't know what do > > Thanks > > Luca > > Luca Belforte wrote: > > Hi Beyers, > > > > yes theoretically, but my problem is different. If y delete all the ip > > route in the kernel (ip route flush all) so I'm sure the kernel can't > > help. Then ping command doesn't work. > > > > My question is more how force click to process the who coming from the > > system itself? (like a ping or traceroute command) > > > > Or opposite how to be sure that click process it? > > > > thanks > > > > Luca > > > > Beyers Cronje wrote: > > > >> Hi Luca, > >> > >> Theoretically using FromDevice with "SNIFFER false" then the kernel > >> should not process the packets. > >> > >> Beyers > >> > >> On Wed, Nov 18, 2009 at 10:08 PM, Luca Belforte > >> >> > wrote: > >> > >> Hello, > >> > >> i have a xorp+click installation, who works, click receive the > correct > >> routes. > >> But if i want to do a ping, or traceroute it still use the kernel > >> route > >> informations. > >> I tried to disable the SNIFFING mode, but without success. > >> > >> How can i use click to route packet coming from the system? > >> > >> Thanks in advance > >> > >> Luca > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From cliff at meraki.com Thu Nov 19 13:56:07 2009 From: cliff at meraki.com (Cliff Frey) Date: Thu, 19 Nov 2009 10:56:07 -0800 Subject: [Click] Using userlevel-click to forward packet In-Reply-To: <4B059311.5000800@student.uclouvain.be> References: <4B045426.3000204@student.uclouvain.be> <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> <4B0573BB.3090200@student.uclouvain.be> <4B058A17.8080703@student.uclouvain.be> <4B059311.5000800@student.uclouvain.be> Message-ID: Luca, Please respond to the mailing list so that other people can help out too. I believe that there is an example online: http://read.cs.ucla.edu/click/examples/fromhost-tunnel.click In some cases you can get away with just using ToHost... like in most of the other examples. On Thu, Nov 19, 2009 at 10:48 AM, Luca Belforte < luca.belforte at student.uclouvain.be> wrote: > Hello Cliff, > > thanks, this sound what i was searching for. (Strange that the xorp > generator script doesn't use it) > > Did you have an example on how i can configure it? > > Thanks > > Luca > > > Cliff Frey wrote: > > Luca, > > > > You need to add a FromHost element to your config which will receive > > packets from Linux, and a ToHost element that will deliver packets to > > Linux. > > > > Cliff > > > > On Thu, Nov 19, 2009 at 10:10 AM, Luca Belforte > > > > wrote: > > > > I put here my click configuration > > > > I'm using click 1.7 because the 1.6 doesn't work with xorp > > > > // > > // Generated by XORP FEA > > // > > > > > > // Shared IPv4 input path and routing table > > > > _xorp_ip4 :: Strip(14) > > -> CheckIPHeader(INTERFACES 10.10.10.11/24 > > 10.30.30.10/24 ) > > -> _xorp_rt4 :: LinearIPLookup(10.10.10.11/32 > > 2, 10.30.30.10/32 > 2); > > > > > > // ARP responses are copied to each ARPQuerier and the host. > > > > _xorp_arpt :: Tee(3); > > > > > > // Input and output paths for eth1 > > > > FromDevice(eth1, SNIFFER false) -> _xorp_c0 :: Classifier( > > 12/0800, // [0] IPv4 packet > > 12/0806 20/0001, // [1] ARP request > > 12/0806 20/0002, // [2] ARP reply > > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation > > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment > > 12/86dd, // [5] IPv6 packet > > -) // [6] Unsupported protocol; > > _xorp_out0 :: Queue(200) -> _xorp_to_device0 :: ToDevice(eth1); > > > > // IPv4 > > _xorp_c0[0] -> Paint(1) -> _xorp_ip4; > > _xorp_c0[1] -> ARPResponder(10.10.10.11 8:0:27:23:1a:29) -> > > _xorp_out0; > > _xorp_arpq0 :: ARPQuerier(10.10.10.11, 8:0:27:23:1a:29) -> > > _xorp_out0; > > _xorp_c0[2] -> _xorp_arpt; > > _xorp_arpt[0] -> [1]_xorp_arpq0; > > > > // Discard IPv6 > > _xorp_c0[5] -> Discard; > > _xorp_c0[3] -> Discard; > > _xorp_c0[4] -> Discard; > > > > // Unknown protocol > > _xorp_c0[6] -> Print("eth1 unknown protocol") -> Discard; > > > > > > // Input and output paths for eth2 > > > > FromDevice(eth2, SNIFFER false) -> _xorp_c1 :: Classifier( > > 12/0800, // [0] IPv4 packet > > 12/0806 20/0001, // [1] ARP request > > 12/0806 20/0002, // [2] ARP reply > > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation > > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment > > 12/86dd, // [5] IPv6 packet > > -) // [6] Unsupported protocol; > > _xorp_out1 :: Queue(200) -> _xorp_to_device1 :: ToDevice(eth2); > > > > // IPv4 > > _xorp_c1[0] -> Paint(2) -> _xorp_ip4; > > _xorp_c1[1] -> ARPResponder(10.30.30.10 8:0:27:2b:ed:3f) -> > > _xorp_out1; > > _xorp_arpq1 :: ARPQuerier(10.30.30.10, 8:0:27:2b:ed:3f) -> > > _xorp_out1; > > _xorp_c1[2] -> _xorp_arpt; > > _xorp_arpt[1] -> [1]_xorp_arpq1; > > > > // Discard IPv6 > > _xorp_c1[5] -> Discard; > > _xorp_c1[3] -> Discard; > > _xorp_c1[4] -> Discard; > > > > // Unknown protocol > > _xorp_c1[6] -> Print("eth2 unknown protocol") -> Discard; > > > > > > // Local delivery > > > > _xorp_toh :: Discard; > > > > // IPv4 > > _xorp_rt4[2] -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2) -> > > _xorp_toh; > > _xorp_arpt[2] -> _xorp_toh; > > > > > > // Forwarding path for eth1 > > > > // IPv4 > > _xorp_rt4[0] -> DropBroadcasts > > -> _xorp_cp0 :: PaintTee(1) > > -> _xorp_gio0 :: IPGWOptions(10.10.10.11) > > -> FixIPSrc(10.10.10.11) > > -> _xorp_dt0 :: DecIPTTL > > -> _xorp_fr0 :: IPFragmenter(1500) > > -> [0]_xorp_arpq0; > > _xorp_dt0[1] -> ICMPError(10.10.10.11, timeexceeded) -> _xorp_rt4; > > _xorp_fr0[1] -> ICMPError(10.10.10.11, unreachable, needfrag) -> > > _xorp_rt4; > > _xorp_gio0[1] -> ICMPError(10.10.10.11, parameterproblem) -> > > _xorp_rt4; > > _xorp_cp0[1] -> ICMPError(10.10.10.11, redirect, host) -> > > _xorp_rt4; > > > > > > // Forwarding path for eth2 > > > > // IPv4 > > _xorp_rt4[1] -> DropBroadcasts > > -> _xorp_cp1 :: PaintTee(2) > > -> _xorp_gio1 :: IPGWOptions(10.30.30.10) > > -> FixIPSrc(10.30.30.10) > > -> _xorp_dt1 :: DecIPTTL > > -> _xorp_fr1 :: IPFragmenter(1500) > > -> [0]_xorp_arpq1; > > _xorp_dt1[1] -> ICMPError(10.30.30.10, timeexceeded) -> _xorp_rt4; > > _xorp_fr1[1] -> ICMPError(10.30.30.10, unreachable, needfrag) -> > > _xorp_rt4; > > _xorp_gio1[1] -> ICMPError(10.30.30.10, parameterproblem) -> > > _xorp_rt4; > > _xorp_cp1[1] -> ICMPError(10.30.30.10, redirect, host) -> > > _xorp_rt4; > > > > > > And here we can see the correct routing table: > > 10.10.10.11/32 - 2 > > 10.30.30.10/32 - 2 > > 10.10.10.0/24 - 0 > > 10.30.30.0/24 - 1 > > 10.20.20.0/24 10.10.10.10 0 > > > > (the subnet 10.20.20.0/24 come from the > > other router connected) > > > > So click know it. > > > > But if i do a : > > > > ping 10.20.20.10 (who exist) i have the following message: > > connect: Network is unreachable > > > > The connect command doesn't know the click route :( > > > > I really don't know what do > > > > Thanks > > > > Luca > > > > Luca Belforte wrote: > > > Hi Beyers, > > > > > > yes theoretically, but my problem is different. If y delete all > > the ip > > > route in the kernel (ip route flush all) so I'm sure the kernel > > can't > > > help. Then ping command doesn't work. > > > > > > My question is more how force click to process the who coming > > from the > > > system itself? (like a ping or traceroute command) > > > > > > Or opposite how to be sure that click process it? > > > > > > thanks > > > > > > Luca > > > > > > Beyers Cronje wrote: > > > > > >> Hi Luca, > > >> > > >> Theoretically using FromDevice with "SNIFFER false" then the > kernel > > >> should not process the packets. > > >> > > >> Beyers > > >> > > >> On Wed, Nov 18, 2009 at 10:08 PM, Luca Belforte > > >> > > > >> > >> wrote: > > >> > > >> Hello, > > >> > > >> i have a xorp+click installation, who works, click receive > > the correct > > >> routes. > > >> But if i want to do a ping, or traceroute it still use the > > kernel > > >> route > > >> informations. > > >> I tried to disable the SNIFFING mode, but without success. > > >> > > >> How can i use click to route packet coming from the system? > > >> > > >> Thanks in advance > > >> > > >> Luca > > >> _______________________________________________ > > >> 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 > > > > > > > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > > From luca.belforte at student.uclouvain.be Thu Nov 19 15:54:13 2009 From: luca.belforte at student.uclouvain.be (Luca Belforte) Date: Thu, 19 Nov 2009 21:54:13 +0100 Subject: [Click] Using userlevel-click to forward packet In-Reply-To: References: <4B045426.3000204@student.uclouvain.be> <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> <4B0573BB.3090200@student.uclouvain.be> <4B058A17.8080703@student.uclouvain.be> <4B059311.5000800@student.uclouvain.be> Message-ID: <4B05B075.2070406@student.uclouvain.be> Hello, i added the following code: FromHost(fake0) -> _xorp_c2 :: Classifier( 12/0800, // [0] IPv4 packet 12/0806) // [1] ARP request _xorp_to_device2 :: ToHost(fake0); // IPv4 _xorp_c2[0] -> Paint(1) -> _xorp_ip4; _xorp_c2[1] -> ARPResponder(0.0.0.0/0 1:1:1:1:1:1) -> _xorp_to_device2; but this doesn't help, I'm still having the same problem. Thanks Luca Cliff Frey wrote: > Luca, > > Please respond to the mailing list so that other people can help out too. > > I believe that there is an example online: > http://read.cs.ucla.edu/click/examples/fromhost-tunnel.click > > In some cases you can get away with just using ToHost... like in most > of the other examples. > > On Thu, Nov 19, 2009 at 10:48 AM, Luca Belforte > > wrote: > > Hello Cliff, > > thanks, this sound what i was searching for. (Strange that the xorp > generator script doesn't use it) > > Did you have an example on how i can configure it? > > Thanks > > Luca > > > Cliff Frey wrote: > > Luca, > > > > You need to add a FromHost element to your config which will receive > > packets from Linux, and a ToHost element that will deliver > packets to > > Linux. > > > > Cliff > > > > On Thu, Nov 19, 2009 at 10:10 AM, Luca Belforte > > > > >> wrote: > > > > I put here my click configuration > > > > I'm using click 1.7 because the 1.6 doesn't work with xorp > > > > // > > // Generated by XORP FEA > > // > > > > > > // Shared IPv4 input path and routing table > > > > _xorp_ip4 :: Strip(14) > > -> CheckIPHeader(INTERFACES 10.10.10.11/24 > > > 10.30.30.10/24 > ) > > -> _xorp_rt4 :: LinearIPLookup(10.10.10.11/32 > > > 2, 10.30.30.10/32 > 2); > > > > > > // ARP responses are copied to each ARPQuerier and the host. > > > > _xorp_arpt :: Tee(3); > > > > > > // Input and output paths for eth1 > > > > FromDevice(eth1, SNIFFER false) -> _xorp_c0 :: Classifier( > > 12/0800, // [0] IPv4 packet > > 12/0806 20/0001, // [1] ARP request > > 12/0806 20/0002, // [2] ARP reply > > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation > > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment > > 12/86dd, // [5] IPv6 packet > > -) // [6] Unsupported protocol; > > _xorp_out0 :: Queue(200) -> _xorp_to_device0 :: > ToDevice(eth1); > > > > // IPv4 > > _xorp_c0[0] -> Paint(1) -> _xorp_ip4; > > _xorp_c0[1] -> ARPResponder(10.10.10.11 8:0:27:23:1a:29) -> > > _xorp_out0; > > _xorp_arpq0 :: ARPQuerier(10.10.10.11, 8:0:27:23:1a:29) -> > > _xorp_out0; > > _xorp_c0[2] -> _xorp_arpt; > > _xorp_arpt[0] -> [1]_xorp_arpq0; > > > > // Discard IPv6 > > _xorp_c0[5] -> Discard; > > _xorp_c0[3] -> Discard; > > _xorp_c0[4] -> Discard; > > > > // Unknown protocol > > _xorp_c0[6] -> Print("eth1 unknown protocol") -> Discard; > > > > > > // Input and output paths for eth2 > > > > FromDevice(eth2, SNIFFER false) -> _xorp_c1 :: Classifier( > > 12/0800, // [0] IPv4 packet > > 12/0806 20/0001, // [1] ARP request > > 12/0806 20/0002, // [2] ARP reply > > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation > > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment > > 12/86dd, // [5] IPv6 packet > > -) // [6] Unsupported protocol; > > _xorp_out1 :: Queue(200) -> _xorp_to_device1 :: > ToDevice(eth2); > > > > // IPv4 > > _xorp_c1[0] -> Paint(2) -> _xorp_ip4; > > _xorp_c1[1] -> ARPResponder(10.30.30.10 8:0:27:2b:ed:3f) -> > > _xorp_out1; > > _xorp_arpq1 :: ARPQuerier(10.30.30.10, 8:0:27:2b:ed:3f) -> > > _xorp_out1; > > _xorp_c1[2] -> _xorp_arpt; > > _xorp_arpt[1] -> [1]_xorp_arpq1; > > > > // Discard IPv6 > > _xorp_c1[5] -> Discard; > > _xorp_c1[3] -> Discard; > > _xorp_c1[4] -> Discard; > > > > // Unknown protocol > > _xorp_c1[6] -> Print("eth2 unknown protocol") -> Discard; > > > > > > // Local delivery > > > > _xorp_toh :: Discard; > > > > // IPv4 > > _xorp_rt4[2] -> EtherEncap(0x0800, 1:1:1:1:1:1, > 2:2:2:2:2:2) -> > > _xorp_toh; > > _xorp_arpt[2] -> _xorp_toh; > > > > > > // Forwarding path for eth1 > > > > // IPv4 > > _xorp_rt4[0] -> DropBroadcasts > > -> _xorp_cp0 :: PaintTee(1) > > -> _xorp_gio0 :: IPGWOptions(10.10.10.11) > > -> FixIPSrc(10.10.10.11) > > -> _xorp_dt0 :: DecIPTTL > > -> _xorp_fr0 :: IPFragmenter(1500) > > -> [0]_xorp_arpq0; > > _xorp_dt0[1] -> ICMPError(10.10.10.11, timeexceeded) -> > _xorp_rt4; > > _xorp_fr0[1] -> ICMPError(10.10.10.11, unreachable, > needfrag) -> > > _xorp_rt4; > > _xorp_gio0[1] -> ICMPError(10.10.10.11, parameterproblem) -> > > _xorp_rt4; > > _xorp_cp0[1] -> ICMPError(10.10.10.11, redirect, host) -> > > _xorp_rt4; > > > > > > // Forwarding path for eth2 > > > > // IPv4 > > _xorp_rt4[1] -> DropBroadcasts > > -> _xorp_cp1 :: PaintTee(2) > > -> _xorp_gio1 :: IPGWOptions(10.30.30.10) > > -> FixIPSrc(10.30.30.10) > > -> _xorp_dt1 :: DecIPTTL > > -> _xorp_fr1 :: IPFragmenter(1500) > > -> [0]_xorp_arpq1; > > _xorp_dt1[1] -> ICMPError(10.30.30.10, timeexceeded) -> > _xorp_rt4; > > _xorp_fr1[1] -> ICMPError(10.30.30.10, unreachable, > needfrag) -> > > _xorp_rt4; > > _xorp_gio1[1] -> ICMPError(10.30.30.10, parameterproblem) -> > > _xorp_rt4; > > _xorp_cp1[1] -> ICMPError(10.30.30.10, redirect, host) -> > > _xorp_rt4; > > > > > > And here we can see the correct routing table: > > 10.10.10.11/32 > - 2 > > 10.30.30.10/32 > - 2 > > 10.10.10.0/24 > - 0 > > 10.30.30.0/24 > - 1 > > 10.20.20.0/24 > 10.10.10.10 0 > > > > (the subnet 10.20.20.0/24 > come from the > > other router connected) > > > > So click know it. > > > > But if i do a : > > > > ping 10.20.20.10 (who exist) i have the following message: > > connect: Network is unreachable > > > > The connect command doesn't know the click route :( > > > > I really don't know what do > > > > Thanks > > > > Luca > > > > Luca Belforte wrote: > > > Hi Beyers, > > > > > > yes theoretically, but my problem is different. If y > delete all > > the ip > > > route in the kernel (ip route flush all) so I'm sure the > kernel > > can't > > > help. Then ping command doesn't work. > > > > > > My question is more how force click to process the who coming > > from the > > > system itself? (like a ping or traceroute command) > > > > > > Or opposite how to be sure that click process it? > > > > > > thanks > > > > > > Luca > > > > > > Beyers Cronje wrote: > > > > > >> Hi Luca, > > >> > > >> Theoretically using FromDevice with "SNIFFER false" then > the kernel > > >> should not process the packets. > > >> > > >> Beyers > > >> > > >> On Wed, Nov 18, 2009 at 10:08 PM, Luca Belforte > > >> > > > > > >> > > >>> wrote: > > >> > > >> Hello, > > >> > > >> i have a xorp+click installation, who works, click > receive > > the correct > > >> routes. > > >> But if i want to do a ping, or traceroute it still > use the > > kernel > > >> route > > >> informations. > > >> I tried to disable the SNIFFING mode, but without > success. > > >> > > >> How can i use click to route packet coming from the > system? > > >> > > >> Thanks in advance > > >> > > >> Luca > > >> _______________________________________________ > > >> 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 > > > > > > > > _______________________________________________ > > click mailing list > > click at amsterdam.lcs.mit.edu > > > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > > > From jetever at gmail.com Thu Nov 19 21:31:27 2009 From: jetever at gmail.com (Yongheng Qi) Date: Fri, 20 Nov 2009 10:31:27 +0800 Subject: [Click] click optimize efficiency Message-ID: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> Dear everyone. I use click roofnet process the 802.11n packet. test it use IxChariot. find about 90Mbps, click use 100% cpu. I use routeros 433AH boardband.the cpu is MIPS 680Mhz. I don't know how to make click have more eiffciency. please help me, Thanks very much. -- Yongheng Qi Mobile: +86 1390 119 7481 From jetever at gmail.com Thu Nov 19 21:31:27 2009 From: jetever at gmail.com (Yongheng Qi) Date: Fri, 20 Nov 2009 10:31:27 +0800 Subject: [Click] click optimize efficiency Message-ID: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> Dear everyone. I use click roofnet process the 802.11n packet. test it use IxChariot. find about 90Mbps, click use 100% cpu. I use routeros 433AH boardband.the cpu is MIPS 680Mhz. I don't know how to make click have more eiffciency. please help me, Thanks very much. -- Yongheng Qi Mobile: +86 1390 119 7481 From pekka.nikander at nomadiclab.com Fri Nov 20 10:14:10 2009 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 20 Nov 2009 17:14:10 +0200 Subject: [Click] Mac OS X assert failed when trying to use KernelTun Message-ID: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> I'm a relative newbie to Click, and trying to use KernelTun on Mac OS X, with the latest GIT version. Unfortunately it looks like that there is a bug, apparently related to the interactions between kevents and select/poll. The OS X tun/tap devices don't currently support kevents, and therefore click tries to back off to use select/poll. However, once it gets to the actual poll in master.cc, something has gone wrong and I get a an assertion failure on line 850 in master.cc: Element *read_elt = (p->revents & ~POLLOUT ? _read_elements[fd] : 0); This results in an assertion failure, with this trivial script: click -e "KernelTun(192.168.15.1/24) -> Discard" Assertion failed: (i>=0 && i<_n), function operator[], file ../include/click/vector.hh, line 184. Abort trap My gut feeling is that the bug may line somewhere in master.cc Master:add_select, in the code that tries to make sure that one can fall back to select/poll in the case of kqueue error. But I may be wrong. In any case, when tracing the execution in opening the tun/tap device, the kevent system call at line 602 of master.cc fails, causing the _kqueue socket to be closed and made unused. However, much before that I can see with ifconfig that the tun/tap interface is indeed open and correctly ifconfig'ed. Anyone an idea where to continue debugging? Or would it be easier to add KEVENT support to the Mac tun/tap kexts? --Pekka Nikander From wubaochuan at seu.edu.cn Sun Nov 22 08:11:06 2009 From: wubaochuan at seu.edu.cn (Baochuan Wu) Date: Sun, 22 Nov 2009 21:11:06 +0800 Subject: [Click] help Message-ID: <458895177.20877@seu.edu.cn> Dear everyone. I want to know whether the following functions can be achieved using Click. I have a few machines, each machine runs Click. There is another machine which is more intellegent, it can compute routes for Click if it can obtein the topology of the machines which run Click. I want to know: Can Click send LSAs to the intellegent machine ? Can Click receive routes from the intellegent machine, and install the received routes? Please help me, Thank you very much. ----------------------- Baochuan Wu From luca.belforte at student.uclouvain.be Sun Nov 22 09:25:47 2009 From: luca.belforte at student.uclouvain.be (Luca Belforte) Date: Sun, 22 Nov 2009 15:25:47 +0100 Subject: [Click] Using userlevel-click to forward packet In-Reply-To: <4B05B075.2070406@student.uclouvain.be> References: <4B045426.3000204@student.uclouvain.be> <329bff5c0911182317k64e199b3xfddf59085053b694@mail.gmail.com> <4B0573BB.3090200@student.uclouvain.be> <4B058A17.8080703@student.uclouvain.be> <4B059311.5000800@student.uclouvain.be> <4B05B075.2070406@student.uclouvain.be> Message-ID: <4B0949EB.4050400@student.uclouvain.be> Hello all, I also have a problem delivering packet to "kernel" I have a toHost, who work, but the ping or traceroute application dosen't receive the information, but i see the exchange in click, if a put some print. Mycode: _xorp_out2 :: ToHost(fake); _xorp_rt4[2] -> IPPrint("toHost1") -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2) -> _xorp_out2; _xorp_arpt[2] -> IPPrint("toHost2") -> _xorp_out2; and my config is R1 (10.10.10.10) -------------------------------- (10.10.10.11) R2 When i ping 10.10.10.10 from R2, i see on click that R1 receive ICMP Echo, and send a reply, R2 receive the ICMP Echo-Reply, and transmit to host, the printed line is : toHost1: icmp echo reply (with the ip address etc etc) But the ping command, doesn't receive the ping answer, so i think the packets are lost How correctly deliver the packet to the host? Thanks Luca Luca Belforte wrote: > Hello, > > i added the following code: > > FromHost(fake0) -> _xorp_c2 :: Classifier( > 12/0800, // [0] IPv4 packet > 12/0806) // [1] ARP request > _xorp_to_device2 :: ToHost(fake0); > > // IPv4 > _xorp_c2[0] -> Paint(1) -> _xorp_ip4; > _xorp_c2[1] -> ARPResponder(0.0.0.0/0 1:1:1:1:1:1) -> _xorp_to_device2; > > but this doesn't help, I'm still having the same problem. > > Thanks > > Luca > > Cliff Frey wrote: > >> Luca, >> >> Please respond to the mailing list so that other people can help out too. >> >> I believe that there is an example online: >> http://read.cs.ucla.edu/click/examples/fromhost-tunnel.click >> >> In some cases you can get away with just using ToHost... like in most >> of the other examples. >> >> On Thu, Nov 19, 2009 at 10:48 AM, Luca Belforte >> > > wrote: >> >> Hello Cliff, >> >> thanks, this sound what i was searching for. (Strange that the xorp >> generator script doesn't use it) >> >> Did you have an example on how i can configure it? >> >> Thanks >> >> Luca >> >> >> Cliff Frey wrote: >> > Luca, >> > >> > You need to add a FromHost element to your config which will receive >> > packets from Linux, and a ToHost element that will deliver >> packets to >> > Linux. >> > >> > Cliff >> > >> > On Thu, Nov 19, 2009 at 10:10 AM, Luca Belforte >> > > >> > > >> wrote: >> > >> > I put here my click configuration >> > >> > I'm using click 1.7 because the 1.6 doesn't work with xorp >> > >> > // >> > // Generated by XORP FEA >> > // >> > >> > >> > // Shared IPv4 input path and routing table >> > >> > _xorp_ip4 :: Strip(14) >> > -> CheckIPHeader(INTERFACES 10.10.10.11/24 >> >> > 10.30.30.10/24 >> ) >> > -> _xorp_rt4 :: LinearIPLookup(10.10.10.11/32 >> >> > 2, 10.30.30.10/32 >> 2); >> > >> > >> > // ARP responses are copied to each ARPQuerier and the host. >> > >> > _xorp_arpt :: Tee(3); >> > >> > >> > // Input and output paths for eth1 >> > >> > FromDevice(eth1, SNIFFER false) -> _xorp_c0 :: Classifier( >> > 12/0800, // [0] IPv4 packet >> > 12/0806 20/0001, // [1] ARP request >> > 12/0806 20/0002, // [2] ARP reply >> > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation >> > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment >> > 12/86dd, // [5] IPv6 packet >> > -) // [6] Unsupported protocol; >> > _xorp_out0 :: Queue(200) -> _xorp_to_device0 :: >> ToDevice(eth1); >> > >> > // IPv4 >> > _xorp_c0[0] -> Paint(1) -> _xorp_ip4; >> > _xorp_c0[1] -> ARPResponder(10.10.10.11 8:0:27:23:1a:29) -> >> > _xorp_out0; >> > _xorp_arpq0 :: ARPQuerier(10.10.10.11, 8:0:27:23:1a:29) -> >> > _xorp_out0; >> > _xorp_c0[2] -> _xorp_arpt; >> > _xorp_arpt[0] -> [1]_xorp_arpq0; >> > >> > // Discard IPv6 >> > _xorp_c0[5] -> Discard; >> > _xorp_c0[3] -> Discard; >> > _xorp_c0[4] -> Discard; >> > >> > // Unknown protocol >> > _xorp_c0[6] -> Print("eth1 unknown protocol") -> Discard; >> > >> > >> > // Input and output paths for eth2 >> > >> > FromDevice(eth2, SNIFFER false) -> _xorp_c1 :: Classifier( >> > 12/0800, // [0] IPv4 packet >> > 12/0806 20/0001, // [1] ARP request >> > 12/0806 20/0002, // [2] ARP reply >> > 12/86dd 20/3aff 54/87, // [3] IPv6 ICMP ND solicitation >> > 12/86dd 20/3aff 54/88, // [4] IPv6 ICMP ND advertisment >> > 12/86dd, // [5] IPv6 packet >> > -) // [6] Unsupported protocol; >> > _xorp_out1 :: Queue(200) -> _xorp_to_device1 :: >> ToDevice(eth2); >> > >> > // IPv4 >> > _xorp_c1[0] -> Paint(2) -> _xorp_ip4; >> > _xorp_c1[1] -> ARPResponder(10.30.30.10 8:0:27:2b:ed:3f) -> >> > _xorp_out1; >> > _xorp_arpq1 :: ARPQuerier(10.30.30.10, 8:0:27:2b:ed:3f) -> >> > _xorp_out1; >> > _xorp_c1[2] -> _xorp_arpt; >> > _xorp_arpt[1] -> [1]_xorp_arpq1; >> > >> > // Discard IPv6 >> > _xorp_c1[5] -> Discard; >> > _xorp_c1[3] -> Discard; >> > _xorp_c1[4] -> Discard; >> > >> > // Unknown protocol >> > _xorp_c1[6] -> Print("eth2 unknown protocol") -> Discard; >> > >> > >> > // Local delivery >> > >> > _xorp_toh :: Discard; >> > >> > // IPv4 >> > _xorp_rt4[2] -> EtherEncap(0x0800, 1:1:1:1:1:1, >> 2:2:2:2:2:2) -> >> > _xorp_toh; >> > _xorp_arpt[2] -> _xorp_toh; >> > >> > >> > // Forwarding path for eth1 >> > >> > // IPv4 >> > _xorp_rt4[0] -> DropBroadcasts >> > -> _xorp_cp0 :: PaintTee(1) >> > -> _xorp_gio0 :: IPGWOptions(10.10.10.11) >> > -> FixIPSrc(10.10.10.11) >> > -> _xorp_dt0 :: DecIPTTL >> > -> _xorp_fr0 :: IPFragmenter(1500) >> > -> [0]_xorp_arpq0; >> > _xorp_dt0[1] -> ICMPError(10.10.10.11, timeexceeded) -> >> _xorp_rt4; >> > _xorp_fr0[1] -> ICMPError(10.10.10.11, unreachable, >> needfrag) -> >> > _xorp_rt4; >> > _xorp_gio0[1] -> ICMPError(10.10.10.11, parameterproblem) -> >> > _xorp_rt4; >> > _xorp_cp0[1] -> ICMPError(10.10.10.11, redirect, host) -> >> > _xorp_rt4; >> > >> > >> > // Forwarding path for eth2 >> > >> > // IPv4 >> > _xorp_rt4[1] -> DropBroadcasts >> > -> _xorp_cp1 :: PaintTee(2) >> > -> _xorp_gio1 :: IPGWOptions(10.30.30.10) >> > -> FixIPSrc(10.30.30.10) >> > -> _xorp_dt1 :: DecIPTTL >> > -> _xorp_fr1 :: IPFragmenter(1500) >> > -> [0]_xorp_arpq1; >> > _xorp_dt1[1] -> ICMPError(10.30.30.10, timeexceeded) -> >> _xorp_rt4; >> > _xorp_fr1[1] -> ICMPError(10.30.30.10, unreachable, >> needfrag) -> >> > _xorp_rt4; >> > _xorp_gio1[1] -> ICMPError(10.30.30.10, parameterproblem) -> >> > _xorp_rt4; >> > _xorp_cp1[1] -> ICMPError(10.30.30.10, redirect, host) -> >> > _xorp_rt4; >> > >> > >> > And here we can see the correct routing table: >> > 10.10.10.11/32 >> - 2 >> > 10.30.30.10/32 >> - 2 >> > 10.10.10.0/24 >> - 0 >> > 10.30.30.0/24 >> - 1 >> > 10.20.20.0/24 >> 10.10.10.10 0 >> > >> > (the subnet 10.20.20.0/24 >> come from the >> > other router connected) >> > >> > So click know it. >> > >> > But if i do a : >> > >> > ping 10.20.20.10 (who exist) i have the following message: >> > connect: Network is unreachable >> > >> > The connect command doesn't know the click route :( >> > >> > I really don't know what do >> > >> > Thanks >> > >> > Luca >> > >> > Luca Belforte wrote: >> > > Hi Beyers, >> > > >> > > yes theoretically, but my problem is different. If y >> delete all >> > the ip >> > > route in the kernel (ip route flush all) so I'm sure the >> kernel >> > can't >> > > help. Then ping command doesn't work. >> > > >> > > My question is more how force click to process the who coming >> > from the >> > > system itself? (like a ping or traceroute command) >> > > >> > > Or opposite how to be sure that click process it? >> > > >> > > thanks >> > > >> > > Luca >> > > >> > > Beyers Cronje wrote: >> > > >> > >> Hi Luca, >> > >> >> > >> Theoretically using FromDevice with "SNIFFER false" then >> the kernel >> > >> should not process the packets. >> > >> >> > >> Beyers >> > >> >> > >> On Wed, Nov 18, 2009 at 10:08 PM, Luca Belforte >> > >> > >> > > > >> > >> > >> > > >>> wrote: >> > >> >> > >> Hello, >> > >> >> > >> i have a xorp+click installation, who works, click >> receive >> > the correct >> > >> routes. >> > >> But if i want to do a ping, or traceroute it still >> use the >> > kernel >> > >> route >> > >> informations. >> > >> I tried to disable the SNIFFING mode, but without >> success. >> > >> >> > >> How can i use click to route packet coming from the >> system? >> > >> >> > >> Thanks in advance >> > >> >> > >> Luca >> > >> _______________________________________________ >> > >> 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 >> > > >> > > >> > _______________________________________________ >> > 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 a.greenhalgh at cs.ucl.ac.uk Mon Nov 23 07:42:23 2009 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Mon, 23 Nov 2009 13:42:23 +0100 Subject: [Click] 2.6.24.7 patch split into two syntax and core changes. Message-ID: <4769af410911230442h3dd26532qf3dd6a44afed832e@mail.gmail.com> Here is the current checked in click patch for 2.6.24.7 split into the core click changes and the syntax changes. It has been compiled on a clean linux kernel and a checked out version of click via git from today. Click hasn't been run with this patch though. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: core-linux-2.6.24.7-patch Type: application/octet-stream Size: 11425 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091123/da4d027d/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: syntax-linux-2.6.24.7-patch Type: application/octet-stream Size: 149783 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091123/da4d027d/attachment-0003.obj From kohler at cs.ucla.edu Mon Nov 23 09:01:42 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Mon, 23 Nov 2009 15:01:42 +0100 Subject: [Click] Initial version of a Perl script for automatically translating C header files to be C++ compatible Message-ID: <4B0A95C6.1090608@cs.ucla.edu> SyClick is fun! Eddie -------------- next part -------------- A non-text attachment was scrubbed... Name: fixincludes.pl Type: application/x-perl Size: 1849 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091123/caf8e0cf/attachment.bin From latencybuster at gmail.com Mon Nov 23 15:56:11 2009 From: latencybuster at gmail.com (Latency Buster) Date: Mon, 23 Nov 2009 15:56:11 -0500 Subject: [Click] IP header check failed: Message-ID: I am trying to separate out multicast packets. Before feeding to the IPClassifier, when I pass it through CheckIPHeader(), I recv lots of IP HEader Failed Messages. The input packets are multicast packets but the IP header is clean (as looked via wireshark). Any insights why this might occur? ------------------ CONFIG --------------------------------------- inputDevice::FromDump(/home/click/test.pcap, END_AFTER 0.2); inputDevice->c0::Classifier (12/8100 /* dot1Q */, 12/0800 /* 'normal ip packets */, - /* everything else including ARP */); // Filter out multicast packets ip_classifier::IPClassifier(224.0.0.0/4 and ip proto udp, - /* everything else */); c0[0]-> Print("We received 802.1Q Packets.. Discarding") -> Discard; c0[1]-> ip::CheckIPHeader (14, INTERFACES 224.0.0.0/4, VERBOSE true,CHECKSUM false); c0[2]-> Discard; ip[0] -> ip_classifier; ip[1] -> Print("IP header Failed..", 20) -> ToDump (/home/click/badip.pcap); ip_classifier[0]->Print("These are valid Multicast Packets for NAT") -> Discard; ip_classifier[1]->Print ("This will all go to LINUX Host")-> Discard; ----------------------------- END OF CONFIG -------------------------- click-user:~/ click test_mcast.click IP header Failed..: 68 | 01005e43 0d0d001b 0ded1180 08004500 05da3e82 00001c11 337fac15 7e2cefc3 0d0dbb60 138905c6 364d0000 04534b07 0d32000f 30490000 00000000 00010000 13890000 IP header Failed..: 68 |01005e43 0d0d001b 0ded1180 08004500 05da3e83 00001c11 337eac15 7e2cefc3 0d0dbb60 138905c6 4ccb0000 04544b07 0d330000 19d80000 00000000 00010000 13890000 From bcronje at gmail.com Mon Nov 23 16:26:21 2009 From: bcronje at gmail.com (Beyers Cronje) Date: Mon, 23 Nov 2009 23:26:21 +0200 Subject: [Click] IP header check failed: In-Reply-To: References: Message-ID: <329bff5c0911231326h57faa9a6jf309231921fa603f@mail.gmail.com> As a start use CheckIPHeader "DETAILS true" configuration setting and have a look at the drop_details handler information for more detailed information on why CheckIPHeader dropped the packet. On Mon, Nov 23, 2009 at 10:56 PM, Latency Buster wrote: > I am trying to separate out multicast packets. Before feeding to the > IPClassifier, when I pass it through CheckIPHeader(), I recv lots of > IP HEader Failed Messages. The input packets are multicast packets but > the IP header is clean (as looked via wireshark). Any insights why > this might occur? > > > > ------------------ CONFIG --------------------------------------- > inputDevice::FromDump(/home/click/test.pcap, END_AFTER 0.2); > > inputDevice->c0::Classifier (12/8100 /* dot1Q */, 12/0800 /* > 'normal ip packets */, - /* everything else including ARP */); > > // Filter out multicast packets > ip_classifier::IPClassifier(224.0.0.0/4 and ip proto udp, - /* > everything else */); > > > c0[0]-> Print("We received 802.1Q Packets.. Discarding") -> Discard; > c0[1]-> ip::CheckIPHeader (14, INTERFACES 224.0.0.0/4, VERBOSE > true,CHECKSUM false); > c0[2]-> Discard; > > ip[0] -> ip_classifier; > ip[1] -> Print("IP header Failed..", 20) -> ToDump > (/home/click/badip.pcap); > > ip_classifier[0]->Print("These are valid Multicast Packets for NAT") -> > Discard; > ip_classifier[1]->Print ("This will all go to LINUX Host")-> Discard; > > ----------------------------- END OF CONFIG -------------------------- > > click-user:~/ click test_mcast.click > > IP header Failed..: 68 | 01005e43 0d0d001b 0ded1180 08004500 > 05da3e82 00001c11 337fac15 7e2cefc3 0d0dbb60 138905c6 364d0000 > 04534b07 0d32000f 30490000 00000000 00010000 13890000 > > IP header Failed..: 68 |01005e43 0d0d001b 0ded1180 08004500 05da3e83 > 00001c11 337eac15 7e2cefc3 0d0dbb60 138905c6 4ccb0000 04544b07 > 0d330000 19d80000 00000000 00010000 13890000 > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From latencybuster at gmail.com Mon Nov 23 16:45:12 2009 From: latencybuster at gmail.com (Latency Buster) Date: Mon, 23 Nov 2009 16:45:12 -0500 Subject: [Click] IP header check failed: In-Reply-To: <329bff5c0911231326h57faa9a6jf309231921fa603f@mail.gmail.com> References: <329bff5c0911231326h57faa9a6jf309231921fa603f@mail.gmail.com> Message-ID: > As a start use CheckIPHeader "DETAILS true" configuration setting and have a I should have posted that earlier. It spits out "ip: IP header check failed: bad IP length" In the packet I see, ip.len == 1498 Thanks, From latencybuster at gmail.com Mon Nov 23 17:04:21 2009 From: latencybuster at gmail.com (Latency Buster) Date: Mon, 23 Nov 2009 17:04:21 -0500 Subject: [Click] Click with Intel 82598 (10G) In-Reply-To: <4769af410910250007u417d5507j9dd8f189bb94063a@mail.gmail.com> References: <1957618c0910231326h4d3ea965w68b575d420eb4537@mail.gmail.com> <4769af410910250007u417d5507j9dd8f189bb94063a@mail.gmail.com> Message-ID: I might be getting a pair of 10G Intel cards. I assume the patches are for Intel 82598 - that's what I am trying to scour. Sorry for the delayed response and thanks for the link to your patches. On Sun, Oct 25, 2009 at 2:07 AM, Adam Greenhalgh wrote: > Yes, its not bug free, but my patches are here. > > http://nrg.cs.ucl.ac.uk/vrouter/mq > > Happy to work with people on this. > > Adam > > 2009/10/23 Yogesh Mundada : >> AFAIK, group at Intel research Berkley has already tries that. >> Here is the paper link that talks about it: >> http://berkeley.intel-research.net/sylvia/sosp128-dobrescu.pdf >> >> On Fri, Oct 23, 2009 at 12:51 PM, Latency Buster >> wrote: >>> Has anyone tried Click with 10GigE Intel cards ? Just curious.. I >>> might have one or two cards and if needed can develop the driver >>> patches. >>> >>> Thanks, >>> _______________________________________________ >>> 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 >> > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From jetever at gmail.com Tue Nov 24 04:48:57 2009 From: jetever at gmail.com (Yongheng Qi) Date: Tue, 24 Nov 2009 17:48:57 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> Message-ID: <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> Click performance is so poor. I only use 3 classifier and 1 iprewrite and other general packet process elements. At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per second. The attachment is the click config file. anyone can tell me how to optimize it. Thanks very much 2009/11/20 Yongheng Qi > Dear everyone. > > I use click roofnet process the 802.11n packet. test it use IxChariot. find > about 90Mbps, click use 100% cpu. > > I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > I don't know how to make click have more eiffciency. > > please help me, Thanks very much. > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > -- Yongheng Qi Mobile: +86 1390 119 7481 -------------- next part -------------- A non-text attachment was scrubbed... Name: sr2.click_c Type: application/octet-stream Size: 6735 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091124/296b6d82/attachment-0002.obj From jetever at gmail.com Tue Nov 24 04:48:57 2009 From: jetever at gmail.com (Yongheng Qi) Date: Tue, 24 Nov 2009 17:48:57 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> Message-ID: <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> Click performance is so poor. I only use 3 classifier and 1 iprewrite and other general packet process elements. At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per second. The attachment is the click config file. anyone can tell me how to optimize it. Thanks very much 2009/11/20 Yongheng Qi > Dear everyone. > > I use click roofnet process the 802.11n packet. test it use IxChariot. find > about 90Mbps, click use 100% cpu. > > I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > I don't know how to make click have more eiffciency. > > please help me, Thanks very much. > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > -- Yongheng Qi Mobile: +86 1390 119 7481 -------------- next part -------------- A non-text attachment was scrubbed... Name: sr2.click_c Type: application/octet-stream Size: 6735 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091124/296b6d82/attachment-0003.obj From latencybuster at gmail.com Tue Nov 24 10:24:32 2009 From: latencybuster at gmail.com (Latency Buster) Date: Tue, 24 Nov 2009 10:24:32 -0500 Subject: [Click] User defined deterministic NAT Table Message-ID: 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, From rchertov at cs.ucsb.edu Tue Nov 24 11:00:02 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Tue, 24 Nov 2009 08:00:02 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> Message-ID: <4B0C0302.5060509@cs.ucsb.edu> The performance might be poor due to the configuration file that you use. It is hard to say what is wrong without seeing your Click config file. Roman Yongheng Qi wrote: > Click performance is so poor. I only use 3 classifier and 1 iprewrite and > other general packet process elements. > > At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per > second. > > The attachment is the click config file. anyone can tell me how to optimize > it. > > Thanks very much > > > 2009/11/20 Yongheng Qi > >> Dear everyone. >> >> I use click roofnet process the 802.11n packet. test it use IxChariot. find >> about 90Mbps, click use 100% cpu. >> >> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. >> >> I don't know how to make click have more eiffciency. >> >> please help me, Thanks very much. >> >> -- >> Yongheng Qi >> >> Mobile: +86 1390 119 7481 >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From cliff at meraki.com Tue Nov 24 13:32:58 2009 From: cliff at meraki.com (Cliff Frey) Date: Tue, 24 Nov 2009 10:32:58 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> Message-ID: Your config looks reasonable to me. How are you measuring performance? I know if you are running TCP on the devices as well (if you are testing tcp-to-the-device rather than forwarding perfomance) that can slow things down (because of TCP checksumming and because linux will keep a copy of every packet, causing there to be a lot more memcpy overhead). Also, often the drivers contribute a lot of the slowdown, even though this is very hard to measure/see. It also seems as though you are using a br-lan device from linux, perhaps the linux bridge code isn't very fast as well. You can benchmark click by loading the same config, but with an InfiniteSource instead of a FromHost or FromDevice, and a Discard instead of a ToHost/ToDevice, and seeing what performance you get there. That can give you a benchmark for the maximum possible speeds that you will see with click. If that number is very high, then you need to be optimizing your drivers or linux. If the number is low, then the problem probably is in click. I know from experience that it is possible to forward more than 140Mbps using kernel click with linux on a mips board in the 600-800 MHz range. Cliff On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi wrote: > Click performance is so poor. I only use 3 classifier and 1 iprewrite and > other general packet process elements. > > At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per > second. > > The attachment is the click config file. anyone can tell me how to optimize > it. > > Thanks very much > > > 2009/11/20 Yongheng Qi > > > Dear everyone. > > > > I use click roofnet process the 802.11n packet. test it use IxChariot. > find > > about 90Mbps, click use 100% cpu. > > > > I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > > > I don't know how to make click have more eiffciency. > > > > please help me, Thanks very much. > > > > -- > > Yongheng Qi > > > > Mobile: +86 1390 119 7481 > > > > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > From rchertov at cs.ucsb.edu Tue Nov 24 13:49:02 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Tue, 24 Nov 2009 10:49:02 -0800 Subject: [Click] click optimize efficiency In-Reply-To: References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> Message-ID: <4B0C2A9E.9060108@cs.ucsb.edu> I failed to notice the config file... In addition to what Cliff said, you can try a simple test where you configure Click as a transparent bridge to forward packets between two devices. Then, you can look at the counters to see where the packet drops occur. FromDevice(eth0) -> Queue -> ToDevice(eth1); If the counters for FromDevice, Queue, and ToDevice are the same, it means that you are dropping packets at eth0 driver. You also need to keep track of how many packets you sent from the source to help you diagnose the issue. Roman Cliff Frey wrote: > Your config looks reasonable to me. > > How are you measuring performance? I know if you are running TCP on the > devices as well (if you are testing tcp-to-the-device rather than forwarding > perfomance) that can slow things down (because of TCP checksumming and > because linux will keep a copy of every packet, causing there to be a lot > more memcpy overhead). > > Also, often the drivers contribute a lot of the slowdown, even though this > is very hard to measure/see. > > It also seems as though you are using a br-lan device from linux, perhaps > the linux bridge code isn't very fast as well. > > You can benchmark click by loading the same config, but with an > InfiniteSource instead of a FromHost or FromDevice, and a Discard instead of > a ToHost/ToDevice, and seeing what performance you get there. That can give > you a benchmark for the maximum possible speeds that you will see with > click. If that number is very high, then you need to be optimizing your > drivers or linux. If the number is low, then the problem probably is in > click. > > I know from experience that it is possible to forward more than 140Mbps > using kernel click with linux on a mips board in the 600-800 MHz range. > > Cliff > > On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi wrote: > >> Click performance is so poor. I only use 3 classifier and 1 iprewrite and >> other general packet process elements. >> >> At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per >> second. >> >> The attachment is the click config file. anyone can tell me how to optimize >> it. >> >> Thanks very much >> >> >> 2009/11/20 Yongheng Qi >> >>> Dear everyone. >>> >>> I use click roofnet process the 802.11n packet. test it use IxChariot. >> find >>> about 90Mbps, click use 100% cpu. >>> >>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. >>> >>> I don't know how to make click have more eiffciency. >>> >>> please help me, Thanks very much. >>> >>> -- >>> Yongheng Qi >>> >>> Mobile: +86 1390 119 7481 >>> >> >> >> -- >> Yongheng Qi >> >> Mobile: +86 1390 119 7481 >> >> _______________________________________________ >> 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 jetever at gmail.com Tue Nov 24 20:14:32 2009 From: jetever at gmail.com (Yongheng Qi) Date: Wed, 25 Nov 2009 09:14:32 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <4B0C2A9E.9060108@cs.ucsb.edu> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> Message-ID: <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> Thanks, you advise is very importent for me. I think it not the TCP problem, because I test the UDP thoughout put. The same as TCP. Cliff say about kernel will memcpy every packet. Have the way solve the question? In the test, the kclick thread use more then 95% CPU. The eth0 driver use the opewrt include and the ath2 use the atheros sdk. These drivers may have problem? On 11/25/09, Roman Chertov wrote: > I failed to notice the config file... > > In addition to what Cliff said, you can try a simple test where you > configure Click as a transparent bridge to forward packets between two > devices. Then, you can look at the counters to see where the packet > drops occur. > > FromDevice(eth0) -> Queue -> ToDevice(eth1); > > If the counters for FromDevice, Queue, and ToDevice are the same, it > means that you are dropping packets at eth0 driver. You also need to > keep track of how many packets you sent from the source to help you > diagnose the issue. > > Roman > > Cliff Frey wrote: >> Your config looks reasonable to me. >> >> How are you measuring performance? I know if you are running TCP on the >> devices as well (if you are testing tcp-to-the-device rather than >> forwarding >> perfomance) that can slow things down (because of TCP checksumming and >> because linux will keep a copy of every packet, causing there to be a lot >> more memcpy overhead). >> >> Also, often the drivers contribute a lot of the slowdown, even though this >> is very hard to measure/see. >> >> It also seems as though you are using a br-lan device from linux, perhaps >> the linux bridge code isn't very fast as well. >> >> You can benchmark click by loading the same config, but with an >> InfiniteSource instead of a FromHost or FromDevice, and a Discard instead >> of >> a ToHost/ToDevice, and seeing what performance you get there. That can >> give >> you a benchmark for the maximum possible speeds that you will see with >> click. If that number is very high, then you need to be optimizing your >> drivers or linux. If the number is low, then the problem probably is in >> click. >> >> I know from experience that it is possible to forward more than 140Mbps >> using kernel click with linux on a mips board in the 600-800 MHz range. >> >> Cliff >> >> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi wrote: >> >>> Click performance is so poor. I only use 3 classifier and 1 iprewrite and >>> other general packet process elements. >>> >>> At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per >>> second. >>> >>> The attachment is the click config file. anyone can tell me how to >>> optimize >>> it. >>> >>> Thanks very much >>> >>> >>> 2009/11/20 Yongheng Qi >>> >>>> Dear everyone. >>>> >>>> I use click roofnet process the 802.11n packet. test it use IxChariot. >>> find >>>> about 90Mbps, click use 100% cpu. >>>> >>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. >>>> >>>> I don't know how to make click have more eiffciency. >>>> >>>> please help me, Thanks very much. >>>> >>>> -- >>>> Yongheng Qi >>>> >>>> Mobile: +86 1390 119 7481 >>>> >>> >>> >>> -- >>> Yongheng Qi >>> >>> Mobile: +86 1390 119 7481 >>> >>> _______________________________________________ >>> 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 >> > > -- Sent from my mobile device Yongheng Qi Mobile: +86 1390 119 7481 From rchertov at cs.ucsb.edu Tue Nov 24 20:35:16 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Tue, 24 Nov 2009 17:35:16 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> Message-ID: <4B0C89D4.9090604@cs.ucsb.edu> Are you sure that your wireless link can transmit more than 90Mbps? I would try to test the base performance of your source and destination first. Roman Yongheng Qi wrote: > Thanks, you advise is very importent for me. I think it not the TCP > problem, because I test the UDP thoughout put. The same as TCP. Cliff > say about kernel will memcpy every packet. Have the way solve the > question? In the test, the kclick thread use more then 95% CPU. The > eth0 driver use the opewrt include and the ath2 use the atheros sdk. > These drivers may have problem? > > On 11/25/09, Roman Chertov wrote: >> I failed to notice the config file... >> >> In addition to what Cliff said, you can try a simple test where you >> configure Click as a transparent bridge to forward packets between two >> devices. Then, you can look at the counters to see where the packet >> drops occur. >> >> FromDevice(eth0) -> Queue -> ToDevice(eth1); >> >> If the counters for FromDevice, Queue, and ToDevice are the same, it >> means that you are dropping packets at eth0 driver. You also need to >> keep track of how many packets you sent from the source to help you >> diagnose the issue. >> >> Roman >> >> Cliff Frey wrote: >>> Your config looks reasonable to me. >>> >>> How are you measuring performance? I know if you are running TCP on the >>> devices as well (if you are testing tcp-to-the-device rather than >>> forwarding >>> perfomance) that can slow things down (because of TCP checksumming and >>> because linux will keep a copy of every packet, causing there to be a lot >>> more memcpy overhead). >>> >>> Also, often the drivers contribute a lot of the slowdown, even though this >>> is very hard to measure/see. >>> >>> It also seems as though you are using a br-lan device from linux, perhaps >>> the linux bridge code isn't very fast as well. >>> >>> You can benchmark click by loading the same config, but with an >>> InfiniteSource instead of a FromHost or FromDevice, and a Discard instead >>> of >>> a ToHost/ToDevice, and seeing what performance you get there. That can >>> give >>> you a benchmark for the maximum possible speeds that you will see with >>> click. If that number is very high, then you need to be optimizing your >>> drivers or linux. If the number is low, then the problem probably is in >>> click. >>> >>> I know from experience that it is possible to forward more than 140Mbps >>> using kernel click with linux on a mips board in the 600-800 MHz range. >>> >>> Cliff >>> >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi wrote: >>> >>>> Click performance is so poor. I only use 3 classifier and 1 iprewrite and >>>> other general packet process elements. >>>> >>>> At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per >>>> second. >>>> >>>> The attachment is the click config file. anyone can tell me how to >>>> optimize >>>> it. >>>> >>>> Thanks very much >>>> >>>> >>>> 2009/11/20 Yongheng Qi >>>> >>>>> Dear everyone. >>>>> >>>>> I use click roofnet process the 802.11n packet. test it use IxChariot. >>>> find >>>>> about 90Mbps, click use 100% cpu. >>>>> >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. >>>>> >>>>> I don't know how to make click have more eiffciency. >>>>> >>>>> please help me, Thanks very much. >>>>> >>>>> -- >>>>> Yongheng Qi >>>>> >>>>> Mobile: +86 1390 119 7481 >>>>> >>>> >>>> -- >>>> Yongheng Qi >>>> >>>> Mobile: +86 1390 119 7481 >>>> >>>> _______________________________________________ >>>> 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 jetever at gmail.com Tue Nov 24 20:43:40 2009 From: jetever at gmail.com (Yongheng Qi) Date: Wed, 25 Nov 2009 09:43:40 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <4B0C89D4.9090604@cs.ucsb.edu> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> Message-ID: <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> en, I am not sure, but I don't know how test the wireless throughout put. but the wireless card on ap sta mode can get the 140Mbps. the monitor mode is our optimized. so it can get the same throughout put as ap sta mode. 2009/11/25 Roman Chertov > Are you sure that your wireless link can transmit more than 90Mbps? I > would try to test the base performance of your source and destination > first. > > Roman > > Yongheng Qi wrote: > > Thanks, you advise is very importent for me. I think it not the TCP > > problem, because I test the UDP thoughout put. The same as TCP. Cliff > > say about kernel will memcpy every packet. Have the way solve the > > question? In the test, the kclick thread use more then 95% CPU. The > > eth0 driver use the opewrt include and the ath2 use the atheros sdk. > > These drivers may have problem? > > > > On 11/25/09, Roman Chertov wrote: > >> I failed to notice the config file... > >> > >> In addition to what Cliff said, you can try a simple test where you > >> configure Click as a transparent bridge to forward packets between two > >> devices. Then, you can look at the counters to see where the packet > >> drops occur. > >> > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > >> > >> If the counters for FromDevice, Queue, and ToDevice are the same, it > >> means that you are dropping packets at eth0 driver. You also need to > >> keep track of how many packets you sent from the source to help you > >> diagnose the issue. > >> > >> Roman > >> > >> Cliff Frey wrote: > >>> Your config looks reasonable to me. > >>> > >>> How are you measuring performance? I know if you are running TCP on > the > >>> devices as well (if you are testing tcp-to-the-device rather than > >>> forwarding > >>> perfomance) that can slow things down (because of TCP checksumming and > >>> because linux will keep a copy of every packet, causing there to be a > lot > >>> more memcpy overhead). > >>> > >>> Also, often the drivers contribute a lot of the slowdown, even though > this > >>> is very hard to measure/see. > >>> > >>> It also seems as though you are using a br-lan device from linux, > perhaps > >>> the linux bridge code isn't very fast as well. > >>> > >>> You can benchmark click by loading the same config, but with an > >>> InfiniteSource instead of a FromHost or FromDevice, and a Discard > instead > >>> of > >>> a ToHost/ToDevice, and seeing what performance you get there. That can > >>> give > >>> you a benchmark for the maximum possible speeds that you will see with > >>> click. If that number is very high, then you need to be optimizing > your > >>> drivers or linux. If the number is low, then the problem probably is > in > >>> click. > >>> > >>> I know from experience that it is possible to forward more than 140Mbps > >>> using kernel click with linux on a mips board in the 600-800 MHz range. > >>> > >>> Cliff > >>> > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > wrote: > >>> > >>>> Click performance is so poor. I only use 3 classifier and 1 iprewrite > and > >>>> other general packet process elements. > >>>> > >>>> At 680Mhz MIPS CPU, click actually can't process over 90Mbit data per > >>>> second. > >>>> > >>>> The attachment is the click config file. anyone can tell me how to > >>>> optimize > >>>> it. > >>>> > >>>> Thanks very much > >>>> > >>>> > >>>> 2009/11/20 Yongheng Qi > >>>> > >>>>> Dear everyone. > >>>>> > >>>>> I use click roofnet process the 802.11n packet. test it use > IxChariot. > >>>> find > >>>>> about 90Mbps, click use 100% cpu. > >>>>> > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > >>>>> > >>>>> I don't know how to make click have more eiffciency. > >>>>> > >>>>> please help me, Thanks very much. > >>>>> > >>>>> -- > >>>>> Yongheng Qi > >>>>> > >>>>> Mobile: +86 1390 119 7481 > >>>>> > >>>> > >>>> -- > >>>> Yongheng Qi > >>>> > >>>> Mobile: +86 1390 119 7481 > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >> > > > > -- Yongheng Qi Mobile: +86 1390 119 7481 From rchertov at cs.ucsb.edu Tue Nov 24 20:47:36 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Tue, 24 Nov 2009 17:47:36 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> Message-ID: <4B0C8CB8.5070102@cs.ucsb.edu> You can run Click on the receiver with the following config file. FromDevice(devX) -> ctr :: AverageCounter -> Discard; Then, you can look at the ctr stats to see what throughput you are getting at the receiver. Yongheng Qi wrote: > en, I am not sure, but I don't know how test the wireless throughout put. > > but the wireless card on ap sta mode can get the 140Mbps. the monitor > mode is > > our optimized. so it can get the same throughout put as ap sta mode. > > 2009/11/25 Roman Chertov > > > Are you sure that your wireless link can transmit more than 90Mbps? I > would try to test the base performance of your source and > destination first. > > Roman > > Yongheng Qi wrote: > > Thanks, you advise is very importent for me. I think it not the TCP > > problem, because I test the UDP thoughout put. The same as TCP. Cliff > > say about kernel will memcpy every packet. Have the way solve the > > question? In the test, the kclick thread use more then 95% CPU. The > > eth0 driver use the opewrt include and the ath2 use the atheros sdk. > > These drivers may have problem? > > > > On 11/25/09, Roman Chertov > wrote: > >> I failed to notice the config file... > >> > >> In addition to what Cliff said, you can try a simple test where you > >> configure Click as a transparent bridge to forward packets > between two > >> devices. Then, you can look at the counters to see where the packet > >> drops occur. > >> > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > >> > >> If the counters for FromDevice, Queue, and ToDevice are the same, it > >> means that you are dropping packets at eth0 driver. You also need to > >> keep track of how many packets you sent from the source to help you > >> diagnose the issue. > >> > >> Roman > >> > >> Cliff Frey wrote: > >>> Your config looks reasonable to me. > >>> > >>> How are you measuring performance? I know if you are running > TCP on the > >>> devices as well (if you are testing tcp-to-the-device rather than > >>> forwarding > >>> perfomance) that can slow things down (because of TCP > checksumming and > >>> because linux will keep a copy of every packet, causing there to > be a lot > >>> more memcpy overhead). > >>> > >>> Also, often the drivers contribute a lot of the slowdown, even > though this > >>> is very hard to measure/see. > >>> > >>> It also seems as though you are using a br-lan device from > linux, perhaps > >>> the linux bridge code isn't very fast as well. > >>> > >>> You can benchmark click by loading the same config, but with an > >>> InfiniteSource instead of a FromHost or FromDevice, and a > Discard instead > >>> of > >>> a ToHost/ToDevice, and seeing what performance you get there. > That can > >>> give > >>> you a benchmark for the maximum possible speeds that you will > see with > >>> click. If that number is very high, then you need to be > optimizing your > >>> drivers or linux. If the number is low, then the problem > probably is in > >>> click. > >>> > >>> I know from experience that it is possible to forward more than > 140Mbps > >>> using kernel click with linux on a mips board in the 600-800 MHz > range. > >>> > >>> Cliff > >>> > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > wrote: > >>> > >>>> Click performance is so poor. I only use 3 classifier and 1 > iprewrite and > >>>> other general packet process elements. > >>>> > >>>> At 680Mhz MIPS CPU, click actually can't process over 90Mbit > data per > >>>> second. > >>>> > >>>> The attachment is the click config file. anyone can tell me how to > >>>> optimize > >>>> it. > >>>> > >>>> Thanks very much > >>>> > >>>> > >>>> 2009/11/20 Yongheng Qi > > >>>> > >>>>> Dear everyone. > >>>>> > >>>>> I use click roofnet process the 802.11n packet. test it use > IxChariot. > >>>> find > >>>>> about 90Mbps, click use 100% cpu. > >>>>> > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > >>>>> > >>>>> I don't know how to make click have more eiffciency. > >>>>> > >>>>> please help me, Thanks very much. > >>>>> > >>>>> -- > >>>>> Yongheng Qi > >>>>> > >>>>> Mobile: +86 1390 119 7481 > >>>>> > >>>> > >>>> -- > >>>> Yongheng Qi > >>>> > >>>> Mobile: +86 1390 119 7481 > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >> > > > > > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 From jetever at gmail.com Tue Nov 24 21:39:23 2009 From: jetever at gmail.com (Yongheng Qi) Date: Wed, 25 Nov 2009 10:39:23 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <4B0C8CB8.5070102@cs.ucsb.edu> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> Message-ID: <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> Thanks, Roman, I have test the FromDevice(eth0) -> ctr :: AverageCounter -> Discard and FromDevice(br-lan) both can get the 100Mbps throuthput, it is my etherlink limit. 2009/11/25 Roman Chertov > You can run Click on the receiver with the following config file. > > FromDevice(devX) -> ctr :: AverageCounter -> Discard; > > Then, you can look at the ctr stats to see what throughput you are > getting at the receiver. > > Yongheng Qi wrote: > > en, I am not sure, but I don't know how test the wireless throughout put. > > > > but the wireless card on ap sta mode can get the 140Mbps. the monitor > > mode is > > > > our optimized. so it can get the same throughout put as ap sta mode. > > > > 2009/11/25 Roman Chertov > > > > > > Are you sure that your wireless link can transmit more than 90Mbps? > I > > would try to test the base performance of your source and > > destination first. > > > > Roman > > > > Yongheng Qi wrote: > > > Thanks, you advise is very importent for me. I think it not the TCP > > > problem, because I test the UDP thoughout put. The same as TCP. > Cliff > > > say about kernel will memcpy every packet. Have the way solve the > > > question? In the test, the kclick thread use more then 95% CPU. The > > > eth0 driver use the opewrt include and the ath2 use the atheros > sdk. > > > These drivers may have problem? > > > > > > On 11/25/09, Roman Chertov > > wrote: > > >> I failed to notice the config file... > > >> > > >> In addition to what Cliff said, you can try a simple test where > you > > >> configure Click as a transparent bridge to forward packets > > between two > > >> devices. Then, you can look at the counters to see where the > packet > > >> drops occur. > > >> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > > >> > > >> If the counters for FromDevice, Queue, and ToDevice are the same, > it > > >> means that you are dropping packets at eth0 driver. You also need > to > > >> keep track of how many packets you sent from the source to help > you > > >> diagnose the issue. > > >> > > >> Roman > > >> > > >> Cliff Frey wrote: > > >>> Your config looks reasonable to me. > > >>> > > >>> How are you measuring performance? I know if you are running > > TCP on the > > >>> devices as well (if you are testing tcp-to-the-device rather than > > >>> forwarding > > >>> perfomance) that can slow things down (because of TCP > > checksumming and > > >>> because linux will keep a copy of every packet, causing there to > > be a lot > > >>> more memcpy overhead). > > >>> > > >>> Also, often the drivers contribute a lot of the slowdown, even > > though this > > >>> is very hard to measure/see. > > >>> > > >>> It also seems as though you are using a br-lan device from > > linux, perhaps > > >>> the linux bridge code isn't very fast as well. > > >>> > > >>> You can benchmark click by loading the same config, but with an > > >>> InfiniteSource instead of a FromHost or FromDevice, and a > > Discard instead > > >>> of > > >>> a ToHost/ToDevice, and seeing what performance you get there. > > That can > > >>> give > > >>> you a benchmark for the maximum possible speeds that you will > > see with > > >>> click. If that number is very high, then you need to be > > optimizing your > > >>> drivers or linux. If the number is low, then the problem > > probably is in > > >>> click. > > >>> > > >>> I know from experience that it is possible to forward more than > > 140Mbps > > >>> using kernel click with linux on a mips board in the 600-800 MHz > > range. > > >>> > > >>> Cliff > > >>> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > > wrote: > > >>> > > >>>> Click performance is so poor. I only use 3 classifier and 1 > > iprewrite and > > >>>> other general packet process elements. > > >>>> > > >>>> At 680Mhz MIPS CPU, click actually can't process over 90Mbit > > data per > > >>>> second. > > >>>> > > >>>> The attachment is the click config file. anyone can tell me how > to > > >>>> optimize > > >>>> it. > > >>>> > > >>>> Thanks very much > > >>>> > > >>>> > > >>>> 2009/11/20 Yongheng Qi > > > > >>>> > > >>>>> Dear everyone. > > >>>>> > > >>>>> I use click roofnet process the 802.11n packet. test it use > > IxChariot. > > >>>> find > > >>>>> about 90Mbps, click use 100% cpu. > > >>>>> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > >>>>> > > >>>>> I don't know how to make click have more eiffciency. > > >>>>> > > >>>>> please help me, Thanks very much. > > >>>>> > > >>>>> -- > > >>>>> Yongheng Qi > > >>>>> > > >>>>> Mobile: +86 1390 119 7481 > > >>>>> > > >>>> > > >>>> -- > > >>>> Yongheng Qi > > >>>> > > >>>> Mobile: +86 1390 119 7481 > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > >>> > > >> > > > > > > > > > > > > > -- > > Yongheng Qi > > > > Mobile: +86 1390 119 7481 > > -- Yongheng Qi Mobile: +86 1390 119 7481 From rchertov at cs.ucsb.edu Tue Nov 24 21:46:03 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Tue, 24 Nov 2009 18:46:03 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> Message-ID: <4B0C9A6B.3090308@cs.ucsb.edu> When you run your original config on the gateway device, look at the dmesg output. If there are queue drops in any of the queues, you will notice that. If that is the case, you will have to modify your config. For example, you can play with the BURST parameter. Yongheng Qi wrote: > Thanks, Roman, > > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> Discard and > FromDevice(br-lan) > > both can get the 100Mbps throuthput, it is my etherlink limit. > > > > 2009/11/25 Roman Chertov > > > You can run Click on the receiver with the following config file. > > FromDevice(devX) -> ctr :: AverageCounter -> Discard; > > Then, you can look at the ctr stats to see what throughput you are > getting at the receiver. > > Yongheng Qi wrote: > > en, I am not sure, but I don't know how test the wireless > throughout put. > > > > but the wireless card on ap sta mode can get the 140Mbps. the monitor > > mode is > > > > our optimized. so it can get the same throughout put as ap sta mode. > > > > 2009/11/25 Roman Chertov > > >> > > > > Are you sure that your wireless link can transmit more than > 90Mbps? I > > would try to test the base performance of your source and > > destination first. > > > > Roman > > > > Yongheng Qi wrote: > > > Thanks, you advise is very importent for me. I think it not > the TCP > > > problem, because I test the UDP thoughout put. The same as > TCP. Cliff > > > say about kernel will memcpy every packet. Have the way > solve the > > > question? In the test, the kclick thread use more then 95% > CPU. The > > > eth0 driver use the opewrt include and the ath2 use the > atheros sdk. > > > These drivers may have problem? > > > > > > On 11/25/09, Roman Chertov > > >> > wrote: > > >> I failed to notice the config file... > > >> > > >> In addition to what Cliff said, you can try a simple test > where you > > >> configure Click as a transparent bridge to forward packets > > between two > > >> devices. Then, you can look at the counters to see where > the packet > > >> drops occur. > > >> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > > >> > > >> If the counters for FromDevice, Queue, and ToDevice are the > same, it > > >> means that you are dropping packets at eth0 driver. You > also need to > > >> keep track of how many packets you sent from the source to > help you > > >> diagnose the issue. > > >> > > >> Roman > > >> > > >> Cliff Frey wrote: > > >>> Your config looks reasonable to me. > > >>> > > >>> How are you measuring performance? I know if you are running > > TCP on the > > >>> devices as well (if you are testing tcp-to-the-device > rather than > > >>> forwarding > > >>> perfomance) that can slow things down (because of TCP > > checksumming and > > >>> because linux will keep a copy of every packet, causing > there to > > be a lot > > >>> more memcpy overhead). > > >>> > > >>> Also, often the drivers contribute a lot of the slowdown, even > > though this > > >>> is very hard to measure/see. > > >>> > > >>> It also seems as though you are using a br-lan device from > > linux, perhaps > > >>> the linux bridge code isn't very fast as well. > > >>> > > >>> You can benchmark click by loading the same config, but > with an > > >>> InfiniteSource instead of a FromHost or FromDevice, and a > > Discard instead > > >>> of > > >>> a ToHost/ToDevice, and seeing what performance you get there. > > That can > > >>> give > > >>> you a benchmark for the maximum possible speeds that you will > > see with > > >>> click. If that number is very high, then you need to be > > optimizing your > > >>> drivers or linux. If the number is low, then the problem > > probably is in > > >>> click. > > >>> > > >>> I know from experience that it is possible to forward more > than > > 140Mbps > > >>> using kernel click with linux on a mips board in the > 600-800 MHz > > range. > > >>> > > >>> Cliff > > >>> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > > > >> wrote: > > >>> > > >>>> Click performance is so poor. I only use 3 classifier and 1 > > iprewrite and > > >>>> other general packet process elements. > > >>>> > > >>>> At 680Mhz MIPS CPU, click actually can't process over 90Mbit > > data per > > >>>> second. > > >>>> > > >>>> The attachment is the click config file. anyone can tell > me how to > > >>>> optimize > > >>>> it. > > >>>> > > >>>> Thanks very much > > >>>> > > >>>> > > >>>> 2009/11/20 Yongheng Qi > > >> > > >>>> > > >>>>> Dear everyone. > > >>>>> > > >>>>> I use click roofnet process the 802.11n packet. test it use > > IxChariot. > > >>>> find > > >>>>> about 90Mbps, click use 100% cpu. > > >>>>> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > >>>>> > > >>>>> I don't know how to make click have more eiffciency. > > >>>>> > > >>>>> please help me, Thanks very much. > > >>>>> > > >>>>> -- > > >>>>> Yongheng Qi > > >>>>> > > >>>>> Mobile: +86 1390 119 7481 > > >>>>> > > >>>> > > >>>> -- > > >>>> Yongheng Qi > > >>>> > > >>>> Mobile: +86 1390 119 7481 > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > >>> > > >> > > > > > > > > > > > > > -- > > Yongheng Qi > > > > Mobile: +86 1390 119 7481 > > > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 From jetever at gmail.com Tue Nov 24 21:53:11 2009 From: jetever at gmail.com (Yongheng Qi) Date: Wed, 25 Nov 2009 10:53:11 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <4B0C9A6B.3090308@cs.ucsb.edu> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> Message-ID: <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> By the way, when test the two routes use wireless, both them kclick thread use more then 95% CPU load. I check all queue I am used, nothing be droped. how to play with the BURST parameter? Thanks 2009/11/25 Roman Chertov > When you run your original config on the gateway device, look at the > dmesg output. If there are queue drops in any of the queues, you will > notice that. If that is the case, you will have to modify your config. > For example, you can play with the BURST parameter. > > Yongheng Qi wrote: > > Thanks, Roman, > > > > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> Discard and > > FromDevice(br-lan) > > > > both can get the 100Mbps throuthput, it is my etherlink limit. > > > > > > > > 2009/11/25 Roman Chertov > > > > > > You can run Click on the receiver with the following config file. > > > > FromDevice(devX) -> ctr :: AverageCounter -> Discard; > > > > Then, you can look at the ctr stats to see what throughput you are > > getting at the receiver. > > > > Yongheng Qi wrote: > > > en, I am not sure, but I don't know how test the wireless > > throughout put. > > > > > > but the wireless card on ap sta mode can get the 140Mbps. the > monitor > > > mode is > > > > > > our optimized. so it can get the same throughout put as ap sta > mode. > > > > > > 2009/11/25 Roman Chertov > > > > >> > > > > > > Are you sure that your wireless link can transmit more than > > 90Mbps? I > > > would try to test the base performance of your source and > > > destination first. > > > > > > Roman > > > > > > Yongheng Qi wrote: > > > > Thanks, you advise is very importent for me. I think it not > > the TCP > > > > problem, because I test the UDP thoughout put. The same as > > TCP. Cliff > > > > say about kernel will memcpy every packet. Have the way > > solve the > > > > question? In the test, the kclick thread use more then 95% > > CPU. The > > > > eth0 driver use the opewrt include and the ath2 use the > > atheros sdk. > > > > These drivers may have problem? > > > > > > > > On 11/25/09, Roman Chertov > > > > >> > > wrote: > > > >> I failed to notice the config file... > > > >> > > > >> In addition to what Cliff said, you can try a simple test > > where you > > > >> configure Click as a transparent bridge to forward packets > > > between two > > > >> devices. Then, you can look at the counters to see where > > the packet > > > >> drops occur. > > > >> > > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > > > >> > > > >> If the counters for FromDevice, Queue, and ToDevice are the > > same, it > > > >> means that you are dropping packets at eth0 driver. You > > also need to > > > >> keep track of how many packets you sent from the source to > > help you > > > >> diagnose the issue. > > > >> > > > >> Roman > > > >> > > > >> Cliff Frey wrote: > > > >>> Your config looks reasonable to me. > > > >>> > > > >>> How are you measuring performance? I know if you are > running > > > TCP on the > > > >>> devices as well (if you are testing tcp-to-the-device > > rather than > > > >>> forwarding > > > >>> perfomance) that can slow things down (because of TCP > > > checksumming and > > > >>> because linux will keep a copy of every packet, causing > > there to > > > be a lot > > > >>> more memcpy overhead). > > > >>> > > > >>> Also, often the drivers contribute a lot of the slowdown, > even > > > though this > > > >>> is very hard to measure/see. > > > >>> > > > >>> It also seems as though you are using a br-lan device from > > > linux, perhaps > > > >>> the linux bridge code isn't very fast as well. > > > >>> > > > >>> You can benchmark click by loading the same config, but > > with an > > > >>> InfiniteSource instead of a FromHost or FromDevice, and a > > > Discard instead > > > >>> of > > > >>> a ToHost/ToDevice, and seeing what performance you get > there. > > > That can > > > >>> give > > > >>> you a benchmark for the maximum possible speeds that you > will > > > see with > > > >>> click. If that number is very high, then you need to be > > > optimizing your > > > >>> drivers or linux. If the number is low, then the problem > > > probably is in > > > >>> click. > > > >>> > > > >>> I know from experience that it is possible to forward more > > than > > > 140Mbps > > > >>> using kernel click with linux on a mips board in the > > 600-800 MHz > > > range. > > > >>> > > > >>> Cliff > > > >>> > > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > > > > > >> wrote: > > > >>> > > > >>>> Click performance is so poor. I only use 3 classifier and > 1 > > > iprewrite and > > > >>>> other general packet process elements. > > > >>>> > > > >>>> At 680Mhz MIPS CPU, click actually can't process over > 90Mbit > > > data per > > > >>>> second. > > > >>>> > > > >>>> The attachment is the click config file. anyone can tell > > me how to > > > >>>> optimize > > > >>>> it. > > > >>>> > > > >>>> Thanks very much > > > >>>> > > > >>>> > > > >>>> 2009/11/20 Yongheng Qi > > > > >> > > > >>>> > > > >>>>> Dear everyone. > > > >>>>> > > > >>>>> I use click roofnet process the 802.11n packet. test it > use > > > IxChariot. > > > >>>> find > > > >>>>> about 90Mbps, click use 100% cpu. > > > >>>>> > > > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > > >>>>> > > > >>>>> I don't know how to make click have more eiffciency. > > > >>>>> > > > >>>>> please help me, Thanks very much. > > > >>>>> > > > >>>>> -- > > > >>>>> Yongheng Qi > > > >>>>> > > > >>>>> Mobile: +86 1390 119 7481 > > > >>>>> > > > >>>> > > > >>>> -- > > > >>>> Yongheng Qi > > > >>>> > > > >>>> Mobile: +86 1390 119 7481 > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > >>> > > > >> > > > > > > > > > > > > > > > > > > > -- > > > Yongheng Qi > > > > > > Mobile: +86 1390 119 7481 > > > > > > > > > > -- > > Yongheng Qi > > > > Mobile: +86 1390 119 7481 > > -- Yongheng Qi Mobile: +86 1390 119 7481 -------------- next part -------------- A non-text attachment was scrubbed... Name: sr2.click_c Type: application/octet-stream Size: 6735 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091125/9b8c2b2d/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: sr2.click_gw Type: application/octet-stream Size: 8477 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091125/9b8c2b2d/attachment-0003.obj From harald at net.t-labs.tu-berlin.de Wed Nov 25 09:11:53 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Wed, 25 Nov 2009 15:11:53 +0100 Subject: [Click] compiling the old 2.6.24.7 kernel with recent compilers Message-ID: <4B0D3B29.7000603@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, for those of you who want to build the linuxmodule for x86: The latest "officially" supported click kernel is 2.6.24.7. This does not build with recent compilers (4.4) on x86, but there is a backport fix here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=811a0fff5d6e80e18e06be88e0fb685f3924bf8f seems to build now.... - -- 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 iD8DBQFLDTspy8wrZ9OvkU0RAoYIAJ4ziXvVoOCNtWDhuAD7HohoS/tM1QCcD3LL ccnKJW39/N1N/0ab+DtljBQ= =EZMY -----END PGP SIGNATURE----- From harald at net.t-labs.tu-berlin.de Wed Nov 25 12:49:31 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Wed, 25 Nov 2009 18:49:31 +0100 Subject: [Click] bug in the new timer functions Message-ID: <4B0D6E2B.6040503@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks a lot for giving us simulation time, yet..... (I'll revert a few commits for the time beeing) make[1]: Entering directory `/usr/src/click/linuxmodule' make -C /lib/modules/2.6.24.7/build M=/usr/src/click/linuxmodule modules make[2]: Entering directory `/usr/src/linux-2.6.24.7' CXX [M] arpquerier.o make[2]: Leaving directory `/usr/src/linux-2.6.24.7' make[1]: Leaving directory `/usr/src/click/linuxmodule' make[1]: Entering directory `/usr/src/click/linuxmodule' make -C /lib/modules/2.6.24.7/build M=/usr/src/click/linuxmodule modules make[2]: Entering directory `/usr/src/linux-2.6.24.7' CXX [M] arpquerier.o In file included from /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.hh:8, from /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.cc:21: /usr/src/click/linuxmodule/../elements/ethernet/arptable.hh: In member function 'Timestamp ARPTable::timeout() const': /usr/src/click/linuxmodule/../elements/ethernet/arptable.hh:117: error: call of overloaded 'make_jiffies(const uint32_t&)' is ambiguous /usr/src/click/linuxmodule/../include/click/timestamp.hh:913: note: candidates are: static Timestamp Timestamp::make_jiffies(click_jiffies_t) /usr/src/click/linuxmodule/../include/click/timestamp.hh:927: note: static Timestamp Timestamp::make_jiffies(click_jiffies_difference_t) /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.cc: In member function 'virtual int ARPQuerier::live_reconfigure(Vector&, ErrorHandler*)': /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.cc:114: error: call of overloaded 'make_jiffies(uint32_t&)' is ambiguous /usr/src/click/linuxmodule/../include/click/timestamp.hh:913: note: candidates are: static Timestamp Timestamp::make_jiffies(click_jiffies_t) /usr/src/click/linuxmodule/../include/click/timestamp.hh:927: note: static Timestamp Timestamp::make_jiffies(click_jiffies_difference_t) make[3]: *** [/usr/src/click/linuxmodule/arpquerier.o] Error 1 make[2]: *** [_module_/usr/src/click/linuxmodule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.24.7' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/click/linuxmodule' make: *** [linuxmodule] Error 2 - -- 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 iD8DBQFLDW4qy8wrZ9OvkU0RArLyAKDkmpWJTCl7UmIq/rZql4WHGRSbWACfb3U2 ZNZj1qczNDH+fvEPDevC0KY= =Xg5n -----END PGP SIGNATURE----- From harald at net.t-labs.tu-berlin.de Wed Nov 25 13:12:13 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Wed, 25 Nov 2009 19:12:13 +0100 Subject: [Click] why does linuxkernel not install to kernel Message-ID: <4B0D737D.6080005@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 is there (still?) a reason for not installing the kernel module to the right place : linuxmodule/Makefile: # Don't install in Linux directories for now # $(MAKE) -C $(KERNELPATH) M=$(shell pwd) modules_install install: Makefile $(ELEMENTSCONF).mk $(ELEMENTSCONF).cc all [...] - -- 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 iD8DBQFLDXN8y8wrZ9OvkU0RApW1AJ47lbCa42oJiu6Ut7TMf8sCCaByhACfcVNY mz5z4jxYTmmgR/G2d7MiLB4= =aLtK -----END PGP SIGNATURE----- From harald at net.t-labs.tu-berlin.de Wed Nov 25 14:29:29 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Wed, 25 Nov 2009 20:29:29 +0100 Subject: [Click] linuxpatchless devel virtual machine Message-ID: <4B0D8599.10503@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, for the development of linuxpatchless (I will write a short explanation for those of you who were not on syclick, you definately missed a really great event) I created a debian-5.0 x86 based image for virtualbox-3.0, here it is: http://www.net.t-labs.tu-berlin.de/~harald/click-dev.vdi.bz2 (1GB download, 3GB unpacked) This runs a vanilla 2.6.24.7 kernel with the compile fix from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=811a0fff5d6e80e18e06be88e0fb685f3924bf8f and the click patches the click sources are found in /usr/src/click git is set up to track "master" from eddie and "linuxpatchless" from our git server git://bowl.net.t-labs.tu-berlin.de/click.git the linuxpatchless branch currently only contains the option to configure --enable-linuxpatchless which will cause a linuxmodule build in the linuxpatchless directory. this is a copy of the linuxmodule directory. I suggest that all patches go into this directory. the root password is "click", be aware that an ssh server is started at boot time, so you may want to change that if you connect it to a public network. no other valid users exist. - -- 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 iD8DBQFLDYWZy8wrZ9OvkU0RAt87AJ4qcQ6VgaeWowHmoLrNaxm6kD0O1ACgy31E eznQS0t6Zxm+p+ppH1uKx28= =LfUF -----END PGP SIGNATURE----- From harald at net.t-labs.tu-berlin.de Wed Nov 25 15:02:34 2009 From: harald at net.t-labs.tu-berlin.de (=?ISO-8859-1?Q?Harald_Schi=F6berg?=) Date: Wed, 25 Nov 2009 21:02:34 +0100 Subject: [Click] linuxpatchless Message-ID: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, this is the promised explanation of the linuxpatchless project. At least how I remember it, so please share whatever I got wrong. On the developer day of the syclick symposium, roughly 10 people started a discussion of how great it would be to run kernel level click without the need for a kernel patch. Most of us were driven by the demand to run click on OpenWRT, which is close to impossible given the current hassle with click's patches and the speed OpenWRT evolves. So we looked at what is there and found: - - a huge mess of syntactic patches, which serve the purpose of allowing the kernel includes to be used by C++ - - a small functional patch which adds click's hooks to grab packets from the kernel and to add the polling driver for intel e1000 cards some folks around Adam started to split those different parts into the two relevant parts, and afaik have succeeded. On the syntactic patches: We agreed that instead of patching the kernel sources in the kernel, we would better copy a build time the include/ hierarchy to click's build dir and patch them there. Eddie started to pick up on his patch-making perl magic and tries to write some magic to automatically mangle those into C++ compliance independently from the kernel version used. For documentation: Everthing should be simple almost regular expressions, like the notorious - - asm ( foo :: bar ) + asm ( foo : : bar ) One notable exception: the current click patch changes - - struct foo {} + EMPTY_STRUCT_DECL(foo) The EMPTY_STRUCT_DECL is one byte long, because empty structs are one byte in C++ but zero bytes in C. so this actually changes linux's internal structures. The prosed solution it to redefine that into a char[0] with is also zero bytes in C++, so we can still interface with the now unpatched structures of the kernel. On the functional patches: We will try to exchange anything in the linuxpatchless directory that accesses one of click's hooks into something that uses a similar linux hook instead. Probably only the FromDevice and ToDevice Elements will have to be updated. The theory converged on registering click with dev_add_pack() and then overwriting skb->protocol in the received sk_buffs to prevent other's from handling the packet as well... Whoever feels more practical: post your patches ;-) That's all I remember on that part, a BIG THANK YOU again to the organizers of syclick who made all that possible in the first place. - -- 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 iD8DBQFLDY1ay8wrZ9OvkU0RAniwAJ9slIU/lUypJovGmTYIfMKW5G5hXwCfWCi0 ay61mfOJbRUcXRlXEeg9Xdc= =Udn3 -----END PGP SIGNATURE----- From kohler at cs.ucla.edu Wed Nov 25 05:21:06 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 25 Nov 2009 11:21:06 +0100 Subject: [Click] Mac OS X assert failed when trying to use KernelTun In-Reply-To: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> References: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> Message-ID: <4B0D0512.3010706@cs.ucla.edu> Pekka, Thans very much for this note! There was indeed a bug in the select handling -- we essentially assumed that every file descriptor was present in some array for both reading and writing. This should be fixed now. Let us know if you have any further issues. Eddie Pekka Nikander wrote: > I'm a relative newbie to Click, and trying to use KernelTun on Mac OS X, with the latest GIT version. Unfortunately it looks like that there is a bug, apparently related to the interactions between kevents and select/poll. > > The OS X tun/tap devices don't currently support kevents, and therefore click tries to back off to use select/poll. However, once it gets to the actual poll in master.cc, something has gone wrong and I get a an assertion failure on line 850 in master.cc: > > Element *read_elt = (p->revents & ~POLLOUT ? _read_elements[fd] : 0); > > This results in an assertion failure, with this trivial script: > > click -e "KernelTun(192.168.15.1/24) -> Discard" > Assertion failed: (i>=0 && i<_n), function operator[], file ../include/click/vector.hh, line 184. > Abort trap > > My gut feeling is that the bug may line somewhere in master.cc Master:add_select, in the code that tries to make sure that one can fall back to select/poll in the case of kqueue error. But I may be wrong. > > In any case, when tracing the execution in opening the tun/tap device, the kevent system call at line 602 of master.cc fails, causing the _kqueue socket to be closed and made unused. However, much before that I can see with ifconfig that the tun/tap interface is indeed open and correctly ifconfig'ed. > > Anyone an idea where to continue debugging? Or would it be easier to add KEVENT support to the Mac tun/tap kexts? > > --Pekka Nikander > > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Nov 25 07:27:51 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 25 Nov 2009 13:27:51 +0100 Subject: [Click] Problem with KernetTun In-Reply-To: <4B043D73.9040006@create-net.org> References: <4B043D73.9040006@create-net.org> Message-ID: <4B0D22C7.6000902@cs.ucla.edu> Roberto, Thanks for the info, what an immense disaster. Looks like we need to find that offset at configure time. I've tried to fix it. E Roberto Riggio wrote: > Hi, > > after the last commit to KernelTun i'm getting the following > error when I try to cross-compile click with openwrt (both ixp4xx > and x86 targets). > > CXX ../elements/userlevel/kerneltun.cc > ../elements/userlevel/kerneltun.cc: In member function 'int > KernelTun::updown(IPAddress, IPAddress, ErrorHandler*)': > ../elements/userlevel/kerneltun.cc:262: error: array bound is not an > integer constant > > gcc version is 4.1.2. > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Nov 25 15:31:07 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 25 Nov 2009 15:31:07 -0500 Subject: [Click] FromDump format In-Reply-To: <4AA7A3C1.5020407@net.t-labs.tu-berlin.de> References: <4AA7A3C1.5020407@net.t-labs.tu-berlin.de> Message-ID: <4B0D940B.5040503@cs.ucla.edu> ToDump will also generate pcap files (as I'm sure you know). E Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mar?a G?mez wrote: >> Hello clickers!! >> >> I have a couple of questions about the FromDump element: >> >> 1- I >> have captured the traffic with tcpdump and wireshark and with 'FromDevice(ath0)-> ToDump(capture.dump)' (i use .dump and .cap), >> but I don't know if the file >> format is correct. That is, the format must be in some specific way? > > FromDump uses pcap format[1], which is a binary format containing some > meta-data and the literal packets , use tcpdump -w to write pcap files > >> For example: >> 'time' IP 1.0.0.1.1234 2.0.0.2.1234 : UDP, length 80 > > this is an ascii pretty print, but no dump format > >> 2- Why not print IPPrint element? My configuration: > > because it again gives you some pretty print, but no pcap file > > harald > > 1) e.g. http://wiki.wireshark.org/Development/LibpcapFileFormat > > > - -- > 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 > > iD8DBQFKp6PBy8wrZ9OvkU0RAvbPAKCvIViZrZhjATDkb+05ctd+dy7OPQCfQI0Y > ctXJUhI2YmHuLI5f3BxI+u8= > =7M/y > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Nov 25 15:44:17 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 25 Nov 2009 15:44:17 -0500 Subject: [Click] bug in the new timer functions In-Reply-To: <4B0D6E2B.6040503@net.t-labs.tu-berlin.de> References: <4B0D6E2B.6040503@net.t-labs.tu-berlin.de> Message-ID: <4B0D9721.20907@cs.ucla.edu> Whoops. This is fixed, thanks! E Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Thanks a lot for giving us simulation time, yet..... > > (I'll revert a few commits for the time beeing) > > > make[1]: Entering directory `/usr/src/click/linuxmodule' > make -C /lib/modules/2.6.24.7/build M=/usr/src/click/linuxmodule modules > make[2]: Entering directory `/usr/src/linux-2.6.24.7' > CXX [M] arpquerier.o > make[2]: Leaving directory `/usr/src/linux-2.6.24.7' > make[1]: Leaving directory `/usr/src/click/linuxmodule' > make[1]: Entering directory `/usr/src/click/linuxmodule' > make -C /lib/modules/2.6.24.7/build M=/usr/src/click/linuxmodule modules > make[2]: Entering directory `/usr/src/linux-2.6.24.7' > CXX [M] arpquerier.o > In file included from > /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.hh:8, > from > /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.cc:21: > /usr/src/click/linuxmodule/../elements/ethernet/arptable.hh: In member > function 'Timestamp ARPTable::timeout() const': > /usr/src/click/linuxmodule/../elements/ethernet/arptable.hh:117: error: > call of overloaded 'make_jiffies(const uint32_t&)' is ambiguous > /usr/src/click/linuxmodule/../include/click/timestamp.hh:913: note: > candidates are: static Timestamp Timestamp::make_jiffies(click_jiffies_t) > /usr/src/click/linuxmodule/../include/click/timestamp.hh:927: note: > static Timestamp > Timestamp::make_jiffies(click_jiffies_difference_t) > /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.cc: In member > function 'virtual int ARPQuerier::live_reconfigure(Vector&, > ErrorHandler*)': > /usr/src/click/linuxmodule/../elements/ethernet/arpquerier.cc:114: > error: call of overloaded 'make_jiffies(uint32_t&)' is ambiguous > /usr/src/click/linuxmodule/../include/click/timestamp.hh:913: note: > candidates are: static Timestamp Timestamp::make_jiffies(click_jiffies_t) > /usr/src/click/linuxmodule/../include/click/timestamp.hh:927: note: > static Timestamp > Timestamp::make_jiffies(click_jiffies_difference_t) > make[3]: *** [/usr/src/click/linuxmodule/arpquerier.o] Error 1 > make[2]: *** [_module_/usr/src/click/linuxmodule] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.6.24.7' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/usr/src/click/linuxmodule' > make: *** [linuxmodule] Error 2 > > > - -- > 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 > > iD8DBQFLDW4qy8wrZ9OvkU0RArLyAKDkmpWJTCl7UmIq/rZql4WHGRSbWACfb3U2 > ZNZj1qczNDH+fvEPDevC0KY= > =Xg5n > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Nov 25 04:42:47 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 25 Nov 2009 10:42:47 +0100 Subject: [Click] IP header check failed: In-Reply-To: References: Message-ID: <4B0CFC17.80403@cs.ucla.edu> Hi, The packet has a length of 1498 but the dump has captured less than the complete length. As you can see from your print statements, only 68 bytes were captured. CheckIPHeader expects complete IP packets; it can't check the length or checksum of incomplete packets. Eddie Latency Buster wrote: > I am trying to separate out multicast packets. Before feeding to the > IPClassifier, when I pass it through CheckIPHeader(), I recv lots of > IP HEader Failed Messages. The input packets are multicast packets but > the IP header is clean (as looked via wireshark). Any insights why > this might occur? > > > > ------------------ CONFIG --------------------------------------- > inputDevice::FromDump(/home/click/test.pcap, END_AFTER 0.2); > > inputDevice->c0::Classifier (12/8100 /* dot1Q */, 12/0800 /* > 'normal ip packets */, - /* everything else including ARP */); > > // Filter out multicast packets > ip_classifier::IPClassifier(224.0.0.0/4 and ip proto udp, - /* > everything else */); > > > c0[0]-> Print("We received 802.1Q Packets.. Discarding") -> Discard; > c0[1]-> ip::CheckIPHeader (14, INTERFACES 224.0.0.0/4, VERBOSE > true,CHECKSUM false); > c0[2]-> Discard; > > ip[0] -> ip_classifier; > ip[1] -> Print("IP header Failed..", 20) -> ToDump (/home/click/badip.pcap); > > ip_classifier[0]->Print("These are valid Multicast Packets for NAT") -> Discard; > ip_classifier[1]->Print ("This will all go to LINUX Host")-> Discard; > > ----------------------------- END OF CONFIG -------------------------- > > click-user:~/ click test_mcast.click > > IP header Failed..: 68 | 01005e43 0d0d001b 0ded1180 08004500 > 05da3e82 00001c11 337fac15 7e2cefc3 0d0dbb60 138905c6 364d0000 > 04534b07 0d32000f 30490000 00000000 00010000 13890000 > > IP header Failed..: 68 |01005e43 0d0d001b 0ded1180 08004500 05da3e83 > 00001c11 337eac15 7e2cefc3 0d0dbb60 138905c6 4ccb0000 04544b07 > 0d330000 19d80000 00000000 00010000 13890000 > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Nov 25 15:21:00 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 25 Nov 2009 15:21:00 -0500 Subject: [Click] Weird behavior under OSX Snow Leopard... In-Reply-To: <870845C6-EF7B-4733-BD4C-D79C1351C2B6@ICSI.Berkeley.EDU> References: <870845C6-EF7B-4733-BD4C-D79C1351C2B6@ICSI.Berkeley.EDU> Message-ID: <4B0D91AC.7080408@cs.ucla.edu> Hi Nick, That's pretty weird. The code in FromDevice.u is pretty simple itself; on OS X it's a wrapper around the pcap library. There is no queue inside FromDevice itself. Perhaps this is related to the select()/poll() problems others reported. Can you confirm that tcpdump works as expected, generating packets one at a time? Does OS X pcap support pcap_setnonblock()? (config-userlevel.h should have HAVE_PCAP_SETNONBLOCK.) If not, can you try to get rid of the fcntl() on fromdevice.cc:230? Eddie Nicholas Weaver wrote: > I'm seeing some very weird behavior under OSX on FromDevice... > > The very simple code: > FromDevice(en0, PROMISC true) -> Print("en0") -> Queue -> ToDevice(en1); > > What happens is no packets are received by the Print command until > some internal buffer in the FromDevice fills up, and then they are all > delivered at once in a big burst, through the queue, and out the en1 > interface. > > Suggestions? > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Wed Nov 25 15:46:58 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Wed, 25 Nov 2009 15:46:58 -0500 Subject: [Click] why does linuxkernel not install to kernel In-Reply-To: <4B0D737D.6080005@net.t-labs.tu-berlin.de> References: <4B0D737D.6080005@net.t-labs.tu-berlin.de> Message-ID: <4B0D97C2.8000909@cs.ucla.edu> Hi, The simple answer is, No... although I rather like having all the Click install files in the same place, I don't really care either way. Eddie Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > is there (still?) a reason for not installing the kernel module to the > right place : > > linuxmodule/Makefile: > > # Don't install in Linux directories for now > # $(MAKE) -C $(KERNELPATH) M=$(shell pwd) modules_install > install: Makefile $(ELEMENTSCONF).mk $(ELEMENTSCONF).cc all > [...] > > > - -- > 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 > > iD8DBQFLDXN8y8wrZ9OvkU0RApW1AJ47lbCa42oJiu6Ut7TMf8sCCaByhACfcVNY > mz5z4jxYTmmgR/G2d7MiLB4= > =aLtK > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From brampton+click at gmail.com Wed Nov 25 18:16:19 2009 From: brampton+click at gmail.com (Andrew Brampton) Date: Wed, 25 Nov 2009 23:16:19 +0000 Subject: [Click] RFC: Annotations In-Reply-To: References: Message-ID: For those of you who weren't just at SyClick there was some discussion on how to improve annotations within Click. The work was split into two parts, firstly a way to add any number of arbitrary annotations to a packet, and secondly, a way to tag each element with a list of which annotations they require and change, and then figure out if a elements reads a annotation which has not been previously set. I'm interested in the former annotation change, and I would like to continue the discussion about it on this mailing list. There was a lot of discussion at SyClick, so not all of this is my work. I would appreciate if others gave feedback and suggestions. Additionally I'm writing this from a airport without wifi, so my facts may be slightly wrong. Description: ?Packet annotations are a way to add extra information to a packet as it flows through Click. Examples include; a paint annotation which virtually colours a packet, a destination annotation that allows destination IP address to be attached to a packet, even if it doesn't have a valid header. Currently annotations seem to be simple integers, ranging from one to a few bytes. Each packet can also contain multiple annotations. (I would be interested to know how many and which annotations people are typically using?) Problem: ?P1. A packet is limited to 48 bytes of annotations, due to a limited available space in the linux kernel's skbuf. ?P2. Due to the limited space, many annotations accidentally write over each other in this small 48byte annotation space. Requirements: R1. All existing annotations should be supported. R2. There are people that annotate packets in high performance systems. Therefore adding and removing annotations should as least costly as possible. R3. A unlimited number of annotations should be supported on each packet. R4. Annotations should be flexible to hold any size of data, as well as being extendable so that new types of annotations are easily added. R5. Annotations should not override each other. R6. When a Packet is cloned, the annotations must also be cloned. R7. Annotations are allowed to be pointers to other objects. This causes issues because if a packet is cloned, so must the annotations. If the annotation is a pointer click might also have to clone the annotation, and equally Click must destroy them when the Packet is discarded. SyClick Solution: The solution invented at SyClick involved creating a new AnnotationSpace array of type Annotation *. Each element in the array pointed to a Annotation class. The existing 48 byte array in the Packet had a pointer stored in the last 4 or 8 bytes, which pointed to this the AnnotationSpace. Each index in the AnnotationSpace was exclusively used by a different Annotation type. For example, to add a paint annotation you would create a PaintAnnotation class which extends Annotation. This class would, for example, store a single integer to represent the paint colour. You would then define a unique number for this annotation, for example, 10. To set the paint annotation you would first find the AnnotationSpace pointer in the Packet, then check if index 10 contain a valid pointer, if not you would create a PaintAnnotation object. Finally you would set the value on this instance. A added bonus was that you could still use the first 40-44 bytes in the Packet for existing annotations, allowing Click to slowly transition to the new scheme. I hope I have correctly remembered and represented this solution. SyClick solution problems: I believe that the original solution did not consider a high performance requirements. Therefore, mallocing a AnnotationSpace, and then another malloc for each Annotation is very costly in both CPU and memory. Secondly if you still allow use to the 40-44 byte annotation area, you will run the risk of violating requirement 5. It does satisfy requirement 7 as long as each Annotaton subclass is clonable, and when a Packet is cloned it must clone each Annotation and the AnnotationSpace. To get some background on the problem, and see what other people have done when faced with a similar problem I have described how both FreeBSD and Linux do a similar thing. FreeBSD kernel solution: Inside the FreeBSD kernel (not click), each packet is stored in a mbuf. A type of annotation can be added to these mbufs called mbuf_tags. These tags contain a integer type identifier as well as a data associated with the tag. Each mbuf can points to a linked list of these mbuf_tags. To add a new tag you simply add it to the end of the linked list. To search if a tag is set you must walk the linked list. This has pros and cons, firstly it is flexible and very extendable without wasting memory. However, it does require a malloc for each mbuf_tag. FreeBSD migrates this malloc cost by having preallocated pools of tags which speeds up tag allocation. Linux kernel solution: Inside a non click Linux kernel, each packet is stored in a skbuf. These skbufs have many fields, each one for a different annotation. Each time a annotation is added or removed the skbuf struct changes. In my opinion this solution is ugly, but it easy, work well and maintains high performance. A hybrid solution (aka my solution): There are only 48 bytes of space available, so if you want an unlimited number of annotations, you will eventually have to malloc some addition space. Therefore I suggest a hybrid approach, where the 48byte area is used for as long as possible, and then when you need more space you move to a new linked list area. To facilitate this I suggest that each annotation has a unique number. The 48byte area is then divided into multiple annotations where each annotation looks like: struct { ?char size; // the size of the data field ?char id; ?char data[]; } The number of annotations within the 48byte area would depend on the data size. For example: Data Size (in bytes), # of annotations 1, 16 2, 12 4, 8 8, 4.8 As soon as we run out of space in the 48 byte area we malloc a new annotation area at least as big as the inserted annotation, but most likely a lot larger. We can then chain these 48byte area to the new area using a special next annotations annotation. To check if the packet has a particular annotation this structure will have to be linearly traversed. This may not be a issue if there are only a couple of annotations on the packet, but if there are 10 or 20 you may lose performance again (I will have to benchmark that). Also, this scheme makes it hard to include complex annotations, such as a pointer to a object. As cloning and deleting will cause memory leaks. While sat here in the airport I've come up with a number of different ideas, here are some more: A slow/fast annotation: Perhaps we should split the annotation space into slow and fast areas. The fast area will exclusively use the 48 byte area, while the slow area will use some external malloced space. The slow area could also allow custom clone and cleanup handlers to ensure that any pointers to class can be dealt with correctly. The fast area will work exactly how it works now, so we have many of the problems we have now, but with perhaps less annotations trying to be stuffed in it (unless of cause want a fast system). A annotation offset table: We use the 48byte area, however, we ensure that no more than 48 bytes of annotation may be configured in a single click configuration. Some code would parse all the Elements within the Click configuration and identify which annotations are being used. Then Click determines a different byte offset for each annotation to exclusively use within the 48 byte area. For example, say a destination IP address and paint annotation are being used. The first annotation (dest IP) would be assigned zero (the beginning of the 48 byte area), and paint would be assigned 4. Paint is assigned 4 because the first annotation takes 4 bytes, and paint is to appear after it. When a annotation is written to a Packet, the offset would be looked up in this table and written to the correct place. This system would ensure that annotations do not override each other. The system should also be fast because it is the same as existing just with one level of indirection. However, we are still limited to 48 bytes, and we don't easily support pointers to objects. A more bizzare/clever solution? I still think there might be a better way to do all this, so I'm welcome for any suggestions. What's next? I hope people will read all the way down to here :) I also hope people will give their feedback and suggestions. I might code up a couple of the solutions and benchmark them. thanks Andrew From pekka.nikander at nomadiclab.com Thu Nov 26 05:57:45 2009 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Thu, 26 Nov 2009 12:57:45 +0200 Subject: [Click] Mac OS X assert failed when trying to use KernelTun In-Reply-To: <4B0D0512.3010706@cs.ucla.edu> References: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> <4B0D0512.3010706@cs.ucla.edu> Message-ID: Eddie, Thanks, it works! I needed to do two other small things to get it working: 1. It didn't compile out of last night's git; the following patch made it to compile: --- a/lib/timestamp.cc +++ b/lib/timestamp.cc @@ -67,7 +67,7 @@ Timestamp::warp(bool from_now) if (_warp_class == warp_simulation) { *this = _warp_flat_offset; if (from_now) { -# if TIMESTAMP_MATH_FLAT64 +# if TIMESTAMP_REP_FLAT64 || TIMESTAMP_MATH_FLAT64 ++_warp_flat_offset._t.x; # else ++_warp_flat_offset._t.subsec; I'm not sure if that is the right patch, though... 2. Mac OS X tun devices are point-to-point links, requiring both a local and remote IP address. Right now click configures only the local one, resulting in an interface like the following: $ ifconfig tun0 tun0: flags=8951 mtu 1500 inet 192.168.15.1 --> 0.0.0.0 netmask 0xffffff00 open (pid 63049) Once I added a remote address there with ifconfig, it started to work: # ifconfig tun0 192.168.15.1 192.168.16.1 # click -e "tun :: KernelTun(192.168.15.1/24); tun -> IPPrint -> Discard" & # ping 192.168.16.1 > /dev/null 2>&1 1259231868.596160: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 0) 1259231869.596198: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 256) 1259231870.596240: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 512) 1259231871.596328: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 768) 1259231872.596394: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1024) 1259231873.596553: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1280) Alternatively, I was also able to do the same by manipulating the routing table: # route add -net 192.168.16.0 192.168.15.1 However, pinging anything on the local subnet 192.168.15.0/24 doesn't go to the click process. I guess the documentation should be updated... Anyway, this should be enough slay some GMPLS Dragons locally on Mac OS X. :-) --Pekka On 2009-11 -25, at 12:21 , Eddie Kohler wrote: > Pekka, > > Thans very much for this note! There was indeed a bug in the select handling -- we essentially assumed that every file descriptor was present in some array for both reading and writing. This should be fixed now. Let us know if you have any further issues. > > Eddie > > > Pekka Nikander wrote: >> I'm a relative newbie to Click, and trying to use KernelTun on Mac OS X, with the latest GIT version. Unfortunately it looks like that there is a bug, apparently related to the interactions between kevents and select/poll. The OS X tun/tap devices don't currently support kevents, and therefore click tries to back off to use select/poll. However, once it gets to the actual poll in master.cc, something has gone wrong and I get a an assertion failure on line 850 in master.cc: >> Element *read_elt = (p->revents & ~POLLOUT ? _read_elements[fd] : 0); >> This results in an assertion failure, with this trivial script: >> click -e "KernelTun(192.168.15.1/24) -> Discard" >> Assertion failed: (i>=0 && i<_n), function operator[], file ../include/click/vector.hh, line 184. >> Abort trap >> My gut feeling is that the bug may line somewhere in master.cc Master:add_select, in the code that tries to make sure that one can fall back to select/poll in the case of kqueue error. But I may be wrong. >> In any case, when tracing the execution in opening the tun/tap device, the kevent system call at line 602 of master.cc fails, causing the _kqueue socket to be closed and made unused. However, much before that I can see with ifconfig that the tun/tap interface is indeed open and correctly ifconfig'ed. >> Anyone an idea where to continue debugging? Or would it be easier to add KEVENT support to the Mac tun/tap kexts? >> --Pekka Nikander >> _______________________________________________ >> 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 Nov 26 07:48:52 2009 From: bart.braem at ua.ac.be (Bart Braem) Date: Thu, 26 Nov 2009 13:48:52 +0100 Subject: [Click] RFC: Annotations In-Reply-To: References: Message-ID: Hi Andrew, Thanks for this long and very correct representation of the SyClick discussion. I am very much interested in this problem, so I will give my view on the situation below. Let me tell you first why I believe this is necessary. The main motivation to me flexibility. Anyone can write an own element and consider everything else a black box. Everything works out of the box. Except, when you use annotations. Then, all of a sudden you need to take care of possible conflicts. And that does not feel right. So, on to the solutions you mentioned. I fully agree on the advantages and disadvantages you listed for all possible solutions. The largest issue to tackle seems the tradeoff between speed (aka the current implementation) and flexibility (aka the SyClick implementation). This last solution comes very close to the ideal balance, in my opinion: On 26 Nov 2009, at 00:16, Andrew Brampton wrote: > A annotation offset table: > We use the 48byte area, however, we ensure that no more than 48 bytes > of annotation may be configured in a single click configuration. Some > code would parse all the Elements within the Click configuration and > identify which annotations are being used. Then Click determines a > different byte offset for each annotation to exclusively use within > the 48 byte area. For example, say a destination IP address and paint > annotation are being used. The first annotation (dest IP) would be > assigned zero (the beginning of the 48 byte area), and paint would be > assigned 4. Paint is assigned 4 because the first annotation takes 4 > bytes, and paint is to appear after it. > > When a annotation is written to a Packet, the offset would be looked > up in this table and written to the correct place. This system would > ensure that annotations do not override each other. The system should > also be fast because it is the same as existing just with one level of > indirection. However, we are still limited to 48 bytes, and we don't > easily support pointers to objects. So we are still facing a flexibility problem. This time, in the buffer size. I have discussed this over lunch with Kurt Smolderen, who was in the coding group at SyClick. We came up with the following idea. The key is to precompute everything at compile time. The system generates annotation macros, based on a annotation_preferences file. This file is generated based on the elements, see later. Elements can use these get and set macros, the system will of course generate compilation errors if the annotations are not defined. The annotation_preferences file defines preference of annotations: it specifies whether an annotation should preferably be stored in the small 48 byte buffer, or in a larger map that requires indirection. This way, standard annotations like paint or dst_ip_anno can have larger preference and can be used more quickly. The generation of the structure to fit in the 48 bytes, takes into account the platform (for the size of the pointer to the larger map), the annotation preference and alignment. Some rather intelligent algorithms could be used to make sure the bytes are used wisely. The larger map will just be a struct, with the annotations in it. This means for this map, only 1 indirection is needed. As we know in advance where each annotation will be in the struct, things will be very fast for lookups. No list traversal is required. The generated macros will either refer to the 48 byte struct or the larger map struct, meaning they will be quick and easy to generate. To generate the annotation_preferences file, a new macro is introduced: REQUIRES_ANNO(NAME, TYPE, PREF=255) At least one element using the annotation, preferably the one setting it, should use this macro. Duplicate definition of the annotation can easily be detected (by the macro generation program), as well as missing definition (the compiler will define the expected macros to be undefined). Extracting the macros will happen by a scan over all or a limited set of elements, see later. The macros resulting from this REQUIRES_ANNO macro are: TYPE ANNO_NAME_GET(); void ANNO_NAME_SET(TYPE); We think that with type information there, it should not be hard to generate a struct or a map. sizeof is our friend :-) It is important to decide which elements to consider. Because, as you might notice, the standard way would be to generate annotations for all elements. In regular testing environments this is not really a problem, but it is not optimal. So we propose to only consider the elements from packages that are being used, this will already reduce the annotation map size. However, for setups that require maximal performance this is not enough. That is why we suggest to modify click_mkmindriver to be able to output elements required in the script. This output could be used to extract used REQUIRES_ANNO macros. So we can generate a minimal annotation_preferences file, resulting in the perfect balance. It is not always smart to allocate an entire map struct when allocating a packet. That is why a user should be able to specify something like --enable-late_annotation_allocation Then, the map struct is not allocated upon packet construction. The ANNO_NAME_GET macro will now contain an extra check on the map pointer being valid. The ANNO_NAME_SET macro will contain map allocation logic. A rather tricky difficulty is the type being passed to the REQUIRES_ANNO macro: what if this is a pointer or a char[]. We propose to scan for either * or [] in the macro arguments and be smart: - if you see a pointer, add new Pointer to the packet constructor and delete Pointer to the packet destructor (yes this implies we claim pointer ownership) - if you see char[], generate an error, it is not possible to allocate this - if you see char[i], generate malloc and free code to handle this case This is the result of 1 hour of brainstorming at lunch, so this could well contain some logical errors. You comments are of course welcome. best regards, Bart and Kurt -- Bart Braem PATS research group - IBBT Dept. of Mathematics and Computer Sciences University of Antwerp Campus Middelheim, G3.27 Middelheimlaan 1 B-2020 Antwerpen, Belgium Phone: +32 (0)3 265.38.82 Fax: +32 (0)3 265.37.77 Web: www.pats.ua.ac.be From bart.braem at ua.ac.be Thu Nov 26 10:31:33 2009 From: bart.braem at ua.ac.be (Bart Braem) Date: Thu, 26 Nov 2009 16:31:33 +0100 Subject: [Click] Mac OS X assert failed when trying to use KernelTun In-Reply-To: References: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> <4B0D0512.3010706@cs.ucla.edu> Message-ID: <4EE028B1-E3EF-4DB3-8188-EEF1B2161C7F@ua.ac.be> On 26 Nov 2009, at 11:57, Pekka Nikander wrote: > 1. It didn't compile out of last night's git; the following patch made it to compile: > > --- a/lib/timestamp.cc > +++ b/lib/timestamp.cc > @@ -67,7 +67,7 @@ Timestamp::warp(bool from_now) > if (_warp_class == warp_simulation) { > *this = _warp_flat_offset; > if (from_now) { > -# if TIMESTAMP_MATH_FLAT64 > +# if TIMESTAMP_REP_FLAT64 || TIMESTAMP_MATH_FLAT64 > ++_warp_flat_offset._t.x; > # else > ++_warp_flat_offset._t.subsec; > > I'm not sure if that is the right patch, though... I am experiencing the same bug on the same platform, luckily the same patch fixes it. Regards, Bart Braem -- Bart Braem PATS research group - IBBT Dept. of Mathematics and Computer Sciences University of Antwerp Campus Middelheim, G3.27 Middelheimlaan 1 B-2020 Antwerpen, Belgium Phone: +32 (0)3 265.38.82 Fax: +32 (0)3 265.37.77 Web: www.pats.ua.ac.be From kohler at cs.ucla.edu Thu Nov 26 13:17:13 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 26 Nov 2009 10:17:13 -0800 Subject: [Click] linuxpatchless In-Reply-To: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> References: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> Message-ID: <4B0EC629.1060303@cs.ucla.edu> Hello all, Harald Schi?berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Eddie started to pick up on his patch-making perl magic and tries to > write some magic to automatically mangle those into C++ compliance > independently from the kernel version used. This is now done. On current git, if you configure with --enable-fixincludes, Click will automatically fix Linux's headers for C++ compatibility -- at least on my 2.6.27 Ubuntu laptop, it succeeds, though I'm sure every now and then a new version will require an update to the scripts. I have successfully run conf/test.click on an unpatched kernel! Neat. FWIW on linuxpatchless, at least FromDevice, ToDevice, ToHost, and FromHost will need closer attention. (Not just From and ToDevice.) Thanks to you and to our most excellent Syclick hosts! Eddie > > For documentation: > Everthing should be simple almost regular expressions, like the notorious > - - asm ( foo :: bar ) > + asm ( foo : : bar ) > One notable exception: > the current click patch changes > - - struct foo {} > + EMPTY_STRUCT_DECL(foo) > The EMPTY_STRUCT_DECL is one byte long, because empty structs are one > byte in C++ but zero bytes in C. so this actually changes linux's > internal structures. The prosed solution it to redefine that into a > char[0] with is also zero bytes in C++, so we can still interface with > the now unpatched structures of the kernel. > > On the functional patches: > We will try to exchange anything in the linuxpatchless directory that > accesses one of click's hooks into something that uses a similar linux > hook instead. Probably only the FromDevice and ToDevice Elements will > have to be updated. > The theory converged on registering click with dev_add_pack() and then > overwriting skb->protocol in the received sk_buffs to prevent other's > from handling the packet as well... > Whoever feels more practical: post your patches ;-) > > That's all I remember on that part, a BIG THANK YOU again to the > organizers of syclick who made all that possible in the first place. > > - -- > 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 > > iD8DBQFLDY1ay8wrZ9OvkU0RAniwAJ9slIU/lUypJovGmTYIfMKW5G5hXwCfWCi0 > ay61mfOJbRUcXRlXEeg9Xdc= > =Udn3 > -----END PGP SIGNATURE----- > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From kohler at cs.ucla.edu Thu Nov 26 13:36:20 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Thu, 26 Nov 2009 10:36:20 -0800 Subject: [Click] Mac OS X assert failed when trying to use KernelTun In-Reply-To: References: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> <4B0D0512.3010706@cs.ucla.edu> Message-ID: <4B0ECAA4.4080509@cs.ucla.edu> Thanks much for the patch! I've checked it in. Too bad about the high variability in tun semantics. I'd love to accept a documentation patch :) Eddie Pekka Nikander wrote: > Eddie, > > Thanks, it works! > > I needed to do two other small things to get it working: > > 1. It didn't compile out of last night's git; the following patch made it to compile: > > --- a/lib/timestamp.cc > +++ b/lib/timestamp.cc > @@ -67,7 +67,7 @@ Timestamp::warp(bool from_now) > if (_warp_class == warp_simulation) { > *this = _warp_flat_offset; > if (from_now) { > -# if TIMESTAMP_MATH_FLAT64 > +# if TIMESTAMP_REP_FLAT64 || TIMESTAMP_MATH_FLAT64 > ++_warp_flat_offset._t.x; > # else > ++_warp_flat_offset._t.subsec; > > I'm not sure if that is the right patch, though... > > > 2. Mac OS X tun devices are point-to-point links, requiring both a local and remote IP address. > > Right now click configures only the local one, resulting in an interface like the following: > > $ ifconfig tun0 > tun0: flags=8951 mtu 1500 > inet 192.168.15.1 --> 0.0.0.0 netmask 0xffffff00 > open (pid 63049) > > Once I added a remote address there with ifconfig, it started to work: > > # ifconfig tun0 192.168.15.1 192.168.16.1 > # click -e "tun :: KernelTun(192.168.15.1/24); tun -> IPPrint -> Discard" & > # ping 192.168.16.1 > /dev/null 2>&1 > 1259231868.596160: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 0) > 1259231869.596198: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 256) > 1259231870.596240: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 512) > 1259231871.596328: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 768) > 1259231872.596394: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1024) > 1259231873.596553: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1280) > > Alternatively, I was also able to do the same by manipulating the routing table: > # route add -net 192.168.16.0 192.168.15.1 > > However, pinging anything on the local subnet 192.168.15.0/24 doesn't go to the click process. > > I guess the documentation should be updated... > > > Anyway, this should be enough slay some GMPLS Dragons locally on Mac OS X. :-) > > --Pekka > > On 2009-11 -25, at 12:21 , Eddie Kohler wrote: > >> Pekka, >> >> Thans very much for this note! There was indeed a bug in the select handling -- we essentially assumed that every file descriptor was present in some array for both reading and writing. This should be fixed now. Let us know if you have any further issues. >> >> Eddie >> >> >> Pekka Nikander wrote: >>> I'm a relative newbie to Click, and trying to use KernelTun on Mac OS X, with the latest GIT version. Unfortunately it looks like that there is a bug, apparently related to the interactions between kevents and select/poll. The OS X tun/tap devices don't currently support kevents, and therefore click tries to back off to use select/poll. However, once it gets to the actual poll in master.cc, something has gone wrong and I get a an assertion failure on line 850 in master.cc: >>> Element *read_elt = (p->revents & ~POLLOUT ? _read_elements[fd] : 0); >>> This results in an assertion failure, with this trivial script: >>> click -e "KernelTun(192.168.15.1/24) -> Discard" >>> Assertion failed: (i>=0 && i<_n), function operator[], file ../include/click/vector.hh, line 184. >>> Abort trap >>> My gut feeling is that the bug may line somewhere in master.cc Master:add_select, in the code that tries to make sure that one can fall back to select/poll in the case of kqueue error. But I may be wrong. >>> In any case, when tracing the execution in opening the tun/tap device, the kevent system call at line 602 of master.cc fails, causing the _kqueue socket to be closed and made unused. However, much before that I can see with ifconfig that the tun/tap interface is indeed open and correctly ifconfig'ed. >>> Anyone an idea where to continue debugging? Or would it be easier to add KEVENT support to the Mac tun/tap kexts? >>> --Pekka Nikander >>> _______________________________________________ >>> click mailing list >>> click at amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > From joonwpark81 at gmail.com Thu Nov 26 14:12:36 2009 From: joonwpark81 at gmail.com (Joonwoo Park) Date: Thu, 26 Nov 2009 11:12:36 -0800 Subject: [Click] linuxpatchless In-Reply-To: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> References: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> Message-ID: Hi forks. 2009/11/25 Harald Schi?berg : > - - a small functional patch which adds click's hooks to grab packets from > the kernel and to add the polling driver for intel e1000 cards > I think we could do this with netfilter hooks for someone who doesn't use polling, so we can avoid kernel patches completely. Joonwoo From joonwpark81 at gmail.com Thu Nov 26 14:14:36 2009 From: joonwpark81 at gmail.com (Joonwoo Park) Date: Thu, 26 Nov 2009 11:14:36 -0800 Subject: [Click] linuxpatchless In-Reply-To: References: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> Message-ID: On Thu, Nov 26, 2009 at 11:12 AM, Joonwoo Park wrote: > Hi forks. Shoot :( :( :( I meant folks. Joonwoo From jetever at gmail.com Thu Nov 26 21:58:51 2009 From: jetever at gmail.com (Yongheng Qi) Date: Fri, 27 Nov 2009 10:58:51 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <4B0C9A6B.3090308@cs.ucsb.edu> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> Message-ID: <3958ac680911261858k9b1baf9w4795a428ce462db5@mail.gmail.com> I try to every ways want to improve the click optimize. but nothing effict. have I need to use fast classifier? but I don't know how to use it at embedded environment. I compile at my pc and handle install click.ko to my broadband. 2009/11/25 Roman Chertov > When you run your original config on the gateway device, look at the > dmesg output. If there are queue drops in any of the queues, you will > notice that. If that is the case, you will have to modify your config. > For example, you can play with the BURST parameter. > > Yongheng Qi wrote: > > Thanks, Roman, > > > > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> Discard and > > FromDevice(br-lan) > > > > both can get the 100Mbps throuthput, it is my etherlink limit. > > > > > > > > 2009/11/25 Roman Chertov > > > > > > You can run Click on the receiver with the following config file. > > > > FromDevice(devX) -> ctr :: AverageCounter -> Discard; > > > > Then, you can look at the ctr stats to see what throughput you are > > getting at the receiver. > > > > Yongheng Qi wrote: > > > en, I am not sure, but I don't know how test the wireless > > throughout put. > > > > > > but the wireless card on ap sta mode can get the 140Mbps. the > monitor > > > mode is > > > > > > our optimized. so it can get the same throughout put as ap sta > mode. > > > > > > 2009/11/25 Roman Chertov > > > > >> > > > > > > Are you sure that your wireless link can transmit more than > > 90Mbps? I > > > would try to test the base performance of your source and > > > destination first. > > > > > > Roman > > > > > > Yongheng Qi wrote: > > > > Thanks, you advise is very importent for me. I think it not > > the TCP > > > > problem, because I test the UDP thoughout put. The same as > > TCP. Cliff > > > > say about kernel will memcpy every packet. Have the way > > solve the > > > > question? In the test, the kclick thread use more then 95% > > CPU. The > > > > eth0 driver use the opewrt include and the ath2 use the > > atheros sdk. > > > > These drivers may have problem? > > > > > > > > On 11/25/09, Roman Chertov > > > > >> > > wrote: > > > >> I failed to notice the config file... > > > >> > > > >> In addition to what Cliff said, you can try a simple test > > where you > > > >> configure Click as a transparent bridge to forward packets > > > between two > > > >> devices. Then, you can look at the counters to see where > > the packet > > > >> drops occur. > > > >> > > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > > > >> > > > >> If the counters for FromDevice, Queue, and ToDevice are the > > same, it > > > >> means that you are dropping packets at eth0 driver. You > > also need to > > > >> keep track of how many packets you sent from the source to > > help you > > > >> diagnose the issue. > > > >> > > > >> Roman > > > >> > > > >> Cliff Frey wrote: > > > >>> Your config looks reasonable to me. > > > >>> > > > >>> How are you measuring performance? I know if you are > running > > > TCP on the > > > >>> devices as well (if you are testing tcp-to-the-device > > rather than > > > >>> forwarding > > > >>> perfomance) that can slow things down (because of TCP > > > checksumming and > > > >>> because linux will keep a copy of every packet, causing > > there to > > > be a lot > > > >>> more memcpy overhead). > > > >>> > > > >>> Also, often the drivers contribute a lot of the slowdown, > even > > > though this > > > >>> is very hard to measure/see. > > > >>> > > > >>> It also seems as though you are using a br-lan device from > > > linux, perhaps > > > >>> the linux bridge code isn't very fast as well. > > > >>> > > > >>> You can benchmark click by loading the same config, but > > with an > > > >>> InfiniteSource instead of a FromHost or FromDevice, and a > > > Discard instead > > > >>> of > > > >>> a ToHost/ToDevice, and seeing what performance you get > there. > > > That can > > > >>> give > > > >>> you a benchmark for the maximum possible speeds that you > will > > > see with > > > >>> click. If that number is very high, then you need to be > > > optimizing your > > > >>> drivers or linux. If the number is low, then the problem > > > probably is in > > > >>> click. > > > >>> > > > >>> I know from experience that it is possible to forward more > > than > > > 140Mbps > > > >>> using kernel click with linux on a mips board in the > > 600-800 MHz > > > range. > > > >>> > > > >>> Cliff > > > >>> > > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > > > > > >> wrote: > > > >>> > > > >>>> Click performance is so poor. I only use 3 classifier and > 1 > > > iprewrite and > > > >>>> other general packet process elements. > > > >>>> > > > >>>> At 680Mhz MIPS CPU, click actually can't process over > 90Mbit > > > data per > > > >>>> second. > > > >>>> > > > >>>> The attachment is the click config file. anyone can tell > > me how to > > > >>>> optimize > > > >>>> it. > > > >>>> > > > >>>> Thanks very much > > > >>>> > > > >>>> > > > >>>> 2009/11/20 Yongheng Qi > > > > >> > > > >>>> > > > >>>>> Dear everyone. > > > >>>>> > > > >>>>> I use click roofnet process the 802.11n packet. test it > use > > > IxChariot. > > > >>>> find > > > >>>>> about 90Mbps, click use 100% cpu. > > > >>>>> > > > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > > >>>>> > > > >>>>> I don't know how to make click have more eiffciency. > > > >>>>> > > > >>>>> please help me, Thanks very much. > > > >>>>> > > > >>>>> -- > > > >>>>> Yongheng Qi > > > >>>>> > > > >>>>> Mobile: +86 1390 119 7481 > > > >>>>> > > > >>>> > > > >>>> -- > > > >>>> Yongheng Qi > > > >>>> > > > >>>> Mobile: +86 1390 119 7481 > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > >>> > > > >> > > > > > > > > > > > > > > > > > > > -- > > > Yongheng Qi > > > > > > Mobile: +86 1390 119 7481 > > > > > > > > > > -- > > Yongheng Qi > > > > Mobile: +86 1390 119 7481 > > -- Yongheng Qi Mobile: +86 1390 119 7481 From jetever at gmail.com Fri Nov 27 04:36:12 2009 From: jetever at gmail.com (Yongheng Qi) Date: Fri, 27 Nov 2009 17:36:12 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911261858k9b1baf9w4795a428ce462db5@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911261858k9b1baf9w4795a428ce462db5@mail.gmail.com> Message-ID: <3958ac680911270136v3204586ekb4e7b6cfac34e2e7@mail.gmail.com> Dear everyone. I find click could use Polling extensions, the polling device can use on madwifi or other wireless drivers? Thanks 2009/11/27 Yongheng Qi > I try to every ways want to improve the click optimize. but nothing effict. > > have I need to use fast classifier? but I don't know how to use it at > embedded environment. > > I compile at my pc and handle install click.ko to my broadband. > > > 2009/11/25 Roman Chertov > >> When you run your original config on the gateway device, look at the >> dmesg output. If there are queue drops in any of the queues, you will >> notice that. If that is the case, you will have to modify your config. >> For example, you can play with the BURST parameter. >> >> Yongheng Qi wrote: >> > Thanks, Roman, >> > >> > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> Discard and >> > FromDevice(br-lan) >> > >> > both can get the 100Mbps throuthput, it is my etherlink limit. >> > >> > >> > >> > 2009/11/25 Roman Chertov > > > >> > >> > You can run Click on the receiver with the following config file. >> > >> > FromDevice(devX) -> ctr :: AverageCounter -> Discard; >> > >> > Then, you can look at the ctr stats to see what throughput you are >> > getting at the receiver. >> > >> > Yongheng Qi wrote: >> > > en, I am not sure, but I don't know how test the wireless >> > throughout put. >> > > >> > > but the wireless card on ap sta mode can get the 140Mbps. the >> monitor >> > > mode is >> > > >> > > our optimized. so it can get the same throughout put as ap sta >> mode. >> > > >> > > 2009/11/25 Roman Chertov > > >> > > >> >> > > >> > > Are you sure that your wireless link can transmit more than >> > 90Mbps? I >> > > would try to test the base performance of your source and >> > > destination first. >> > > >> > > Roman >> > > >> > > Yongheng Qi wrote: >> > > > Thanks, you advise is very importent for me. I think it not >> > the TCP >> > > > problem, because I test the UDP thoughout put. The same as >> > TCP. Cliff >> > > > say about kernel will memcpy every packet. Have the way >> > solve the >> > > > question? In the test, the kclick thread use more then 95% >> > CPU. The >> > > > eth0 driver use the opewrt include and the ath2 use the >> > atheros sdk. >> > > > These drivers may have problem? >> > > > >> > > > On 11/25/09, Roman Chertov > > >> > > >> >> > wrote: >> > > >> I failed to notice the config file... >> > > >> >> > > >> In addition to what Cliff said, you can try a simple test >> > where you >> > > >> configure Click as a transparent bridge to forward packets >> > > between two >> > > >> devices. Then, you can look at the counters to see where >> > the packet >> > > >> drops occur. >> > > >> >> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); >> > > >> >> > > >> If the counters for FromDevice, Queue, and ToDevice are the >> > same, it >> > > >> means that you are dropping packets at eth0 driver. You >> > also need to >> > > >> keep track of how many packets you sent from the source to >> > help you >> > > >> diagnose the issue. >> > > >> >> > > >> Roman >> > > >> >> > > >> Cliff Frey wrote: >> > > >>> Your config looks reasonable to me. >> > > >>> >> > > >>> How are you measuring performance? I know if you are >> running >> > > TCP on the >> > > >>> devices as well (if you are testing tcp-to-the-device >> > rather than >> > > >>> forwarding >> > > >>> perfomance) that can slow things down (because of TCP >> > > checksumming and >> > > >>> because linux will keep a copy of every packet, causing >> > there to >> > > be a lot >> > > >>> more memcpy overhead). >> > > >>> >> > > >>> Also, often the drivers contribute a lot of the slowdown, >> even >> > > though this >> > > >>> is very hard to measure/see. >> > > >>> >> > > >>> It also seems as though you are using a br-lan device from >> > > linux, perhaps >> > > >>> the linux bridge code isn't very fast as well. >> > > >>> >> > > >>> You can benchmark click by loading the same config, but >> > with an >> > > >>> InfiniteSource instead of a FromHost or FromDevice, and a >> > > Discard instead >> > > >>> of >> > > >>> a ToHost/ToDevice, and seeing what performance you get >> there. >> > > That can >> > > >>> give >> > > >>> you a benchmark for the maximum possible speeds that you >> will >> > > see with >> > > >>> click. If that number is very high, then you need to be >> > > optimizing your >> > > >>> drivers or linux. If the number is low, then the problem >> > > probably is in >> > > >>> click. >> > > >>> >> > > >>> I know from experience that it is possible to forward more >> > than >> > > 140Mbps >> > > >>> using kernel click with linux on a mips board in the >> > 600-800 MHz >> > > range. >> > > >>> >> > > >>> Cliff >> > > >>> >> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi >> > >> > > >> wrote: >> > > >>> >> > > >>>> Click performance is so poor. I only use 3 classifier and >> 1 >> > > iprewrite and >> > > >>>> other general packet process elements. >> > > >>>> >> > > >>>> At 680Mhz MIPS CPU, click actually can't process over >> 90Mbit >> > > data per >> > > >>>> second. >> > > >>>> >> > > >>>> The attachment is the click config file. anyone can tell >> > me how to >> > > >>>> optimize >> > > >>>> it. >> > > >>>> >> > > >>>> Thanks very much >> > > >>>> >> > > >>>> >> > > >>>> 2009/11/20 Yongheng Qi > > >> > > >> >> > > >>>> >> > > >>>>> Dear everyone. >> > > >>>>> >> > > >>>>> I use click roofnet process the 802.11n packet. test it >> use >> > > IxChariot. >> > > >>>> find >> > > >>>>> about 90Mbps, click use 100% cpu. >> > > >>>>> >> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. >> > > >>>>> >> > > >>>>> I don't know how to make click have more eiffciency. >> > > >>>>> >> > > >>>>> please help me, Thanks very much. >> > > >>>>> >> > > >>>>> -- >> > > >>>>> Yongheng Qi >> > > >>>>> >> > > >>>>> Mobile: +86 1390 119 7481 >> > > >>>>> >> > > >>>> >> > > >>>> -- >> > > >>>> Yongheng Qi >> > > >>>> >> > > >>>> Mobile: +86 1390 119 7481 >> > > >>>> >> > > >>>> _______________________________________________ >> > > >>>> 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 >> > > >>> >> > > >> >> > > > >> > > >> > > >> > > >> > > >> > > -- >> > > Yongheng Qi >> > > >> > > Mobile: +86 1390 119 7481 >> > >> > >> > >> > >> > -- >> > Yongheng Qi >> > >> > Mobile: +86 1390 119 7481 >> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > -- Yongheng Qi Mobile: +86 1390 119 7481 From pekka.nikander at nomadiclab.com Fri Nov 27 07:37:20 2009 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 27 Nov 2009 14:37:20 +0200 Subject: [Click] Mac OS X assert failed when trying to use KernelTun In-Reply-To: <4B0ECAA4.4080509@cs.ucla.edu> References: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> <4B0D0512.3010706@cs.ucla.edu> <4B0ECAA4.4080509@cs.ucla.edu> Message-ID: <5FED7239-3DBA-47D3-8D0B-D14B640EDF9A@nomadiclab.com> I figured out a way to configure the device so that the user visible semantics are almost the same on OSX as on Linux: On OSX, convert a "Linux" KernelTun(192.168.15.1/24) into a combination of 1. "KernelTun(192.168.15.1/24)" and 2. route add 192.168.15.0/24 192.168.15.1 That results in all packets to 192.168.15.0/24 to be sent over the tun to click (including 192.168.15.1). Hence, if the code always used a /32 internally and used the given netmask for adding a net route, the semantics would almost match with the Linux one, with the exception that the host stack doesn't answer even to the local address. I'm looking at the source code now to see if that can be reasonably implemented and documented. --Pekka On 2009-11 -26, at 20:36 , Eddie Kohler wrote: > Thanks much for the patch! I've checked it in. > > Too bad about the high variability in tun semantics. I'd love to accept a documentation patch :) > > Eddie > > > Pekka Nikander wrote: >> Eddie, >> Thanks, it works! I needed to do two other small things to get it working: >> 1. It didn't compile out of last night's git; the following patch made it to compile: >> --- a/lib/timestamp.cc >> +++ b/lib/timestamp.cc >> @@ -67,7 +67,7 @@ Timestamp::warp(bool from_now) >> if (_warp_class == warp_simulation) { >> *this = _warp_flat_offset; >> if (from_now) { >> -# if TIMESTAMP_MATH_FLAT64 >> +# if TIMESTAMP_REP_FLAT64 || TIMESTAMP_MATH_FLAT64 >> ++_warp_flat_offset._t.x; >> # else >> ++_warp_flat_offset._t.subsec; >> I'm not sure if that is the right patch, though... >> 2. Mac OS X tun devices are point-to-point links, requiring both a local and remote IP address. >> Right now click configures only the local one, resulting in an interface like the following: >> $ ifconfig tun0 >> tun0: flags=8951 mtu 1500 >> inet 192.168.15.1 --> 0.0.0.0 netmask 0xffffff00 open (pid 63049) >> Once I added a remote address there with ifconfig, it started to work: >> # ifconfig tun0 192.168.15.1 192.168.16.1 >> # click -e "tun :: KernelTun(192.168.15.1/24); tun -> IPPrint -> Discard" & >> # ping 192.168.16.1 > /dev/null 2>&1 >> 1259231868.596160: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 0) >> 1259231869.596198: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 256) >> 1259231870.596240: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 512) >> 1259231871.596328: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 768) >> 1259231872.596394: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1024) >> 1259231873.596553: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1280) >> Alternatively, I was also able to do the same by manipulating the routing table: >> # route add -net 192.168.16.0 192.168.15.1 >> However, pinging anything on the local subnet 192.168.15.0/24 doesn't go to the click process. >> I guess the documentation should be updated... >> Anyway, this should be enough slay some GMPLS Dragons locally on Mac OS X. :-) >> --Pekka >> On 2009-11 -25, at 12:21 , Eddie Kohler wrote: >>> Pekka, >>> >>> Thans very much for this note! There was indeed a bug in the select handling -- we essentially assumed that every file descriptor was present in some array for both reading and writing. This should be fixed now. Let us know if you have any further issues. >>> >>> Eddie >>> >>> >>> Pekka Nikander wrote: >>>> I'm a relative newbie to Click, and trying to use KernelTun on Mac OS X, with the latest GIT version. Unfortunately it looks like that there is a bug, apparently related to the interactions between kevents and select/poll. The OS X tun/tap devices don't currently support kevents, and therefore click tries to back off to use select/poll. However, once it gets to the actual poll in master.cc, something has gone wrong and I get a an assertion failure on line 850 in master.cc: >>>> Element *read_elt = (p->revents & ~POLLOUT ? _read_elements[fd] : 0); >>>> This results in an assertion failure, with this trivial script: >>>> click -e "KernelTun(192.168.15.1/24) -> Discard" >>>> Assertion failed: (i>=0 && i<_n), function operator[], file ../include/click/vector.hh, line 184. >>>> Abort trap >>>> My gut feeling is that the bug may line somewhere in master.cc Master:add_select, in the code that tries to make sure that one can fall back to select/poll in the case of kqueue error. But I may be wrong. >>>> In any case, when tracing the execution in opening the tun/tap device, the kevent system call at line 602 of master.cc fails, causing the _kqueue socket to be closed and made unused. However, much before that I can see with ifconfig that the tun/tap interface is indeed open and correctly ifconfig'ed. >>>> Anyone an idea where to continue debugging? Or would it be easier to add KEVENT support to the Mac tun/tap kexts? >>>> --Pekka Nikander >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From pekka.nikander at nomadiclab.com Fri Nov 27 08:51:19 2009 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 27 Nov 2009 15:51:19 +0200 Subject: [Click] Mac OS X assert failed when trying to use KernelTun In-Reply-To: <4B0ECAA4.4080509@cs.ucla.edu> References: <4E605F96-3282-466D-8B33-EB38DF315298@nomadiclab.com> <4B0D0512.3010706@cs.ucla.edu> <4B0ECAA4.4080509@cs.ucla.edu> Message-ID: <87AC9AFC-74BE-49F5-BDC6-E532AF3E8D8D@nomadiclab.com> Eddie, This a patch that implements the route adding on Mac OS X, and explains the small difference in the document. Minimally tested and seems to work. --Pekka diff --git a/elements/userlevel/kerneltun.cc b/elements/userlevel/kerneltun.cc index ca59225..abe95ac 100644 --- a/elements/userlevel/kerneltun.cc +++ b/elements/userlevel/kerneltun.cc @@ -40,6 +40,7 @@ # define KERNELTUN_OSX 1 // assume tun driver installed from http://chrisp.de/en/projects/tunnel.html // this driver doesn't produce or expect packets with an address family prepended +#include #endif #if defined(HAVE_NET_IF_TAP_H) # define KERNELTAP_NET 1 @@ -302,6 +303,50 @@ KernelTun::updown(IPAddress addr, IPAddress mask, ErrorHandler *errh) #else # error "Lacking SIOCSIFADDR and/or SIOCSIFNETMASK" #endif +#if defined(KERNELTUN_OSX) + // On OSX, we have to explicitly add a route, too + { + static int seq = 0; + struct { + struct rt_msghdr msghdr; + struct sockaddr_in sin[3]; // Destination, gateway, netmask, + } msg; + + memset(&msg, 0, sizeof(msg)); + msg.msghdr.rtm_msglen = sizeof(msg); + msg.msghdr.rtm_version = RTM_VERSION; + msg.msghdr.rtm_type = RTM_ADD; + msg.msghdr.rtm_index = 0; + msg.msghdr.rtm_pid = 0; + msg.msghdr.rtm_addrs = RTA_DST | RTA_GATEWAY | RTA_NETMASK; + msg.msghdr.rtm_seq = ++seq; + msg.msghdr.rtm_errno = 0; + msg.msghdr.rtm_flags = RTF_UP | RTF_GATEWAY; + + for (unsigned int i = 0; i < sizeof(msg.sin) / sizeof(msg.sin[0]); i++) { + msg.sin[i].sin_len = sizeof(msg.sin[0]); + msg.sin[i].sin_family = AF_INET; + } + + msg.sin[0].sin_addr = addr & mask; // Destination + msg.sin[1].sin_addr = addr; // Gateway + msg.sin[2].sin_addr = mask; // Netmask + + int s = socket(PF_ROUTE, SOCK_RAW, AF_INET); + if (s < 0) { + errh->warning("Opening a PF_ROUTE socket failed: %s", strerror(errno)); + goto out; + } + int r = write(s, (char *)&msg, sizeof(msg)); + if (r < 0) { + errh->warning("Writing to the PF_ROUTE socket failed: %s", strerror(errno)); + } + r = close(s); + if (r < 0) { + errh->warning("Closing the PF_ROUTE socket failed: %s", strerror(errno)); + } + } +#endif #if defined(SIOCSIFHWADDR) if (_macaddr) { ifr.ifr.ifr_hwaddr.sa_family = ARPHRD_ETHER; diff --git a/elements/userlevel/kerneltun.hh b/elements/userlevel/kerneltun.hh index 88cdf87..540dffe 100644 --- a/elements/userlevel/kerneltun.hh +++ b/elements/userlevel/kerneltun.hh @@ -79,17 +79,19 @@ directory" may indicate that your kernel isn't set up, or that some required kernel module hasn't been loaded (on Linux, the relevant module is "tun"). -Packets sent to ADDR will be processed by the host kernel stack; packets sent -to any other address in ADDR/MASK will be sent to KernelTun. Say you run this -configuration: +On Linux and most BSDs, packets sent to ADDR will be processed by the host +kernel stack; on Mac OS X there is no special handling for ADDR. +Packets sent to any (other) address in ADDR/MASK will be sent to KernelTun. +Say you run this configuration: tun :: KernelTun(1.0.0.1/8); tun -> IPClassifier(icmp type echo) -> ICMPPingResponder -> IPPrint -> tun; -If you then "C", I will respond. Click will -never see the packets, so it won't print anything. But if you "C", the pings are sent to Click. You should see printouts from Click, +If you then "C", on Linux and most BSDs I will respond. +On those systems, click will never see the packets, so it won't print anything; +on Mac OS X, Click will see even these packets. +If you "C", the pings are sent to Click. You should see printouts from Click, and C should print Click's responses. This element differs from KernelTap in that it produces and expects IP On 2009-11 -26, at 20:36 , Eddie Kohler wrote: > Thanks much for the patch! I've checked it in. > > Too bad about the high variability in tun semantics. I'd love to accept a documentation patch :) > > Eddie > > > Pekka Nikander wrote: >> Eddie, >> Thanks, it works! I needed to do two other small things to get it working: >> 1. It didn't compile out of last night's git; the following patch made it to compile: >> --- a/lib/timestamp.cc >> +++ b/lib/timestamp.cc >> @@ -67,7 +67,7 @@ Timestamp::warp(bool from_now) >> if (_warp_class == warp_simulation) { >> *this = _warp_flat_offset; >> if (from_now) { >> -# if TIMESTAMP_MATH_FLAT64 >> +# if TIMESTAMP_REP_FLAT64 || TIMESTAMP_MATH_FLAT64 >> ++_warp_flat_offset._t.x; >> # else >> ++_warp_flat_offset._t.subsec; >> I'm not sure if that is the right patch, though... >> 2. Mac OS X tun devices are point-to-point links, requiring both a local and remote IP address. >> Right now click configures only the local one, resulting in an interface like the following: >> $ ifconfig tun0 >> tun0: flags=8951 mtu 1500 >> inet 192.168.15.1 --> 0.0.0.0 netmask 0xffffff00 open (pid 63049) >> Once I added a remote address there with ifconfig, it started to work: >> # ifconfig tun0 192.168.15.1 192.168.16.1 >> # click -e "tun :: KernelTun(192.168.15.1/24); tun -> IPPrint -> Discard" & >> # ping 192.168.16.1 > /dev/null 2>&1 >> 1259231868.596160: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 0) >> 1259231869.596198: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 256) >> 1259231870.596240: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 512) >> 1259231871.596328: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 768) >> 1259231872.596394: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1024) >> 1259231873.596553: 192.168.15.1 > 192.168.16.1: icmp echo (63066, 1280) >> Alternatively, I was also able to do the same by manipulating the routing table: >> # route add -net 192.168.16.0 192.168.15.1 >> However, pinging anything on the local subnet 192.168.15.0/24 doesn't go to the click process. >> I guess the documentation should be updated... >> Anyway, this should be enough slay some GMPLS Dragons locally on Mac OS X. :-) >> --Pekka >> On 2009-11 -25, at 12:21 , Eddie Kohler wrote: >>> Pekka, >>> >>> Thans very much for this note! There was indeed a bug in the select handling -- we essentially assumed that every file descriptor was present in some array for both reading and writing. This should be fixed now. Let us know if you have any further issues. >>> >>> Eddie >>> >>> >>> Pekka Nikander wrote: >>>> I'm a relative newbie to Click, and trying to use KernelTun on Mac OS X, with the latest GIT version. Unfortunately it looks like that there is a bug, apparently related to the interactions between kevents and select/poll. The OS X tun/tap devices don't currently support kevents, and therefore click tries to back off to use select/poll. However, once it gets to the actual poll in master.cc, something has gone wrong and I get a an assertion failure on line 850 in master.cc: >>>> Element *read_elt = (p->revents & ~POLLOUT ? _read_elements[fd] : 0); >>>> This results in an assertion failure, with this trivial script: >>>> click -e "KernelTun(192.168.15.1/24) -> Discard" >>>> Assertion failed: (i>=0 && i<_n), function operator[], file ../include/click/vector.hh, line 184. >>>> Abort trap >>>> My gut feeling is that the bug may line somewhere in master.cc Master:add_select, in the code that tries to make sure that one can fall back to select/poll in the case of kqueue error. But I may be wrong. >>>> In any case, when tracing the execution in opening the tun/tap device, the kevent system call at line 602 of master.cc fails, causing the _kqueue socket to be closed and made unused. However, much before that I can see with ifconfig that the tun/tap interface is indeed open and correctly ifconfig'ed. >>>> Anyone an idea where to continue debugging? Or would it be easier to add KEVENT support to the Mac tun/tap kexts? >>>> --Pekka Nikander >>>> _______________________________________________ >>>> click mailing list >>>> click at amsterdam.lcs.mit.edu >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click From rchertov at cs.ucsb.edu Fri Nov 27 12:03:18 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Fri, 27 Nov 2009 09:03:18 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911240148x55c20197tabb26c15a9716226@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> Message-ID: <4B100656.5010402@cs.ucsb.edu> Yongheng Qi wrote: > By the way, when test the two routes use wireless, both them kclick > thread use more then 95% CPU load. > > I check all queue I am used, nothing be droped. This most likely means that you are dropping packets at the input interfaces as they are not drained fast enough. > > how to play with the BURST parameter? http://read.cs.ucla.edu/click/elements/fromdevice BURST allows to specify how many packets to dequeue at once. You can try increasing this value from its default (8). Roman > > Thanks > > 2009/11/25 Roman Chertov > > > When you run your original config on the gateway device, look at the > dmesg output. If there are queue drops in any of the queues, you will > notice that. If that is the case, you will have to modify your config. > For example, you can play with the BURST parameter. > > Yongheng Qi wrote: > > Thanks, Roman, > > > > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> > Discard and > > FromDevice(br-lan) > > > > both can get the 100Mbps throuthput, it is my etherlink limit. > > > > > > > > 2009/11/25 Roman Chertov > > >> > > > > You can run Click on the receiver with the following config file. > > > > FromDevice(devX) -> ctr :: AverageCounter -> Discard; > > > > Then, you can look at the ctr stats to see what throughput you are > > getting at the receiver. > > > > Yongheng Qi wrote: > > > en, I am not sure, but I don't know how test the wireless > > throughout put. > > > > > > but the wireless card on ap sta mode can get the 140Mbps. > the monitor > > > mode is > > > > > > our optimized. so it can get the same throughout put as ap > sta mode. > > > > > > 2009/11/25 Roman Chertov > > > > > > > >>> > > > > > > Are you sure that your wireless link can transmit more than > > 90Mbps? I > > > would try to test the base performance of your source and > > > destination first. > > > > > > Roman > > > > > > Yongheng Qi wrote: > > > > Thanks, you advise is very importent for me. I think > it not > > the TCP > > > > problem, because I test the UDP thoughout put. The same as > > TCP. Cliff > > > > say about kernel will memcpy every packet. Have the way > > solve the > > > > question? In the test, the kclick thread use more then 95% > > CPU. The > > > > eth0 driver use the opewrt include and the ath2 use the > > atheros sdk. > > > > These drivers may have problem? > > > > > > > > On 11/25/09, Roman Chertov > > > > > > >>> > > wrote: > > > >> I failed to notice the config file... > > > >> > > > >> In addition to what Cliff said, you can try a simple test > > where you > > > >> configure Click as a transparent bridge to forward > packets > > > between two > > > >> devices. Then, you can look at the counters to see where > > the packet > > > >> drops occur. > > > >> > > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > > > >> > > > >> If the counters for FromDevice, Queue, and ToDevice > are the > > same, it > > > >> means that you are dropping packets at eth0 driver. You > > also need to > > > >> keep track of how many packets you sent from the > source to > > help you > > > >> diagnose the issue. > > > >> > > > >> Roman > > > >> > > > >> Cliff Frey wrote: > > > >>> Your config looks reasonable to me. > > > >>> > > > >>> How are you measuring performance? I know if you > are running > > > TCP on the > > > >>> devices as well (if you are testing tcp-to-the-device > > rather than > > > >>> forwarding > > > >>> perfomance) that can slow things down (because of TCP > > > checksumming and > > > >>> because linux will keep a copy of every packet, causing > > there to > > > be a lot > > > >>> more memcpy overhead). > > > >>> > > > >>> Also, often the drivers contribute a lot of the > slowdown, even > > > though this > > > >>> is very hard to measure/see. > > > >>> > > > >>> It also seems as though you are using a br-lan > device from > > > linux, perhaps > > > >>> the linux bridge code isn't very fast as well. > > > >>> > > > >>> You can benchmark click by loading the same config, but > > with an > > > >>> InfiniteSource instead of a FromHost or FromDevice, > and a > > > Discard instead > > > >>> of > > > >>> a ToHost/ToDevice, and seeing what performance you > get there. > > > That can > > > >>> give > > > >>> you a benchmark for the maximum possible speeds that > you will > > > see with > > > >>> click. If that number is very high, then you need to be > > > optimizing your > > > >>> drivers or linux. If the number is low, then the > problem > > > probably is in > > > >>> click. > > > >>> > > > >>> I know from experience that it is possible to > forward more > > than > > > 140Mbps > > > >>> using kernel click with linux on a mips board in the > > 600-800 MHz > > > range. > > > >>> > > > >>> Cliff > > > >>> > > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > > > > > > > > >>> wrote: > > > >>> > > > >>>> Click performance is so poor. I only use 3 > classifier and 1 > > > iprewrite and > > > >>>> other general packet process elements. > > > >>>> > > > >>>> At 680Mhz MIPS CPU, click actually can't process > over 90Mbit > > > data per > > > >>>> second. > > > >>>> > > > >>>> The attachment is the click config file. anyone can > tell > > me how to > > > >>>> optimize > > > >>>> it. > > > >>>> > > > >>>> Thanks very much > > > >>>> > > > >>>> > > > >>>> 2009/11/20 Yongheng Qi > > > > > > > >>> > > > >>>> > > > >>>>> Dear everyone. > > > >>>>> > > > >>>>> I use click roofnet process the 802.11n packet. > test it use > > > IxChariot. > > > >>>> find > > > >>>>> about 90Mbps, click use 100% cpu. > > > >>>>> > > > >>>>> I use routeros 433AH boardband.the cpu is MIPS 680Mhz. > > > >>>>> > > > >>>>> I don't know how to make click have more eiffciency. > > > >>>>> > > > >>>>> please help me, Thanks very much. > > > >>>>> > > > >>>>> -- > > > >>>>> Yongheng Qi > > > >>>>> > > > >>>>> Mobile: +86 1390 119 7481 > > > >>>>> > > > >>>> > > > >>>> -- > > > >>>> Yongheng Qi > > > >>>> > > > >>>> Mobile: +86 1390 119 7481 > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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 > > > >>> > > > >> > > > > > > > > > > > > > > > > > > > -- > > > Yongheng Qi > > > > > > Mobile: +86 1390 119 7481 > > > > > > > > > > -- > > Yongheng Qi > > > > Mobile: +86 1390 119 7481 > > > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 From jetever at gmail.com Fri Nov 27 12:28:28 2009 From: jetever at gmail.com (Yongheng Qi) Date: Sat, 28 Nov 2009 01:28:28 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <4B100656.5010402@cs.ucsb.edu> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> Message-ID: <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> Thanks roman,I think my question is how to reduce the kclick cpu load, now when the thoughput get about 90Mbps kclick use 100% cpu. So I want to make kclick more quickly, and it will process more packets. How do you think? On 11/28/09, Roman Chertov wrote: > Yongheng Qi wrote: >> By the way, when test the two routes use wireless, both them kclick >> thread use more then 95% CPU load. >> >> I check all queue I am used, nothing be droped. > > This most likely means that you are dropping packets at the input > interfaces as they are not drained fast enough. > >> >> how to play with the BURST parameter? > > http://read.cs.ucla.edu/click/elements/fromdevice > > BURST allows to specify how many packets to dequeue at once. You can > try increasing this value from its default (8). > > Roman > >> >> Thanks >> >> 2009/11/25 Roman Chertov > > >> >> When you run your original config on the gateway device, look at the >> dmesg output. If there are queue drops in any of the queues, you will >> notice that. If that is the case, you will have to modify your >> config. >> For example, you can play with the BURST parameter. >> >> Yongheng Qi wrote: >> > Thanks, Roman, >> > >> > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> >> Discard and >> > FromDevice(br-lan) >> > >> > both can get the 100Mbps throuthput, it is my etherlink limit. >> > >> > >> > >> > 2009/11/25 Roman Chertov > >> > >> >> > >> > You can run Click on the receiver with the following config >> file. >> > >> > FromDevice(devX) -> ctr :: AverageCounter -> Discard; >> > >> > Then, you can look at the ctr stats to see what throughput you >> are >> > getting at the receiver. >> > >> > Yongheng Qi wrote: >> > > en, I am not sure, but I don't know how test the wireless >> > throughout put. >> > > >> > > but the wireless card on ap sta mode can get the 140Mbps. >> the monitor >> > > mode is >> > > >> > > our optimized. so it can get the same throughout put as ap >> sta mode. >> > > >> > > 2009/11/25 Roman Chertov > >> > > >> > > >> >>> >> > > >> > > Are you sure that your wireless link can transmit more >> than >> > 90Mbps? I >> > > would try to test the base performance of your source and >> > > destination first. >> > > >> > > Roman >> > > >> > > Yongheng Qi wrote: >> > > > Thanks, you advise is very importent for me. I think >> it not >> > the TCP >> > > > problem, because I test the UDP thoughout put. The same >> as >> > TCP. Cliff >> > > > say about kernel will memcpy every packet. Have the way >> > solve the >> > > > question? In the test, the kclick thread use more then >> 95% >> > CPU. The >> > > > eth0 driver use the opewrt include and the ath2 use the >> > atheros sdk. >> > > > These drivers may have problem? >> > > > >> > > > On 11/25/09, Roman Chertov > >> > > >> > > > > >>> >> > wrote: >> > > >> I failed to notice the config file... >> > > >> >> > > >> In addition to what Cliff said, you can try a simple >> test >> > where you >> > > >> configure Click as a transparent bridge to forward >> packets >> > > between two >> > > >> devices. Then, you can look at the counters to see >> where >> > the packet >> > > >> drops occur. >> > > >> >> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); >> > > >> >> > > >> If the counters for FromDevice, Queue, and ToDevice >> are the >> > same, it >> > > >> means that you are dropping packets at eth0 driver. >> You >> > also need to >> > > >> keep track of how many packets you sent from the >> source to >> > help you >> > > >> diagnose the issue. >> > > >> >> > > >> Roman >> > > >> >> > > >> Cliff Frey wrote: >> > > >>> Your config looks reasonable to me. >> > > >>> >> > > >>> How are you measuring performance? I know if you >> are running >> > > TCP on the >> > > >>> devices as well (if you are testing tcp-to-the-device >> > rather than >> > > >>> forwarding >> > > >>> perfomance) that can slow things down (because of TCP >> > > checksumming and >> > > >>> because linux will keep a copy of every packet, >> causing >> > there to >> > > be a lot >> > > >>> more memcpy overhead). >> > > >>> >> > > >>> Also, often the drivers contribute a lot of the >> slowdown, even >> > > though this >> > > >>> is very hard to measure/see. >> > > >>> >> > > >>> It also seems as though you are using a br-lan >> device from >> > > linux, perhaps >> > > >>> the linux bridge code isn't very fast as well. >> > > >>> >> > > >>> You can benchmark click by loading the same config, >> but >> > with an >> > > >>> InfiniteSource instead of a FromHost or FromDevice, >> and a >> > > Discard instead >> > > >>> of >> > > >>> a ToHost/ToDevice, and seeing what performance you >> get there. >> > > That can >> > > >>> give >> > > >>> you a benchmark for the maximum possible speeds that >> you will >> > > see with >> > > >>> click. If that number is very high, then you need to >> be >> > > optimizing your >> > > >>> drivers or linux. If the number is low, then the >> problem >> > > probably is in >> > > >>> click. >> > > >>> >> > > >>> I know from experience that it is possible to >> forward more >> > than >> > > 140Mbps >> > > >>> using kernel click with linux on a mips board in the >> > 600-800 MHz >> > > range. >> > > >>> >> > > >>> Cliff >> > > >>> >> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi >> > >> > >> > > >> >>> wrote: >> > > >>> >> > > >>>> Click performance is so poor. I only use 3 >> classifier and 1 >> > > iprewrite and >> > > >>>> other general packet process elements. >> > > >>>> >> > > >>>> At 680Mhz MIPS CPU, click actually can't process >> over 90Mbit >> > > data per >> > > >>>> second. >> > > >>>> >> > > >>>> The attachment is the click config file. anyone can >> tell >> > me how to >> > > >>>> optimize >> > > >>>> it. >> > > >>>> >> > > >>>> Thanks very much >> > > >>>> >> > > >>>> >> > > >>>> 2009/11/20 Yongheng Qi > >> > > >> > > >> >>> >> > > >>>> >> > > >>>>> Dear everyone. >> > > >>>>> >> > > >>>>> I use click roofnet process the 802.11n packet. >> test it use >> > > IxChariot. >> > > >>>> find >> > > >>>>> about 90Mbps, click use 100% cpu. >> > > >>>>> >> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS >> 680Mhz. >> > > >>>>> >> > > >>>>> I don't know how to make click have more eiffciency. >> > > >>>>> >> > > >>>>> please help me, Thanks very much. >> > > >>>>> >> > > >>>>> -- >> > > >>>>> Yongheng Qi >> > > >>>>> >> > > >>>>> Mobile: +86 1390 119 7481 >> > > >>>>> >> > > >>>> >> > > >>>> -- >> > > >>>> Yongheng Qi >> > > >>>> >> > > >>>> Mobile: +86 1390 119 7481 >> > > >>>> >> > > >>>> _______________________________________________ >> > > >>>> 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 >> > > >>> >> > > >> >> > > > >> > > >> > > >> > > >> > > >> > > -- >> > > Yongheng Qi >> > > >> > > Mobile: +86 1390 119 7481 >> > >> > >> > >> > >> > -- >> > Yongheng Qi >> > >> > Mobile: +86 1390 119 7481 >> >> >> >> >> -- >> Yongheng Qi >> >> Mobile: +86 1390 119 7481 > > -- Sent from my mobile device Yongheng Qi Mobile: +86 1390 119 7481 From rchertov at cs.ucsb.edu Fri Nov 27 12:53:19 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Fri, 27 Nov 2009 09:53:19 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <4B0C2A9E.9060108@cs.ucsb.edu> <3958ac680911241714n6d051088i84a18635bda3748c@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> Message-ID: <4B10120F.5050302@cs.ucsb.edu> Yongheng Qi wrote: > Thanks roman,I think my question is how to reduce the kclick cpu load, > now when the thoughput get about 90Mbps kclick use 100% cpu. So I want > to make kclick more quickly, and it will process more packets. I highly recommend that you read this http://pdos.csail.mit.edu/papers/click:tocs00/paper.pdf It explains how the elements interact with each other and how the packets are processed. This should give you some insights as to how you can reduce the load and speed up the processing by rearranging your click config. Also, search the mail archives about notifier queues. There was a discussion a while ago on how to reduce the CPU load when the packet load is not very high. Roman > > How do you think? > > On 11/28/09, Roman Chertov wrote: >> Yongheng Qi wrote: >>> By the way, when test the two routes use wireless, both them kclick >>> thread use more then 95% CPU load. >>> >>> I check all queue I am used, nothing be droped. >> This most likely means that you are dropping packets at the input >> interfaces as they are not drained fast enough. >> >>> how to play with the BURST parameter? >> http://read.cs.ucla.edu/click/elements/fromdevice >> >> BURST allows to specify how many packets to dequeue at once. You can >> try increasing this value from its default (8). >> >> Roman >> >>> Thanks >>> >>> 2009/11/25 Roman Chertov >> > >>> >>> When you run your original config on the gateway device, look at the >>> dmesg output. If there are queue drops in any of the queues, you will >>> notice that. If that is the case, you will have to modify your >>> config. >>> For example, you can play with the BURST parameter. >>> >>> Yongheng Qi wrote: >>> > Thanks, Roman, >>> > >>> > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> >>> Discard and >>> > FromDevice(br-lan) >>> > >>> > both can get the 100Mbps throuthput, it is my etherlink limit. >>> > >>> > >>> > >>> > 2009/11/25 Roman Chertov >> >>> > >> >>> > >>> > You can run Click on the receiver with the following config >>> file. >>> > >>> > FromDevice(devX) -> ctr :: AverageCounter -> Discard; >>> > >>> > Then, you can look at the ctr stats to see what throughput you >>> are >>> > getting at the receiver. >>> > >>> > Yongheng Qi wrote: >>> > > en, I am not sure, but I don't know how test the wireless >>> > throughout put. >>> > > >>> > > but the wireless card on ap sta mode can get the 140Mbps. >>> the monitor >>> > > mode is >>> > > >>> > > our optimized. so it can get the same throughout put as ap >>> sta mode. >>> > > >>> > > 2009/11/25 Roman Chertov >> >>> > > >>> > > >>> >>> >>> > > >>> > > Are you sure that your wireless link can transmit more >>> than >>> > 90Mbps? I >>> > > would try to test the base performance of your source and >>> > > destination first. >>> > > >>> > > Roman >>> > > >>> > > Yongheng Qi wrote: >>> > > > Thanks, you advise is very importent for me. I think >>> it not >>> > the TCP >>> > > > problem, because I test the UDP thoughout put. The same >>> as >>> > TCP. Cliff >>> > > > say about kernel will memcpy every packet. Have the way >>> > solve the >>> > > > question? In the test, the kclick thread use more then >>> 95% >>> > CPU. The >>> > > > eth0 driver use the opewrt include and the ath2 use the >>> > atheros sdk. >>> > > > These drivers may have problem? >>> > > > >>> > > > On 11/25/09, Roman Chertov >> >>> > > >>> > > >> >> >>> >>> > wrote: >>> > > >> I failed to notice the config file... >>> > > >> >>> > > >> In addition to what Cliff said, you can try a simple >>> test >>> > where you >>> > > >> configure Click as a transparent bridge to forward >>> packets >>> > > between two >>> > > >> devices. Then, you can look at the counters to see >>> where >>> > the packet >>> > > >> drops occur. >>> > > >> >>> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); >>> > > >> >>> > > >> If the counters for FromDevice, Queue, and ToDevice >>> are the >>> > same, it >>> > > >> means that you are dropping packets at eth0 driver. >>> You >>> > also need to >>> > > >> keep track of how many packets you sent from the >>> source to >>> > help you >>> > > >> diagnose the issue. >>> > > >> >>> > > >> Roman >>> > > >> >>> > > >> Cliff Frey wrote: >>> > > >>> Your config looks reasonable to me. >>> > > >>> >>> > > >>> How are you measuring performance? I know if you >>> are running >>> > > TCP on the >>> > > >>> devices as well (if you are testing tcp-to-the-device >>> > rather than >>> > > >>> forwarding >>> > > >>> perfomance) that can slow things down (because of TCP >>> > > checksumming and >>> > > >>> because linux will keep a copy of every packet, >>> causing >>> > there to >>> > > be a lot >>> > > >>> more memcpy overhead). >>> > > >>> >>> > > >>> Also, often the drivers contribute a lot of the >>> slowdown, even >>> > > though this >>> > > >>> is very hard to measure/see. >>> > > >>> >>> > > >>> It also seems as though you are using a br-lan >>> device from >>> > > linux, perhaps >>> > > >>> the linux bridge code isn't very fast as well. >>> > > >>> >>> > > >>> You can benchmark click by loading the same config, >>> but >>> > with an >>> > > >>> InfiniteSource instead of a FromHost or FromDevice, >>> and a >>> > > Discard instead >>> > > >>> of >>> > > >>> a ToHost/ToDevice, and seeing what performance you >>> get there. >>> > > That can >>> > > >>> give >>> > > >>> you a benchmark for the maximum possible speeds that >>> you will >>> > > see with >>> > > >>> click. If that number is very high, then you need to >>> be >>> > > optimizing your >>> > > >>> drivers or linux. If the number is low, then the >>> problem >>> > > probably is in >>> > > >>> click. >>> > > >>> >>> > > >>> I know from experience that it is possible to >>> forward more >>> > than >>> > > 140Mbps >>> > > >>> using kernel click with linux on a mips board in the >>> > 600-800 MHz >>> > > range. >>> > > >>> >>> > > >>> Cliff >>> > > >>> >>> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi >>> > >>> > >>> > > >>> >>> wrote: >>> > > >>> >>> > > >>>> Click performance is so poor. I only use 3 >>> classifier and 1 >>> > > iprewrite and >>> > > >>>> other general packet process elements. >>> > > >>>> >>> > > >>>> At 680Mhz MIPS CPU, click actually can't process >>> over 90Mbit >>> > > data per >>> > > >>>> second. >>> > > >>>> >>> > > >>>> The attachment is the click config file. anyone can >>> tell >>> > me how to >>> > > >>>> optimize >>> > > >>>> it. >>> > > >>>> >>> > > >>>> Thanks very much >>> > > >>>> >>> > > >>>> >>> > > >>>> 2009/11/20 Yongheng Qi >> >>> > > >>> > > >>> >>> >>> > > >>>> >>> > > >>>>> Dear everyone. >>> > > >>>>> >>> > > >>>>> I use click roofnet process the 802.11n packet. >>> test it use >>> > > IxChariot. >>> > > >>>> find >>> > > >>>>> about 90Mbps, click use 100% cpu. >>> > > >>>>> >>> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS >>> 680Mhz. >>> > > >>>>> >>> > > >>>>> I don't know how to make click have more eiffciency. >>> > > >>>>> >>> > > >>>>> please help me, Thanks very much. >>> > > >>>>> >>> > > >>>>> -- >>> > > >>>>> Yongheng Qi >>> > > >>>>> >>> > > >>>>> Mobile: +86 1390 119 7481 >>> > > >>>>> >>> > > >>>> >>> > > >>>> -- >>> > > >>>> Yongheng Qi >>> > > >>>> >>> > > >>>> Mobile: +86 1390 119 7481 >>> > > >>>> >>> > > >>>> _______________________________________________ >>> > > >>>> 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 >>> > > >>> >>> > > >> >>> > > > >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > Yongheng Qi >>> > > >>> > > Mobile: +86 1390 119 7481 >>> > >>> > >>> > >>> > >>> > -- >>> > Yongheng Qi >>> > >>> > Mobile: +86 1390 119 7481 >>> >>> >>> >>> >>> -- >>> Yongheng Qi >>> >>> Mobile: +86 1390 119 7481 >> > From rchertov at cs.ucsb.edu Fri Nov 27 12:57:43 2009 From: rchertov at cs.ucsb.edu (Roman Chertov) Date: Fri, 27 Nov 2009 09:57:43 -0800 Subject: [Click] linuxpatchless In-Reply-To: <4B0EC629.1060303@cs.ucla.edu> References: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> <4B0EC629.1060303@cs.ucla.edu> Message-ID: <4B101317.90001@cs.ucsb.edu> This is a great development indeed! This should make Click much easier to use as quite a lot of people are intimidated by the fact that the kernel has to be patched and rebuilt. Roman Eddie Kohler wrote: > Hello all, > > Harald Schi?berg wrote: >> This is now done. On current git, if you configure with --enable-fixincludes, >> Click will automatically fix Linux's headers for C++ compatibility -- at least >> on my 2.6.27 Ubuntu laptop, it succeeds, though I'm sure every now and then a >> new version will require an update to the scripts. I have successfully run >> conf/test.click on an unpatched kernel! Neat. > >> FWIW on linuxpatchless, at least FromDevice, ToDevice, ToHost, and FromHost >> will need closer attention. (Not just From and ToDevice.) > >> Thanks to you and to our most excellent Syclick hosts! > >> Eddie > > > > For documentation: > Everthing should be simple almost regular expressions, like the notorious > - asm ( foo :: bar ) > + asm ( foo : : bar ) > One notable exception: > the current click patch changes > - struct foo {} > + EMPTY_STRUCT_DECL(foo) > The EMPTY_STRUCT_DECL is one byte long, because empty structs are one > byte in C++ but zero bytes in C. so this actually changes linux's > internal structures. The prosed solution it to redefine that into a > char[0] with is also zero bytes in C++, so we can still interface with > the now unpatched structures of the kernel. > > On the functional patches: > We will try to exchange anything in the linuxpatchless directory that > accesses one of click's hooks into something that uses a similar linux > hook instead. Probably only the FromDevice and ToDevice Elements will > have to be updated. > The theory converged on registering click with dev_add_pack() and then > overwriting skb->protocol in the received sk_buffs to prevent other's > from handling the packet as well... > Whoever feels more practical: post your patches ;-) > > That's all I remember on that part, a BIG THANK YOU again to the > organizers of syclick who made all that possible in the first place. > >> _______________________________________________ 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 jetever at gmail.com Fri Nov 27 13:00:19 2009 From: jetever at gmail.com (Yongheng Qi) Date: Sat, 28 Nov 2009 02:00:19 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <4B10120F.5050302@cs.ucsb.edu> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <4B0C89D4.9090604@cs.ucsb.edu> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> Message-ID: <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> Thanks very much, Roman. I will read the paper serious. and thanks your advise about notifier queues. now I only use the general Queue(). now it is the wee hours at my local time. I am at home. tomorrow I will go to my office. and If I get the new instance. I will mail to you. 2009/11/28 Roman Chertov > Yongheng Qi wrote: > > Thanks roman,I think my question is how to reduce the kclick cpu load, > > now when the thoughput get about 90Mbps kclick use 100% cpu. So I want > > to make kclick more quickly, and it will process more packets. > > I highly recommend that you read this > http://pdos.csail.mit.edu/papers/click:tocs00/paper.pdf It explains how > the elements interact with each other and how the packets are processed. > This should give you some insights as to how you can reduce the load > and speed up the processing by rearranging your click config. > > Also, search the mail archives about notifier queues. There was a > discussion a while ago on how to reduce the CPU load when the packet > load is not very high. > > Roman > > > > > How do you think? > > > > On 11/28/09, Roman Chertov wrote: > >> Yongheng Qi wrote: > >>> By the way, when test the two routes use wireless, both them kclick > >>> thread use more then 95% CPU load. > >>> > >>> I check all queue I am used, nothing be droped. > >> This most likely means that you are dropping packets at the input > >> interfaces as they are not drained fast enough. > >> > >>> how to play with the BURST parameter? > >> http://read.cs.ucla.edu/click/elements/fromdevice > >> > >> BURST allows to specify how many packets to dequeue at once. You can > >> try increasing this value from its default (8). > >> > >> Roman > >> > >>> Thanks > >>> > >>> 2009/11/25 Roman Chertov >>> > > >>> > >>> When you run your original config on the gateway device, look at > the > >>> dmesg output. If there are queue drops in any of the queues, you > will > >>> notice that. If that is the case, you will have to modify your > >>> config. > >>> For example, you can play with the BURST parameter. > >>> > >>> Yongheng Qi wrote: > >>> > Thanks, Roman, > >>> > > >>> > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> > >>> Discard and > >>> > FromDevice(br-lan) > >>> > > >>> > both can get the 100Mbps throuthput, it is my etherlink limit. > >>> > > >>> > > >>> > > >>> > 2009/11/25 Roman Chertov >>> > >>> > >> > >>> > > >>> > You can run Click on the receiver with the following config > >>> file. > >>> > > >>> > FromDevice(devX) -> ctr :: AverageCounter -> Discard; > >>> > > >>> > Then, you can look at the ctr stats to see what throughput > you > >>> are > >>> > getting at the receiver. > >>> > > >>> > Yongheng Qi wrote: > >>> > > en, I am not sure, but I don't know how test the wireless > >>> > throughout put. > >>> > > > >>> > > but the wireless card on ap sta mode can get the 140Mbps. > >>> the monitor > >>> > > mode is > >>> > > > >>> > > our optimized. so it can get the same throughout put as ap > >>> sta mode. > >>> > > > >>> > > 2009/11/25 Roman Chertov >>> > >>> > > > >>> > > > >>> >>> > >>> > > > >>> > > Are you sure that your wireless link can transmit more > >>> than > >>> > 90Mbps? I > >>> > > would try to test the base performance of your source > and > >>> > > destination first. > >>> > > > >>> > > Roman > >>> > > > >>> > > Yongheng Qi wrote: > >>> > > > Thanks, you advise is very importent for me. I think > >>> it not > >>> > the TCP > >>> > > > problem, because I test the UDP thoughout put. The > same > >>> as > >>> > TCP. Cliff > >>> > > > say about kernel will memcpy every packet. Have the > way > >>> > solve the > >>> > > > question? In the test, the kclick thread use more > then > >>> 95% > >>> > CPU. The > >>> > > > eth0 driver use the opewrt include and the ath2 use > the > >>> > atheros sdk. > >>> > > > These drivers may have problem? > >>> > > > > >>> > > > On 11/25/09, Roman Chertov >>> > >>> > > > >>> > > >>> >>> >>> > >>> > wrote: > >>> > > >> I failed to notice the config file... > >>> > > >> > >>> > > >> In addition to what Cliff said, you can try a simple > >>> test > >>> > where you > >>> > > >> configure Click as a transparent bridge to forward > >>> packets > >>> > > between two > >>> > > >> devices. Then, you can look at the counters to see > >>> where > >>> > the packet > >>> > > >> drops occur. > >>> > > >> > >>> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); > >>> > > >> > >>> > > >> If the counters for FromDevice, Queue, and ToDevice > >>> are the > >>> > same, it > >>> > > >> means that you are dropping packets at eth0 driver. > >>> You > >>> > also need to > >>> > > >> keep track of how many packets you sent from the > >>> source to > >>> > help you > >>> > > >> diagnose the issue. > >>> > > >> > >>> > > >> Roman > >>> > > >> > >>> > > >> Cliff Frey wrote: > >>> > > >>> Your config looks reasonable to me. > >>> > > >>> > >>> > > >>> How are you measuring performance? I know if you > >>> are running > >>> > > TCP on the > >>> > > >>> devices as well (if you are testing > tcp-to-the-device > >>> > rather than > >>> > > >>> forwarding > >>> > > >>> perfomance) that can slow things down (because of > TCP > >>> > > checksumming and > >>> > > >>> because linux will keep a copy of every packet, > >>> causing > >>> > there to > >>> > > be a lot > >>> > > >>> more memcpy overhead). > >>> > > >>> > >>> > > >>> Also, often the drivers contribute a lot of the > >>> slowdown, even > >>> > > though this > >>> > > >>> is very hard to measure/see. > >>> > > >>> > >>> > > >>> It also seems as though you are using a br-lan > >>> device from > >>> > > linux, perhaps > >>> > > >>> the linux bridge code isn't very fast as well. > >>> > > >>> > >>> > > >>> You can benchmark click by loading the same config, > >>> but > >>> > with an > >>> > > >>> InfiniteSource instead of a FromHost or FromDevice, > >>> and a > >>> > > Discard instead > >>> > > >>> of > >>> > > >>> a ToHost/ToDevice, and seeing what performance you > >>> get there. > >>> > > That can > >>> > > >>> give > >>> > > >>> you a benchmark for the maximum possible speeds > that > >>> you will > >>> > > see with > >>> > > >>> click. If that number is very high, then you need > to > >>> be > >>> > > optimizing your > >>> > > >>> drivers or linux. If the number is low, then the > >>> problem > >>> > > probably is in > >>> > > >>> click. > >>> > > >>> > >>> > > >>> I know from experience that it is possible to > >>> forward more > >>> > than > >>> > > 140Mbps > >>> > > >>> using kernel click with linux on a mips board in > the > >>> > 600-800 MHz > >>> > > range. > >>> > > >>> > >>> > > >>> Cliff > >>> > > >>> > >>> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi > >>> > > >>> > > >>> > > > >>> >>> wrote: > >>> > > >>> > >>> > > >>>> Click performance is so poor. I only use 3 > >>> classifier and 1 > >>> > > iprewrite and > >>> > > >>>> other general packet process elements. > >>> > > >>>> > >>> > > >>>> At 680Mhz MIPS CPU, click actually can't process > >>> over 90Mbit > >>> > > data per > >>> > > >>>> second. > >>> > > >>>> > >>> > > >>>> The attachment is the click config file. anyone > can > >>> tell > >>> > me how to > >>> > > >>>> optimize > >>> > > >>>> it. > >>> > > >>>> > >>> > > >>>> Thanks very much > >>> > > >>>> > >>> > > >>>> > >>> > > >>>> 2009/11/20 Yongheng Qi >>> > >>> > > > >>> > > > >>> >>> > >>> > > >>>> > >>> > > >>>>> Dear everyone. > >>> > > >>>>> > >>> > > >>>>> I use click roofnet process the 802.11n packet. > >>> test it use > >>> > > IxChariot. > >>> > > >>>> find > >>> > > >>>>> about 90Mbps, click use 100% cpu. > >>> > > >>>>> > >>> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS > >>> 680Mhz. > >>> > > >>>>> > >>> > > >>>>> I don't know how to make click have more > eiffciency. > >>> > > >>>>> > >>> > > >>>>> please help me, Thanks very much. > >>> > > >>>>> > >>> > > >>>>> -- > >>> > > >>>>> Yongheng Qi > >>> > > >>>>> > >>> > > >>>>> Mobile: +86 1390 119 7481 > >>> > > >>>>> > >>> > > >>>> > >>> > > >>>> -- > >>> > > >>>> Yongheng Qi > >>> > > >>>> > >>> > > >>>> Mobile: +86 1390 119 7481 > >>> > > >>>> > >>> > > >>>> _______________________________________________ > >>> > > >>>> 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 > >>> > > >>> > >>> > > >> > >>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > -- > >>> > > Yongheng Qi > >>> > > > >>> > > Mobile: +86 1390 119 7481 > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Yongheng Qi > >>> > > >>> > Mobile: +86 1390 119 7481 > >>> > >>> > >>> > >>> > >>> -- > >>> Yongheng Qi > >>> > >>> Mobile: +86 1390 119 7481 > >> > > > > -- Yongheng Qi Mobile: +86 1390 119 7481 From kohler at cs.ucla.edu Fri Nov 27 19:33:35 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 27 Nov 2009 16:33:35 -0800 Subject: [Click] linuxpatchless In-Reply-To: <4B0EC629.1060303@cs.ucla.edu> References: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> <4B0EC629.1060303@cs.ucla.edu> Message-ID: <4B106FDF.4030704@cs.ucla.edu> Mainline also now mostly compiles on 2.6.31 with --enable-fixincludes. FromHost and ToDevice do not compile; they need to be ELEMENT_REQUIRES(false)d out. E Eddie Kohler wrote: > Hello all, > > Harald Schi?berg wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Eddie started to pick up on his patch-making perl magic and tries to >> write some magic to automatically mangle those into C++ compliance >> independently from the kernel version used. > > This is now done. On current git, if you configure with --enable-fixincludes, > Click will automatically fix Linux's headers for C++ compatibility -- at least > on my 2.6.27 Ubuntu laptop, it succeeds, though I'm sure every now and then a > new version will require an update to the scripts. I have successfully run > conf/test.click on an unpatched kernel! Neat. > > FWIW on linuxpatchless, at least FromDevice, ToDevice, ToHost, and FromHost > will need closer attention. (Not just From and ToDevice.) > > Thanks to you and to our most excellent Syclick hosts! > > Eddie > > > >> For documentation: >> Everthing should be simple almost regular expressions, like the notorious >> - - asm ( foo :: bar ) >> + asm ( foo : : bar ) >> One notable exception: >> the current click patch changes >> - - struct foo {} >> + EMPTY_STRUCT_DECL(foo) >> The EMPTY_STRUCT_DECL is one byte long, because empty structs are one >> byte in C++ but zero bytes in C. so this actually changes linux's >> internal structures. The prosed solution it to redefine that into a >> char[0] with is also zero bytes in C++, so we can still interface with >> the now unpatched structures of the kernel. >> >> On the functional patches: >> We will try to exchange anything in the linuxpatchless directory that >> accesses one of click's hooks into something that uses a similar linux >> hook instead. Probably only the FromDevice and ToDevice Elements will >> have to be updated. >> The theory converged on registering click with dev_add_pack() and then >> overwriting skb->protocol in the received sk_buffs to prevent other's >> from handling the packet as well... >> Whoever feels more practical: post your patches ;-) >> >> That's all I remember on that part, a BIG THANK YOU again to the >> organizers of syclick who made all that possible in the first place. >> >> - -- >> 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 >> >> iD8DBQFLDY1ay8wrZ9OvkU0RAniwAJ9slIU/lUypJovGmTYIfMKW5G5hXwCfWCi0 >> ay61mfOJbRUcXRlXEeg9Xdc= >> =Udn3 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 Nov 27 19:34:12 2009 From: kohler at cs.ucla.edu (Eddie Kohler) Date: Fri, 27 Nov 2009 16:34:12 -0800 Subject: [Click] linuxpatchless In-Reply-To: References: <4B0D8D5A.30507@net.t-labs.tu-berlin.de> Message-ID: <4B107004.90807@cs.ucla.edu> For what it's worth, this is exactly Harald's plan! E Joonwoo Park wrote: > Hi forks. > > 2009/11/25 Harald Schi?berg : >> - - a small functional patch which adds click's hooks to grab packets from >> the kernel and to add the polling driver for intel e1000 cards >> > > I think we could do this with netfilter hooks for someone who doesn't > use polling, so we can avoid kernel patches completely. > > Joonwoo > > _______________________________________________ > click mailing list > click at amsterdam.lcs.mit.edu > https://amsterdam.lcs.mit.edu/mailman/listinfo/click From jetever at gmail.com Sat Nov 28 03:50:54 2009 From: jetever at gmail.com (Yongheng Qi) Date: Sat, 28 Nov 2009 16:50:54 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911241743v5cda5a70w9e57da2e7c3dd8e7@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> Message-ID: <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> I tested the NotifierQueue, the instance is the same as before. anyone have ideas? Thanks. This is the top result: Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq Load average: 0.95 0.88 0.50 PID PPID USER STAT VSZ %MEM %CPU COMMAND 777 2 root RW 0 0% 99% [kclick] 807 691 root R 1960 2% 0% top 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 691 682 root S 1972 2% 0% -ash 2009/11/28 Yongheng Qi > Thanks very much, Roman. > > I will read the paper serious. and thanks your advise about notifier > queues. > > now I only use the general Queue(). now it is the wee hours at my local > time. > > I am at home. tomorrow I will go to my office. and If I get the new > instance. > > I will mail to you. > > 2009/11/28 Roman Chertov > > Yongheng Qi wrote: >> > Thanks roman,I think my question is how to reduce the kclick cpu load, >> > now when the thoughput get about 90Mbps kclick use 100% cpu. So I want >> > to make kclick more quickly, and it will process more packets. >> >> I highly recommend that you read this >> http://pdos.csail.mit.edu/papers/click:tocs00/paper.pdf It explains how >> the elements interact with each other and how the packets are processed. >> This should give you some insights as to how you can reduce the load >> and speed up the processing by rearranging your click config. >> >> Also, search the mail archives about notifier queues. There was a >> discussion a while ago on how to reduce the CPU load when the packet >> load is not very high. >> >> Roman >> >> > >> > How do you think? >> > >> > On 11/28/09, Roman Chertov wrote: >> >> Yongheng Qi wrote: >> >>> By the way, when test the two routes use wireless, both them kclick >> >>> thread use more then 95% CPU load. >> >>> >> >>> I check all queue I am used, nothing be droped. >> >> This most likely means that you are dropping packets at the input >> >> interfaces as they are not drained fast enough. >> >> >> >>> how to play with the BURST parameter? >> >> http://read.cs.ucla.edu/click/elements/fromdevice >> >> >> >> BURST allows to specify how many packets to dequeue at once. You can >> >> try increasing this value from its default (8). >> >> >> >> Roman >> >> >> >>> Thanks >> >>> >> >>> 2009/11/25 Roman Chertov > >>> > >> >>> >> >>> When you run your original config on the gateway device, look at >> the >> >>> dmesg output. If there are queue drops in any of the queues, you >> will >> >>> notice that. If that is the case, you will have to modify your >> >>> config. >> >>> For example, you can play with the BURST parameter. >> >>> >> >>> Yongheng Qi wrote: >> >>> > Thanks, Roman, >> >>> > >> >>> > I have test the FromDevice(eth0) -> ctr :: AverageCounter -> >> >>> Discard and >> >>> > FromDevice(br-lan) >> >>> > >> >>> > both can get the 100Mbps throuthput, it is my etherlink limit. >> >>> > >> >>> > >> >>> > >> >>> > 2009/11/25 Roman Chertov > >>> >> >>> > >> >> >>> > >> >>> > You can run Click on the receiver with the following config >> >>> file. >> >>> > >> >>> > FromDevice(devX) -> ctr :: AverageCounter -> Discard; >> >>> > >> >>> > Then, you can look at the ctr stats to see what throughput >> you >> >>> are >> >>> > getting at the receiver. >> >>> > >> >>> > Yongheng Qi wrote: >> >>> > > en, I am not sure, but I don't know how test the wireless >> >>> > throughout put. >> >>> > > >> >>> > > but the wireless card on ap sta mode can get the 140Mbps. >> >>> the monitor >> >>> > > mode is >> >>> > > >> >>> > > our optimized. so it can get the same throughout put as ap >> >>> sta mode. >> >>> > > >> >>> > > 2009/11/25 Roman Chertov > >>> >> >>> > > >> >>> > > > > >> >>> >>> >> >>> > > >> >>> > > Are you sure that your wireless link can transmit more >> >>> than >> >>> > 90Mbps? I >> >>> > > would try to test the base performance of your source >> and >> >>> > > destination first. >> >>> > > >> >>> > > Roman >> >>> > > >> >>> > > Yongheng Qi wrote: >> >>> > > > Thanks, you advise is very importent for me. I think >> >>> it not >> >>> > the TCP >> >>> > > > problem, because I test the UDP thoughout put. The >> same >> >>> as >> >>> > TCP. Cliff >> >>> > > > say about kernel will memcpy every packet. Have the >> way >> >>> > solve the >> >>> > > > question? In the test, the kclick thread use more >> then >> >>> 95% >> >>> > CPU. The >> >>> > > > eth0 driver use the opewrt include and the ath2 use >> the >> >>> > atheros sdk. >> >>> > > > These drivers may have problem? >> >>> > > > >> >>> > > > On 11/25/09, Roman Chertov > >>> >> >>> > > >> >>> > > > >>> > >>> >>> >> >>> > wrote: >> >>> > > >> I failed to notice the config file... >> >>> > > >> >> >>> > > >> In addition to what Cliff said, you can try a >> simple >> >>> test >> >>> > where you >> >>> > > >> configure Click as a transparent bridge to forward >> >>> packets >> >>> > > between two >> >>> > > >> devices. Then, you can look at the counters to see >> >>> where >> >>> > the packet >> >>> > > >> drops occur. >> >>> > > >> >> >>> > > >> FromDevice(eth0) -> Queue -> ToDevice(eth1); >> >>> > > >> >> >>> > > >> If the counters for FromDevice, Queue, and ToDevice >> >>> are the >> >>> > same, it >> >>> > > >> means that you are dropping packets at eth0 driver. >> >>> You >> >>> > also need to >> >>> > > >> keep track of how many packets you sent from the >> >>> source to >> >>> > help you >> >>> > > >> diagnose the issue. >> >>> > > >> >> >>> > > >> Roman >> >>> > > >> >> >>> > > >> Cliff Frey wrote: >> >>> > > >>> Your config looks reasonable to me. >> >>> > > >>> >> >>> > > >>> How are you measuring performance? I know if you >> >>> are running >> >>> > > TCP on the >> >>> > > >>> devices as well (if you are testing >> tcp-to-the-device >> >>> > rather than >> >>> > > >>> forwarding >> >>> > > >>> perfomance) that can slow things down (because of >> TCP >> >>> > > checksumming and >> >>> > > >>> because linux will keep a copy of every packet, >> >>> causing >> >>> > there to >> >>> > > be a lot >> >>> > > >>> more memcpy overhead). >> >>> > > >>> >> >>> > > >>> Also, often the drivers contribute a lot of the >> >>> slowdown, even >> >>> > > though this >> >>> > > >>> is very hard to measure/see. >> >>> > > >>> >> >>> > > >>> It also seems as though you are using a br-lan >> >>> device from >> >>> > > linux, perhaps >> >>> > > >>> the linux bridge code isn't very fast as well. >> >>> > > >>> >> >>> > > >>> You can benchmark click by loading the same >> config, >> >>> but >> >>> > with an >> >>> > > >>> InfiniteSource instead of a FromHost or >> FromDevice, >> >>> and a >> >>> > > Discard instead >> >>> > > >>> of >> >>> > > >>> a ToHost/ToDevice, and seeing what performance you >> >>> get there. >> >>> > > That can >> >>> > > >>> give >> >>> > > >>> you a benchmark for the maximum possible speeds >> that >> >>> you will >> >>> > > see with >> >>> > > >>> click. If that number is very high, then you need >> to >> >>> be >> >>> > > optimizing your >> >>> > > >>> drivers or linux. If the number is low, then the >> >>> problem >> >>> > > probably is in >> >>> > > >>> click. >> >>> > > >>> >> >>> > > >>> I know from experience that it is possible to >> >>> forward more >> >>> > than >> >>> > > 140Mbps >> >>> > > >>> using kernel click with linux on a mips board in >> the >> >>> > 600-800 MHz >> >>> > > range. >> >>> > > >>> >> >>> > > >>> Cliff >> >>> > > >>> >> >>> > > >>> On Tue, Nov 24, 2009 at 1:48 AM, Yongheng Qi >> >>> > >> >>> > >> >>> > > >> >>> >>> wrote: >> >>> > > >>> >> >>> > > >>>> Click performance is so poor. I only use 3 >> >>> classifier and 1 >> >>> > > iprewrite and >> >>> > > >>>> other general packet process elements. >> >>> > > >>>> >> >>> > > >>>> At 680Mhz MIPS CPU, click actually can't process >> >>> over 90Mbit >> >>> > > data per >> >>> > > >>>> second. >> >>> > > >>>> >> >>> > > >>>> The attachment is the click config file. anyone >> can >> >>> tell >> >>> > me how to >> >>> > > >>>> optimize >> >>> > > >>>> it. >> >>> > > >>>> >> >>> > > >>>> Thanks very much >> >>> > > >>>> >> >>> > > >>>> >> >>> > > >>>> 2009/11/20 Yongheng Qi > >>> >> >>> > > >> >>> > > >> >>> >>> >> >>> > > >>>> >> >>> > > >>>>> Dear everyone. >> >>> > > >>>>> >> >>> > > >>>>> I use click roofnet process the 802.11n packet. >> >>> test it use >> >>> > > IxChariot. >> >>> > > >>>> find >> >>> > > >>>>> about 90Mbps, click use 100% cpu. >> >>> > > >>>>> >> >>> > > >>>>> I use routeros 433AH boardband.the cpu is MIPS >> >>> 680Mhz. >> >>> > > >>>>> >> >>> > > >>>>> I don't know how to make click have more >> eiffciency. >> >>> > > >>>>> >> >>> > > >>>>> please help me, Thanks very much. >> >>> > > >>>>> >> >>> > > >>>>> -- >> >>> > > >>>>> Yongheng Qi >> >>> > > >>>>> >> >>> > > >>>>> Mobile: +86 1390 119 7481 >> >>> > > >>>>> >> >>> > > >>>> >> >>> > > >>>> -- >> >>> > > >>>> Yongheng Qi >> >>> > > >>>> >> >>> > > >>>> Mobile: +86 1390 119 7481 >> >>> > > >>>> >> >>> > > >>>> _______________________________________________ >> >>> > > >>>> 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 >> >>> > > >>> >> >>> > > >> >> >>> > > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > Yongheng Qi >> >>> > > >> >>> > > Mobile: +86 1390 119 7481 >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Yongheng Qi >> >>> > >> >>> > Mobile: +86 1390 119 7481 >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Yongheng Qi >> >>> >> >>> Mobile: +86 1390 119 7481 >> >> >> > >> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > -- Yongheng Qi Mobile: +86 1390 119 7481 From cliff at meraki.com Sat Nov 28 14:08:23 2009 From: cliff at meraki.com (Cliff Frey) Date: Sat, 28 Nov 2009 11:08:23 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <4B0C8CB8.5070102@cs.ucsb.edu> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> Message-ID: 56% softirq implies to me that 56% of the time is spent in the packet receive functions in your ethernet or wireless driver.... as click should not be running at softirq context. 15% irq means that 15% of the time is actually in interrupt handlers, again that is likely your wireless and/or ethernet drivers. So I don't think that your performance problem is in kclick itself. Probably you could get 10% better performance if you were able to get rid of many many click elements in your data path... but I really think that you should be looking at your ethernet/wireless drivers instead. As I said in my earlier email, you need to break down your problem into smaller pieces before you can blame kclick for the performance. You could also enable CONFIG_PROFILE in linux, which could give you insight into how much time your drivers are spending on what lines of code... but it is a fair amount of work. In addition, with some work you can get linux to also profile your kernel modules... for instance: http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/1115.html Good luck. Cliff On Sat, Nov 28, 2009 at 12:50 AM, Yongheng Qi wrote: > I tested the NotifierQueue, the instance is the same as before. > > anyone have ideas? Thanks. > > This is the top result: > > Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached > CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq > Load average: 0.95 0.88 0.50 > PID PPID USER STAT VSZ %MEM %CPU COMMAND > 777 2 root RW 0 0% 99% [kclick] > 807 691 root R 1960 2% 0% top > 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 > 691 682 root S 1972 2% 0% -ash > > From jetever at gmail.com Sun Nov 29 00:12:32 2009 From: jetever at gmail.com (Yongheng Qi) Date: Sun, 29 Nov 2009 13:12:32 +0800 Subject: [Click] click optimize efficiency In-Reply-To: References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> Message-ID: <3958ac680911282112gfbbfcfq31d9a225f63d22f2@mail.gmail.com> Dear Cliff, Thanks your advice. you mean should use PollDevice replace FromDevice? but find the question in wireless driver or ethernet driver, very difficult. 2009/11/29 Cliff Frey > 56% softirq implies to me that 56% of the time is spent in the packet > receive functions in your ethernet or wireless driver.... as click should > not be running at softirq context. 15% irq means that 15% of the time is > actually in interrupt handlers, again that is likely your wireless and/or > ethernet drivers. So I don't think that your performance problem is in > kclick itself. Probably you could get 10% better performance if you were > able to get rid of many many click elements in your data path... but I > really think that you should be looking at your ethernet/wireless drivers > instead. > > As I said in my earlier email, you need to break down your problem into > smaller pieces before you can blame kclick for the performance. You could > also enable CONFIG_PROFILE in linux, which could give you insight into how > much time your drivers are spending on what lines of code... but it is a > fair amount of work. In addition, with some work you can get linux to also > profile your kernel modules... for instance: > http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/1115.html > > Good luck. > > Cliff > > > On Sat, Nov 28, 2009 at 12:50 AM, Yongheng Qi wrote: > >> I tested the NotifierQueue, the instance is the same as before. >> >> anyone have ideas? Thanks. >> >> This is the top result: >> >> Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached >> CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq >> Load average: 0.95 0.88 0.50 >> PID PPID USER STAT VSZ %MEM %CPU COMMAND >> 777 2 root RW 0 0% 99% [kclick] >> 807 691 root R 1960 2% 0% top >> 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 >> 691 682 root S 1972 2% 0% -ash >> >> > -- Yongheng Qi Mobile: +86 1390 119 7481 From jetever at gmail.com Sun Nov 29 08:01:10 2009 From: jetever at gmail.com (Yongheng Qi) Date: Sun, 29 Nov 2009 21:01:10 +0800 Subject: [Click] click optimize efficiency In-Reply-To: References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911241839w6e6546e2s3cc5875399e44dcd@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> Message-ID: <3958ac680911290501p4d89406fu2be02b158e75abef@mail.gmail.com> Dear Cliff My system use FromDevice get packet from wireless and ethernet driver. you mean FromDeivce used interrupt is irq but not the softirq? I can't distinguish between irq and softirq at driver , FromDevice and ToDevice. 2009/11/29 Cliff Frey > 56% softirq implies to me that 56% of the time is spent in the packet > receive functions in your ethernet or wireless driver.... as click should > not be running at softirq context. 15% irq means that 15% of the time is > actually in interrupt handlers, again that is likely your wireless and/or > ethernet drivers. So I don't think that your performance problem is in > kclick itself. Probably you could get 10% better performance if you were > able to get rid of many many click elements in your data path... but I > really think that you should be looking at your ethernet/wireless drivers > instead. > > As I said in my earlier email, you need to break down your problem into > smaller pieces before you can blame kclick for the performance. You could > also enable CONFIG_PROFILE in linux, which could give you insight into how > much time your drivers are spending on what lines of code... but it is a > fair amount of work. In addition, with some work you can get linux to also > profile your kernel modules... for instance: > http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/1115.html > > Good luck. > > Cliff > > > On Sat, Nov 28, 2009 at 12:50 AM, Yongheng Qi wrote: > >> I tested the NotifierQueue, the instance is the same as before. >> >> anyone have ideas? Thanks. >> >> This is the top result: >> >> Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached >> CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq >> Load average: 0.95 0.88 0.50 >> PID PPID USER STAT VSZ %MEM %CPU COMMAND >> 777 2 root RW 0 0% 99% [kclick] >> 807 691 root R 1960 2% 0% top >> 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 >> 691 682 root S 1972 2% 0% -ash >> >> > -- Yongheng Qi Mobile: +86 1390 119 7481 From michael.voorhaen at ua.ac.be Sun Nov 29 15:05:11 2009 From: michael.voorhaen at ua.ac.be (Michael Voorhaen) Date: Sun, 29 Nov 2009 21:05:11 +0100 Subject: [Click] AODV and OLSR implementations Message-ID: Dear all, It is our pleasure to announce to you that we have released of our AODV and OLSR implementations for Click Modular Router at . The OLSR implementation was written for Click 1.5 and the AODV implementation for Click 1.6. However, we have decided to release them in a tree that contains the current Click git release. Our two trees are actually git forks of the Click git repository. Currently things compile with --enable-aodv or --enable-olsr, however some work is needed to improve compatibility with the click-git. e.g. in the OLSR implementation there are still some calls to deprecated classes and functions. Be sure to read the README files, they contain valuable information on known bugs. We welcome any patches, hoping this can improve the quality of our implementations and help the community. We have chosen to release this code as is. The code is often maintained by different people in our group, who find use for it in their projects. To allow others to use and improve this code we have made it available through github. We are hoping that fixes and improvements flow back to the main branch through the community. Best regards, the PATS research group From cliff at meraki.com Sun Nov 29 15:07:01 2009 From: cliff at meraki.com (Cliff Frey) Date: Sun, 29 Nov 2009 12:07:01 -0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911290501p4d89406fu2be02b158e75abef@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <4B0C9A6B.3090308@cs.ucsb.edu> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> <3958ac680911290501p4d89406fu2be02b158e75abef@mail.gmail.com> Message-ID: IRQ time is likely time spent in interrupt handlers... most likely your drivers (ethernet and wireless) both install interrupt handlers. This is _not_ time spent in click. This is time spent in your drivers. Softirq time is generally time spent in tasklets, either explicit tasklets used by drivers or by rx_poll functions. Again, this is time spent in your driver, not in click. If you want to choose what to optimize, then you must do what I suggested in the first email, and measure the performance of each part of your system individually. You could replace FromDevice with InfiniteSource and ToDevice with (Counter -> Discard) and see what byte/packet rate click can achieve on its own. You could run InfiniteSource -> Counter -> ToDevice And see how many packets/bytes per second your drivers are capable of sending. Either way, I feel like your measurements indicate that it is not a click performance problem, but in fact a driver performance problem. Good luck, Cliff On Sun, Nov 29, 2009 at 5:01 AM, Yongheng Qi wrote: > Dear Cliff > > My system use FromDevice get packet from wireless and ethernet driver. you > mean FromDeivce used interrupt is irq but not the softirq? > > I can't distinguish between irq and softirq at driver , FromDevice and > ToDevice. > > 2009/11/29 Cliff Frey > >> 56% softirq implies to me that 56% of the time is spent in the packet >> receive functions in your ethernet or wireless driver.... as click should >> not be running at softirq context. 15% irq means that 15% of the time is >> actually in interrupt handlers, again that is likely your wireless and/or >> ethernet drivers. So I don't think that your performance problem is in >> kclick itself. Probably you could get 10% better performance if you were >> able to get rid of many many click elements in your data path... but I >> really think that you should be looking at your ethernet/wireless drivers >> instead. >> >> >> As I said in my earlier email, you need to break down your problem into >> smaller pieces before you can blame kclick for the performance. You could >> also enable CONFIG_PROFILE in linux, which could give you insight into how >> much time your drivers are spending on what lines of code... but it is a >> fair amount of work. In addition, with some work you can get linux to also >> profile your kernel modules... for instance: >> http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/1115.html >> >> Good luck. >> >> Cliff >> >> >> On Sat, Nov 28, 2009 at 12:50 AM, Yongheng Qi wrote: >> >>> I tested the NotifierQueue, the instance is the same as before. >>> >>> anyone have ideas? Thanks. >>> >>> This is the top result: >>> >>> Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached >>> CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq >>> Load average: 0.95 0.88 0.50 >>> PID PPID USER STAT VSZ %MEM %CPU COMMAND >>> 777 2 root RW 0 0% 99% [kclick] >>> 807 691 root R 1960 2% 0% top >>> 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 >>> 691 682 root S 1972 2% 0% -ash >>> >>> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > From nicolas.letor at gmail.com Mon Nov 30 03:59:41 2009 From: nicolas.letor at gmail.com (Nicolas Letor) Date: Mon, 30 Nov 2009 09:59:41 +0100 Subject: [Click] Annotation Validation Message-ID: Hi, On the developer day of the SyClick sumposium we devised a solution for checking and validating the use of annotations. I have created a small patch containing the AnnotationValidation skeleton solution. The devised solution consists of two parts: a) Each element declares its use of annotations. We extended the element interface with two methods: require_anno() and provide_anno(), indicating which annotations are used and set by this element. b) At initialization time of the click Router, an AnnotationValidator element verifies the use of annotations by traversing the Click graph and inspecting the element's annotation requirements and provisions. Kind regards, Nico -- Nicolas Letor University of Antwerp Dept. Math. and Computer Science PATS - Performance Analysis of Telecommunication Systems Research Group Middelheimlaan 1, B-2020 Antwerp, Belgium -------------- next part -------------- A non-text attachment was scrubbed... Name: annotationvalidator.patch Type: application/octet-stream Size: 5947 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091130/985d11c7/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: testannotation.click Type: application/octet-stream Size: 261 bytes Desc: not available Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20091130/985d11c7/attachment-0001.obj From jetever at gmail.com Mon Nov 30 12:42:00 2009 From: jetever at gmail.com (Yongheng Qi) Date: Tue, 1 Dec 2009 01:42:00 +0800 Subject: [Click] click optimize efficiency In-Reply-To: References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <3958ac680911241853r6f687c7cy617cee0b26f685f6@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> <3958ac680911290501p4d89406fu2be02b158e75abef@mail.gmail.com> Message-ID: <3958ac680911300942k5896c218l47cf2e846cd6e47e@mail.gmail.com> Dear Cliff and friends: Today, I test the click efficiency without driver, it's work very well. your point is right, thanks. but both ethernet and wireless lead to cpu high loading. so I trace the element ToDevice code: ret = _dev->hard_start_xmit(skb1, _dev); this line send packet throuth driver. if don't excute this line. the cpu load is normal. if excute this line, only ToDevice(eth0) will have high cpu loading. I test ToDevice(ath0) too, the issue like ToDevice(eth0) too. I don't know click ToDevice use hard_start_xmit. why have the strange problem? the hard_start_xmit in the kernel is diffient with dev_queue_xmit. I guess in the ToDevice use interrupt have some conflict with kernel. how to solve the problem? Thanks 2009/11/30 Cliff Frey > IRQ time is likely time spent in interrupt handlers... most likely your > drivers (ethernet and wireless) both install interrupt handlers. This is > _not_ time spent in click. This is time spent in your drivers. > > Softirq time is generally time spent in tasklets, either explicit tasklets > used by drivers or by rx_poll functions. Again, this is time spent in your > driver, not in click. > > If you want to choose what to optimize, then you must do what I suggested > in the first email, and measure the performance of each part of your system > individually. You could replace FromDevice with InfiniteSource and ToDevice > with (Counter -> Discard) and see what byte/packet rate click can achieve on > its own. > > You could run > > InfiniteSource -> Counter -> ToDevice > > And see how many packets/bytes per second your drivers are capable of > sending. > > Either way, I feel like your measurements indicate that it is not a click > performance problem, but in fact a driver performance problem. > > Good luck, > > Cliff > > > On Sun, Nov 29, 2009 at 5:01 AM, Yongheng Qi wrote: > >> Dear Cliff >> >> My system use FromDevice get packet from wireless and ethernet driver. you >> mean FromDeivce used interrupt is irq but not the softirq? >> >> I can't distinguish between irq and softirq at driver , FromDevice and >> ToDevice. >> >> 2009/11/29 Cliff Frey >> >>> 56% softirq implies to me that 56% of the time is spent in the packet >>> receive functions in your ethernet or wireless driver.... as click should >>> not be running at softirq context. 15% irq means that 15% of the time is >>> actually in interrupt handlers, again that is likely your wireless and/or >>> ethernet drivers. So I don't think that your performance problem is in >>> kclick itself. Probably you could get 10% better performance if you were >>> able to get rid of many many click elements in your data path... but I >>> really think that you should be looking at your ethernet/wireless drivers >>> instead. >>> >>> >>> As I said in my earlier email, you need to break down your problem into >>> smaller pieces before you can blame kclick for the performance. You could >>> also enable CONFIG_PROFILE in linux, which could give you insight into how >>> much time your drivers are spending on what lines of code... but it is a >>> fair amount of work. In addition, with some work you can get linux to also >>> profile your kernel modules... for instance: >>> http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/1115.html >>> >>> Good luck. >>> >>> Cliff >>> >>> >>> On Sat, Nov 28, 2009 at 12:50 AM, Yongheng Qi wrote: >>> >>>> I tested the NotifierQueue, the instance is the same as before. >>>> >>>> anyone have ideas? Thanks. >>>> >>>> This is the top result: >>>> >>>> Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached >>>> CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq >>>> Load average: 0.95 0.88 0.50 >>>> PID PPID USER STAT VSZ %MEM %CPU COMMAND >>>> 777 2 root RW 0 0% 99% [kclick] >>>> 807 691 root R 1960 2% 0% top >>>> 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 >>>> 691 682 root S 1972 2% 0% -ash >>>> >>>> >>> >> >> >> -- >> Yongheng Qi >> >> Mobile: +86 1390 119 7481 >> > > -- Yongheng Qi Mobile: +86 1390 119 7481 From jetever at gmail.com Mon Nov 30 12:47:41 2009 From: jetever at gmail.com (Yongheng Qi) Date: Tue, 1 Dec 2009 01:47:41 +0800 Subject: [Click] click optimize efficiency In-Reply-To: <3958ac680911300942k5896c218l47cf2e846cd6e47e@mail.gmail.com> References: <3958ac680911191831g752caea5laf413427f9dcdf1e@mail.gmail.com> <4B100656.5010402@cs.ucsb.edu> <3958ac680911270928w5ae3e79bt6787db0938b84339@mail.gmail.com> <4B10120F.5050302@cs.ucsb.edu> <3958ac680911271000r15b660b9v37eba925d5fb5f3f@mail.gmail.com> <3958ac680911280050u2ddc57dfi6268e806bbf223d5@mail.gmail.com> <3958ac680911290501p4d89406fu2be02b158e75abef@mail.gmail.com> <3958ac680911300942k5896c218l47cf2e846cd6e47e@mail.gmail.com> Message-ID: <3958ac680911300947x6f6a0a2xe216ff224de3413@mail.gmail.com> By the way, I used kernel version is 2.6.26.5 On 12/1/09, Yongheng Qi wrote: > Dear Cliff and friends: > > Today, I test the click efficiency without driver, it's work very well. > your > point is right, thanks. > > but both ethernet and wireless lead to cpu high loading. so I trace the > element ToDevice code: > > ret = _dev->hard_start_xmit(skb1, _dev); > > this line send packet throuth driver. if don't excute this line. the cpu > load is normal. if excute this line, > > only ToDevice(eth0) will have high cpu loading. I test ToDevice(ath0) too, > the issue like ToDevice(eth0) too. > > I don't know click ToDevice use hard_start_xmit. why have the strange > problem? the hard_start_xmit in the kernel is > > diffient with dev_queue_xmit. I guess in the ToDevice use interrupt have > some conflict with kernel. > > how to solve the problem? > > Thanks > > > 2009/11/30 Cliff Frey > >> IRQ time is likely time spent in interrupt handlers... most likely your >> drivers (ethernet and wireless) both install interrupt handlers. This is >> _not_ time spent in click. This is time spent in your drivers. >> >> Softirq time is generally time spent in tasklets, either explicit >> tasklets >> used by drivers or by rx_poll functions. Again, this is time spent in >> your >> driver, not in click. >> >> If you want to choose what to optimize, then you must do what I suggested >> in the first email, and measure the performance of each part of your >> system >> individually. You could replace FromDevice with InfiniteSource and >> ToDevice >> with (Counter -> Discard) and see what byte/packet rate click can achieve >> on >> its own. >> >> You could run >> >> InfiniteSource -> Counter -> ToDevice >> >> And see how many packets/bytes per second your drivers are capable of >> sending. >> >> Either way, I feel like your measurements indicate that it is not a click >> performance problem, but in fact a driver performance problem. >> >> Good luck, >> >> Cliff >> >> >> On Sun, Nov 29, 2009 at 5:01 AM, Yongheng Qi wrote: >> >>> Dear Cliff >>> >>> My system use FromDevice get packet from wireless and ethernet driver. >>> you >>> mean FromDeivce used interrupt is irq but not the softirq? >>> >>> I can't distinguish between irq and softirq at driver , FromDevice and >>> ToDevice. >>> >>> 2009/11/29 Cliff Frey >>> >>>> 56% softirq implies to me that 56% of the time is spent in the packet >>>> receive functions in your ethernet or wireless driver.... as click >>>> should >>>> not be running at softirq context. 15% irq means that 15% of the time >>>> is >>>> actually in interrupt handlers, again that is likely your wireless >>>> and/or >>>> ethernet drivers. So I don't think that your performance problem is in >>>> kclick itself. Probably you could get 10% better performance if you >>>> were >>>> able to get rid of many many click elements in your data path... but I >>>> really think that you should be looking at your ethernet/wireless >>>> drivers >>>> instead. >>>> >>>> >>>> As I said in my earlier email, you need to break down your problem into >>>> smaller pieces before you can blame kclick for the performance. You >>>> could >>>> also enable CONFIG_PROFILE in linux, which could give you insight into >>>> how >>>> much time your drivers are spending on what lines of code... but it is >>>> a >>>> fair amount of work. In addition, with some work you can get linux to >>>> also >>>> profile your kernel modules... for instance: >>>> http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/1115.html >>>> >>>> Good luck. >>>> >>>> Cliff >>>> >>>> >>>> On Sat, Nov 28, 2009 at 12:50 AM, Yongheng Qi >>>> wrote: >>>> >>>>> I tested the NotifierQueue, the instance is the same as before. >>>>> >>>>> anyone have ideas? Thanks. >>>>> >>>>> This is the top result: >>>>> >>>>> Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached >>>>> CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% >>>>> softirq >>>>> Load average: 0.95 0.88 0.50 >>>>> PID PPID USER STAT VSZ %MEM %CPU COMMAND >>>>> 777 2 root RW 0 0% 99% [kclick] >>>>> 807 691 root R 1960 2% 0% top >>>>> 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 >>>>> 691 682 root S 1972 2% 0% -ash >>>>> >>>>> >>>> >>> >>> >>> -- >>> Yongheng Qi >>> >>> Mobile: +86 1390 119 7481 >>> >> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > -- Sent from my mobile device Yongheng Qi Mobile: +86 1390 119 7481 From javier.recacha at gmail.com Mon Nov 30 14:02:32 2009 From: javier.recacha at gmail.com (=?ISO-8859-1?Q?Javier_S=E1nchez?=) Date: Mon, 30 Nov 2009 20:02:32 +0100 Subject: [Click] Madwifi monitor mode performance Message-ID: Hi Yongheng Qi and Click users, Sorry for disturbing you, but I am very, very interested on a sentence you said. ?the monitor mode is our optimized. so it can get the same throughout put as ap sta mode.? I tried to optimize the driver too, I tried to implement atheros FF and atheros compresion into ath_tx_startraw(), but I only achieve: Click + monitor mode + pseudo IBSS: 13 Mbps (iperf, rate 24M) Normal operation ap mode + managed mode: 18 Mbps (iperf, rate 24M) Can you (or someone) share how to achived this?? Some hint? Thanks Javier
