headers
Kristin Stephens | 1 Jul 2011 01:16
Picon
Favicon

Unable to compile element for kernel level click

Hi,

I'm trying to compile my click package for the kernel level click. The
package uses list, map, and FILE, but kept getting compile errors.
When I removed the elements that use those libraries I finally was
able to compile. However this obviously defeats the purpose.

Could someone point me towards resources on either how I can get
around this or what I can and cannot do when I want to compile my
package for kernel level click?

Thanks,
Kristin
Permalink | Reply | 1 comment |
headers
Roman Chertov | 1 Jul 2011 01:40
Picon

Re: Unable to compile element for kernel level click

On Thu, 30 Jun 2011 16:16:06 -0700 Kristin Stephens <ksteph <at> cs.berkeley.edu>
wrote

> Hi,
> 
> I'm trying to compile my click package for the kernel level click. The
> package uses list, map, and FILE, but kept getting compile errors.

You need to use the data structure that click provides.  Look in
click/include/click for what it has (list, vector, hashmap, etc).

However, you cannot have file access in the kernel mode.  To get around that,
you need to define a write handler via which you can send data to your element.

Roman

> When I removed the elements that use those libraries I finally was
> able to compile. However this obviously defeats the purpose.
> 
> Could someone point me towards resources on either how I can get
> around this or what I can and cannot do when I want to compile my
> package for kernel level click?
> 
> Thanks,
> Kristin
> _______________________________________________
> click mailing list
> click <at> amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luigi Rizzo | 1 Jul 2011 19:47
Picon
Picon

click userland patches for large speed improvements

If someone is interest in performance of userland click, i'd suggest
the following two patches and looking at netmap (i already discussed
what follows with Eddie, and i am hoping someone more fluent than
me in C++ can polish the code and add a support for thread-local lists).

To get an idea of what you can get on a single core i7-870 CPU with
the stock version and with these patches:

					1.8.0		With patches
    InfiniteSource -> Discard		515Kpps		18.56Mpps
    InfiniteSource -> Queue -> Discard	500Kpps		13.41Mpps

					pcap		netmap
    FromDevice->Queue->ToDevice		420Kpps		3.97 Mpps

Click userland performance was never a priority given the high cost
(until now) of packet I/O. But once packet i/o has become quite fast,
it turns out that there are to other big offenders:
- the C++ memory allocator is quite expensive, and replacing it with
  thread-local freelists (Packet objects and data buffers can be made
  all with the same size) gives huge savings -- 100ns per packet or more
  even on a fast machine;

- everytime an element wants a timestamp, it calls a syscall (gettimeofday()
  or similar) which consumes another 400-800ns per call. There are many
  elements (e.g. InfiniteSource, Counter, etc.) which timestamp packets.

Attached there are a couple of patches which address these problems:

- patch-pcap	makes FromDevice and ToDevice use libpcap properly,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Roman Chertov | 1 Jul 2011 20:01
Picon

Re: click userland patches for large speed improvements

For curiosity sake, I just ran the script shown below on my machine and got 
3.34 Mpps.  I am using the latest Click from git (as of two days ago), and
running the following CPUs: Intel(R) Xeon(R) CPU  W3520   <at>  2.67GH

It seems that 0.5Mpps is pretty low for an i7-870 CPU, but it does appear that
the patches improved the performance significantly.

InfiniteSource -> ctr::AverageCounter -> Queue -> Discard;

Script(
    wait 60,
    print ctr.count,
    print ctr.byte_count,
);

Roman

On Fri, 1 Jul 2011 19:47:13 +0200 Luigi Rizzo <rizzo <at> iet.unipi.it> wrote

> If someone is interest in performance of userland click, i'd suggest
> the following two patches and looking at netmap (i already discussed
> what follows with Eddie, and i am hoping someone more fluent than
> me in C++ can polish the code and add a support for thread-local lists).
> 
> To get an idea of what you can get on a single core i7-870 CPU with
> the stock version and with these patches:
> 
> 					1.8.0		With patches
>     InfiniteSource -> Discard		515Kpps		18.56Mpps
>     InfiniteSource -> Queue -> Discard	500Kpps		13.41Mpps
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eddie Kohler | 1 Jul 2011 20:13
Favicon

Re: click userland patches for large speed improvements

Hi Roman,

I believe Luigi generally tests on a FreeBSD version, and the FreeBSD malloc 
appears particularly slow compared to current Linux versions.  But Luigi's 
patches are AWESOME and will be integrated soon, with adjustments.  Any help 
appreciated!!  THANKS LUIGI!!!

Luigi, have you done github?

Eddie

On 07/01/2011 11:01 AM, Roman Chertov wrote:
> For curiosity sake, I just ran the script shown below on my machine and got
> 3.34 Mpps.  I am using the latest Click from git (as of two days ago), and
> running the following CPUs: Intel(R) Xeon(R) CPU  W3520   <at>  2.67GH
>
>
> It seems that 0.5Mpps is pretty low for an i7-870 CPU, but it does appear that
> the patches improved the performance significantly.
>
>
> InfiniteSource ->  ctr::AverageCounter ->  Queue ->  Discard;
>
>
> Script(
>      wait 60,
>      print ctr.count,
>      print ctr.byte_count,
> );
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luigi Rizzo | 2 Jul 2011 11:48
Picon
Picon

Re: click userland patches for large speed improvements

On Fri, Jul 01, 2011 at 11:13:45AM -0700, Eddie Kohler wrote:
> Hi Roman,
> 
> I believe Luigi generally tests on a FreeBSD version, and the FreeBSD malloc 
> appears particularly slow compared to current Linux versions.  But Luigi's 
> patches are AWESOME and will be integrated soon, with adjustments.  Any help 
> appreciated!!  THANKS LUIGI!!!
> 
> Luigi, have you done github?

correct, i am developing/testing on FreeBSD and click 1.8.0.

Will try github next week.

The 0.5Mpps figure is dominated by timestamps, which, with the default
configuration on freebsd, are incredibly expensive (800ns to run gettimeofday;
clock_gettime is faster, around 400ns, but click does not use it anyways).

I don't know how cheap is access to timestamps in linux , but certainly it
would make sense to have a run-time option to use, say, TSC or jiffies
as the internal representation (accessible without a syscall)
and convert to sec/usec/nsec only when the value is actually used.

Of course to use TSC you need constant_tsc, and for jiffies you need
an OS that exports the value in a readonly page to all userland threads.

cheers
luigi

> Eddie
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anatolij Zubow | 3 Jul 2011 14:09
Picon
Favicon

ClickWatch

Hi Click users,

we would like to announce the availability of ClickWatch tool which was
developed at the Humboldt University Berlin.

What is ClickWatch?

ClickWatch is an eclipse and EMF-based tool that allows to analyse and
control networks programmed with the Click-API. The Click-API is a C++
based component model specially designed for routers. ClickWatch
accumulates data from multiple network nodes. The status of the network
as well as the generation of reports and network statistics can be
easily accomplished using a model-driven transformation approach. With
the help of a graphical interface ClickWatch accelerates the software
development process. The status of the network can be analysed at
runtime so that the user is able to adapt the router configuration to
the changing environment.

ClickWatch explained in 2 minutes:
http://www.youtube.com/watch?v=c3RmUXvczV0&feature=player_embedded

ClickWatch tutorial:
http://www.youtube.com/watch?v=uyBTWwuWo4M&feature=email

Futher information + software can be found here:
http://hwl.hu-berlin.de/features/software/clickwatch-released/

Greetings,

HWL team
(Continue reading)

Permalink | Reply | 3 comments |
headers
Beyers Cronje | 4 Jul 2011 12:30
Picon
Gravatar

Re: ClickWatch

This looks awesome!

On Sun, Jul 3, 2011 at 2:09 PM, Anatolij Zubow <
zubow <at> informatik.hu-berlin.de> wrote:

> Hi Click users,
>
>
>
> we would like to announce the availability of ClickWatch tool which was
> developed at the Humboldt University Berlin.
>
>
>
> What is ClickWatch?
>
>
>
> ClickWatch is an eclipse and EMF-based tool that allows to analyse and
> control networks programmed with the Click-API. The Click-API is a C++
> based component model specially designed for routers. ClickWatch
> accumulates data from multiple network nodes. The status of the network
> as well as the generation of reports and network statistics can be
> easily accomplished using a model-driven transformation approach. With
> the help of a graphical interface ClickWatch accelerates the software
> development process. The status of the network can be analysed at
> runtime so that the user is able to adapt the router configuration to
> the changing environment.
>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roberto Riggio | 4 Jul 2011 12:57
Favicon

Re: ClickWatch

Yep, it is indeed very interesting.

I was wondering if it could make sense to have a backend to run within a 
node collecting the handlers' values and then pushing everything to the 
frontend for processing visualization.

This could be particularly useful in situations where polling the 
handlers can affect the measurements.

Il 04/07/2011 12:30, Beyers Cronje ha scritto:
> This looks awesome!
>
> On Sun, Jul 3, 2011 at 2:09 PM, Anatolij Zubow<
> zubow <at> informatik.hu-berlin.de>  wrote:
>
>> Hi Click users,
>>
>>
>>
>> we would like to announce the availability of ClickWatch tool which was
>> developed at the Humboldt University Berlin.
>>
>>
>>
>> What is ClickWatch?
>>
>>
>>
>> ClickWatch is an eclipse and EMF-based tool that allows to analyse and
>> control networks programmed with the Click-API. The Click-API is a C++
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fabrice Schuler | 5 Jul 2011 16:24
Picon

PollDevice : not compiled with polling extensions


Hello,

I'm trying to use click polling extensions, but always get the same error :

conf.click:22: While initializing 'PollDevice <at> 6 :: PollDevice':
  warning: can't get packets: not compiled with polling extensions

I'm using click in kernel mode, with kernel 2.6.35.13, but none of the
searches I did on the web was successful. Could anyone give me a hand so
I can use the PollDevice ?

Thanks for your help,
Fabrice

PS : I did not put the configuration file as this is only a sample,
fully functionnal with FromDevice and unfunctionnal with PollDevice
Permalink | Reply | 2 comments |

Gmane