From zaykalov at gmail.com  Thu Nov  1 11:05:53 2012
From: zaykalov at gmail.com (Konstantin Zaykalov)
Date: Thu, 1 Nov 2012 15:05:53 +0000
Subject: [Click] kernel patching elimination
In-Reply-To: <CAFFLP3oMqPXXhah6XoJi674iCcNZ6cJhyS6ToKXYoQojtohXhA@mail.gmail.com>
References: <CALdZA=WQ9o-U2YHJow-WJ7NHOtBsCS8zYwsDigeko5R=es36NQ@mail.gmail.com>
	<CAFFLP3oMqPXXhah6XoJi674iCcNZ6cJhyS6ToKXYoQojtohXhA@mail.gmail.com>
Message-ID: <CALdZA=UMnxdNTHJ1SAv2ddUgQ1Qo4eAJBmYC=gJbkk5yH3dmJg@mail.gmail.com>

Hi Lars,
Yes, I agree, an abstraction layer is not an easy job (otherwise it would
have probably been already done). However it is achievable for example
through a combination of own data structures that map to kernel data
structures and through functions that somewhat correspond to kernel
functions. Obviously all constant variables and primitive data types need
to be taken care of as well. This would eliminate the need to include linux
header files, over which you have no control. Obviously such an approach
will incur some performance penalty.
I think that this question is aimed primarily at Click architects (Eddie
Kohler?), I am simply wondering if the options I wrote about were ever
considered (I'd imagine they were), maybe someone has done some research
around this topic and found some really serious obstacles that make this a
non-starter, for example.
Regards,
Konstantin

On Fri, Oct 26, 2012 at 6:59 AM, Lars Bro <larsbro at gmail.com> wrote:

> Hi Konstantin
>
> At least with include files, they are "included" and cannot easily be
> abstracted away. If they contain syntax that is not C++, and are to be
> included into C++ modules, then we got the problem. For example  the use of
> the :: operator.
>
> So the way to deal with it is to run fixincludes.pl, fixing these
> particular problems, providing  a local set of include files.
>
> fixincludes.pl at least documents what include file problems are solved.
>
> yours,
> Lars Bro
>
> On Thu, Oct 25, 2012 at 2:22 PM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:
>
>> Hi,
>>
>> I've got a few questions regarding the design of Click router:
>> 1) Why does Click do kernel patching (and fixing include files via
>> fixincludes.pl script) for g++ compiler instead of providing wrapper
>> functions, surrounded by "extern "C" "? Or even some abstraction layer
>> written in C?
>> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>> 3) Why doesn't Click use NAPI for device polling?
>>
>> Basically I am looking into possibilities to eliminate kernel patching
>> altogether and make it more independent/standalone.
>>
>> Thank you,
>>
>> Konstantin
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>
>

From zaykalov at gmail.com  Thu Nov  1 11:06:46 2012
From: zaykalov at gmail.com (Konstantin Zaykalov)
Date: Thu, 1 Nov 2012 15:06:46 +0000
Subject: [Click] kernel patching elimination
In-Reply-To: <CAFFLP3oMqPXXhah6XoJi674iCcNZ6cJhyS6ToKXYoQojtohXhA@mail.gmail.com>
References: <CALdZA=WQ9o-U2YHJow-WJ7NHOtBsCS8zYwsDigeko5R=es36NQ@mail.gmail.com>
	<CAFFLP3oMqPXXhah6XoJi674iCcNZ6cJhyS6ToKXYoQojtohXhA@mail.gmail.com>
Message-ID: <CALdZA=VCDxwTDxPx7fEC8tn=6E+mqfCPAwUdP3GDLm3Np5zaRQ@mail.gmail.com>

Hi Lars,
Yes, I agree, an abstraction layer is not an easy job (otherwise it would
have probably been already done). However it is achievable for example
through a combination of own data structures that map to kernel data
structures and through functions that somewhat correspond to kernel
functions. Obviously all constant variables and primitive data types need
to be taken care of as well. This would eliminate the need to include linux
header files, over which you have no control. Obviously such an approach
will incur some performance penalty.
I think that this question is aimed primarily at Click architects (Eddie
Kohler?), I am simply wondering if the options I wrote about were ever
considered (I'd imagine they were), maybe someone has done some research
around this topic and found some really serious obstacles that make this a
non-starter, for example.
Regards,
Konstantin

On Fri, Oct 26, 2012 at 6:59 AM, Lars Bro <larsbro at gmail.com> wrote:

> Hi Konstantin
>
> At least with include files, they are "included" and cannot easily be
> abstracted away. If they contain syntax that is not C++, and are to be
> included into C++ modules, then we got the problem. For example  the use of
> the :: operator.
>
> So the way to deal with it is to run fixincludes.pl, fixing these
> particular problems, providing  a local set of include files.
>
> fixincludes.pl at least documents what include file problems are solved.
>
> yours,
> Lars Bro
>
> On Thu, Oct 25, 2012 at 2:22 PM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:
>
>> Hi,
>>
>> I've got a few questions regarding the design of Click router:
>> 1) Why does Click do kernel patching (and fixing include files via
>> fixincludes.pl script) for g++ compiler instead of providing wrapper
>> functions, surrounded by "extern "C" "? Or even some abstraction layer
>> written in C?
>> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>> 3) Why doesn't Click use NAPI for device polling?
>>
>> Basically I am looking into possibilities to eliminate kernel patching
>> altogether and make it more independent/standalone.
>>
>> Thank you,
>>
>> Konstantin
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>
>

From cliff at meraki.com  Thu Nov  1 11:15:55 2012
From: cliff at meraki.com (Cliff Frey)
Date: Thu, 1 Nov 2012 08:15:55 -0700
Subject: [Click] kernel patching elimination
In-Reply-To: <CALdZA=WQ9o-U2YHJow-WJ7NHOtBsCS8zYwsDigeko5R=es36NQ@mail.gmail.com>
References: <CALdZA=WQ9o-U2YHJow-WJ7NHOtBsCS8zYwsDigeko5R=es36NQ@mail.gmail.com>
Message-ID: <CAFtVOqmZHcP1Vw_TUOHk2jBjH93Jfe2AK=C6VQH22OtPHkSHwQ@mail.gmail.com>

On Thu, Oct 25, 2012 at 5:22 AM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:

> Hi,
>
> I've got a few questions regarding the design of Click router:
> 1) Why does Click do kernel patching (and fixing include files via
> fixincludes.pl script) for g++ compiler instead of providing wrapper
> functions, surrounded by "extern "C" "? Or even some abstraction layer
> written in C?
>

kernel patching works very well.  As Lars stated, it is not possible to
directly include the kernel header files in a c++ file, for many different
reasons (the "::" operator, use of variables name "new", etc).  If an
abstraction layer was written in C, it would need to abstract *all* packet
access, which means that reading or writing any packet data would require
an extra layer of function calls, which would likely affect performance.


> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>

Depending on the version of linux, click will use many different hooks.  If
you have a specific recommendation for something that would be better than
the current hooks, patches would be appreciated!


> 3) Why doesn't Click use NAPI for device polling?
>

Ethernet drivers use NAPI.  Click is not an ethernet driver.  The
"PollDevice" click element, which acts as an ethernet driver, was written
before NAPI existed.  It would probably be possible to build a high
performance framework that gave packets directly to click by somehow
leveraging NAPI like interfaces... it still might require compile time
changes though.

Basically I am looking into possibilities to eliminate kernel patching
> altogether and make it more independent/standalone.
>

On many versions of modern linux, kernel patching is not required, so I'm
not sure what you want to change.  Also, click can be run at userlevel in a
very standalone fashion.

Cliff

From zaykalov at gmail.com  Fri Nov  2 07:42:12 2012
From: zaykalov at gmail.com (Konstantin Zaykalov)
Date: Fri, 2 Nov 2012 11:42:12 +0000
Subject: [Click] kernel patching elimination
In-Reply-To: <CAFtVOqmZHcP1Vw_TUOHk2jBjH93Jfe2AK=C6VQH22OtPHkSHwQ@mail.gmail.com>
References: <CALdZA=WQ9o-U2YHJow-WJ7NHOtBsCS8zYwsDigeko5R=es36NQ@mail.gmail.com>
	<CAFtVOqmZHcP1Vw_TUOHk2jBjH93Jfe2AK=C6VQH22OtPHkSHwQ@mail.gmail.com>
Message-ID: <CALdZA=V3HN8wJ3wiS5T0ZwXbM9XeVbcoxXN1cywKQyL3jDW2Pw@mail.gmail.com>

Hi Cliff,

Thank you for such a detailed answer. The problem I see with Click at the
moment is that it is tied to a particular kernel version, the most recent
of which is 2.6.24.7, released in May 2008. So if I want to take advantage
of any recent feature of the kernel (such as ext4 filesystem, for example),
I need to upgrade my kernel, but Click patch can prevent me from doing so.

 If I ever make any changes to Click, I will definitely consider them to be
contributed back to the community.

There is one part of your answer I didn't quite undestand, though:

>On many versions of modern linux, kernel patching is not required, so I'm
not sure what you want to change.

Could you indicate, please, what are the versions of Linux, where kernel
patching is not required? It took me ages to find Linux version 2.6.24.7 (I
eventually had to use Wayback Machine @ web.archive.org to get it), so if
Click could work with modern Linux kernels without patching, it would be
great!

Thanks again!

Konstantin




On Thu, Nov 1, 2012 at 3:15 PM, Cliff Frey <cliff at meraki.com> wrote:

> On Thu, Oct 25, 2012 at 5:22 AM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:
>
>> Hi,
>>
>> I've got a few questions regarding the design of Click router:
>> 1) Why does Click do kernel patching (and fixing include files via
>> fixincludes.pl script) for g++ compiler instead of providing wrapper
>> functions, surrounded by "extern "C" "? Or even some abstraction layer
>> written in C?
>>
>
> kernel patching works very well.  As Lars stated, it is not possible to
> directly include the kernel header files in a c++ file, for many different
> reasons (the "::" operator, use of variables name "new", etc).  If an
> abstraction layer was written in C, it would need to abstract *all* packet
> access, which means that reading or writing any packet data would require
> an extra layer of function calls, which would likely affect performance.
>
>
>> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>>
>
> Depending on the version of linux, click will use many different hooks.
>  If you have a specific recommendation for something that would be better
> than the current hooks, patches would be appreciated!
>
>
>> 3) Why doesn't Click use NAPI for device polling?
>>
>
> Ethernet drivers use NAPI.  Click is not an ethernet driver.  The
> "PollDevice" click element, which acts as an ethernet driver, was written
> before NAPI existed.  It would probably be possible to build a high
> performance framework that gave packets directly to click by somehow
> leveraging NAPI like interfaces... it still might require compile time
> changes though.
>
> Basically I am looking into possibilities to eliminate kernel patching
>> altogether and make it more independent/standalone.
>>
>
> On many versions of modern linux, kernel patching is not required, so I'm
> not sure what you want to change.  Also, click can be run at userlevel in a
> very standalone fashion.
>
> Cliff
>
>

From cliff at meraki.com  Fri Nov  2 18:56:09 2012
From: cliff at meraki.com (Cliff Frey)
Date: Fri, 2 Nov 2012 15:56:09 -0700
Subject: [Click] kernel patching elimination
In-Reply-To: <CALdZA=V3HN8wJ3wiS5T0ZwXbM9XeVbcoxXN1cywKQyL3jDW2Pw@mail.gmail.com>
References: <CALdZA=WQ9o-U2YHJow-WJ7NHOtBsCS8zYwsDigeko5R=es36NQ@mail.gmail.com>
	<CAFtVOqmZHcP1Vw_TUOHk2jBjH93Jfe2AK=C6VQH22OtPHkSHwQ@mail.gmail.com>
	<CALdZA=V3HN8wJ3wiS5T0ZwXbM9XeVbcoxXN1cywKQyL3jDW2Pw@mail.gmail.com>
Message-ID: <CAFtVOqmSG7ueB6uxT5XVJT6VzTHsLiaao8j+zoT0DuBrE4Cp0Q@mail.gmail.com>

Have you tried just building click on your system's kernel?  I believe that
it works on all modern linux kernels.

On Fri, Nov 2, 2012 at 4:42 AM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:

> Hi Cliff,
>
> Thank you for such a detailed answer. The problem I see with Click at the
> moment is that it is tied to a particular kernel version, the most recent
> of which is 2.6.24.7, released in May 2008. So if I want to take advantage
> of any recent feature of the kernel (such as ext4 filesystem, for example),
> I need to upgrade my kernel, but Click patch can prevent me from doing so.
>
>  If I ever make any changes to Click, I will definitely consider them to be
> contributed back to the community.
>
> There is one part of your answer I didn't quite undestand, though:
>
> >On many versions of modern linux, kernel patching is not required, so I'm
> not sure what you want to change.
>
> Could you indicate, please, what are the versions of Linux, where kernel
> patching is not required? It took me ages to find Linux version 2.6.24.7 (I
> eventually had to use Wayback Machine @ web.archive.org to get it), so if
> Click could work with modern Linux kernels without patching, it would be
> great!
>
> Thanks again!
>
> Konstantin
>
>
>
>
> On Thu, Nov 1, 2012 at 3:15 PM, Cliff Frey <cliff at meraki.com> wrote:
>
> > On Thu, Oct 25, 2012 at 5:22 AM, Konstantin Zaykalov <zaykalov at gmail.com
> >wrote:
> >
> >> Hi,
> >>
> >> I've got a few questions regarding the design of Click router:
> >> 1) Why does Click do kernel patching (and fixing include files via
> >> fixincludes.pl script) for g++ compiler instead of providing wrapper
> >> functions, surrounded by "extern "C" "? Or even some abstraction layer
> >> written in C?
> >>
> >
> > kernel patching works very well.  As Lars stated, it is not possible to
> > directly include the kernel header files in a c++ file, for many
> different
> > reasons (the "::" operator, use of variables name "new", etc).  If an
> > abstraction layer was written in C, it would need to abstract *all*
> packet
> > access, which means that reading or writing any packet data would require
> > an extra layer of function calls, which would likely affect performance.
> >
> >
> >> 2) Why doesn't Click use netfilter hooks for intercepting packets?
> >>
> >
> > Depending on the version of linux, click will use many different hooks.
> >  If you have a specific recommendation for something that would be better
> > than the current hooks, patches would be appreciated!
> >
> >
> >> 3) Why doesn't Click use NAPI for device polling?
> >>
> >
> > Ethernet drivers use NAPI.  Click is not an ethernet driver.  The
> > "PollDevice" click element, which acts as an ethernet driver, was written
> > before NAPI existed.  It would probably be possible to build a high
> > performance framework that gave packets directly to click by somehow
> > leveraging NAPI like interfaces... it still might require compile time
> > changes though.
> >
> > Basically I am looking into possibilities to eliminate kernel patching
> >> altogether and make it more independent/standalone.
> >>
> >
> > On many versions of modern linux, kernel patching is not required, so I'm
> > not sure what you want to change.  Also, click can be run at userlevel
> in a
> > very standalone fashion.
> >
> > Cliff
> >
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From aditya at courant.nyu.edu  Sat Nov  3 18:23:11 2012
From: aditya at courant.nyu.edu (Aditya Dhananjay)
Date: Sat, 3 Nov 2012 22:23:11 +0000 (UTC)
Subject: [Click] Connect with me on LinkedIn
Message-ID: <939438445.25900091.1351981391172.JavaMail.app@ela4-app2313.prod>

LinkedIn
------------



I'd like to add you to my professional network on LinkedIn.

- Aditya

Aditya Dhananjay
Student at New York University
Greater New York City Area

Confirm that you know Aditya Dhananjay:
https://www.linkedin.com/e/-d8du0y-h93at9vh-3o/isd/9404889622/WR35Gb6A/?hs=false&tok=0Thw6a4eyvQRs1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-d8du0y-h93at9vh-3o/XMfEk5tPEWMkQOihgbxiv9n5pbKbMbjKdsBEnGl8Bo/goo/click%40amsterdam%2Elcs%2Emit%2Eedu/20061/I3144955478_1/?hs=false&tok=17iOBDi3ivQRs1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.


  

From zaykalov at gmail.com  Mon Nov  5 09:08:49 2012
From: zaykalov at gmail.com (Konstantin Zaykalov)
Date: Mon, 5 Nov 2012 14:08:49 +0000
Subject: [Click] kernel patching elimination
In-Reply-To: <CAFtVOqmSG7ueB6uxT5XVJT6VzTHsLiaao8j+zoT0DuBrE4Cp0Q@mail.gmail.com>
References: <CALdZA=WQ9o-U2YHJow-WJ7NHOtBsCS8zYwsDigeko5R=es36NQ@mail.gmail.com>
	<CAFtVOqmZHcP1Vw_TUOHk2jBjH93Jfe2AK=C6VQH22OtPHkSHwQ@mail.gmail.com>
	<CALdZA=V3HN8wJ3wiS5T0ZwXbM9XeVbcoxXN1cywKQyL3jDW2Pw@mail.gmail.com>
	<CAFtVOqmSG7ueB6uxT5XVJT6VzTHsLiaao8j+zoT0DuBrE4Cp0Q@mail.gmail.com>
Message-ID: <CALdZA=Uuyh1wJjJzyntAYL4pc451xP+Ki0YQ9AV+MyEy4qd9Lg@mail.gmail.com>

Hi Cliff,

Thank you for the hint - I have now noticed that Click should support
patchless install. This is exactly what I was looking for. It still fails
for me, but I'll figure it out.

Thanks!

Konstantin


On Fri, Nov 2, 2012 at 10:56 PM, Cliff Frey <cliff at meraki.com> wrote:

> Have you tried just building click on your system's kernel?  I believe
> that it works on all modern linux kernels.
>
> On Fri, Nov 2, 2012 at 4:42 AM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:
>
>> Hi Cliff,
>>
>> Thank you for such a detailed answer. The problem I see with Click at the
>> moment is that it is tied to a particular kernel version, the most recent
>> of which is 2.6.24.7, released in May 2008. So if I want to take advantage
>> of any recent feature of the kernel (such as ext4 filesystem, for
>> example),
>> I need to upgrade my kernel, but Click patch can prevent me from doing so.
>>
>>  If I ever make any changes to Click, I will definitely consider them to
>> be
>> contributed back to the community.
>>
>> There is one part of your answer I didn't quite undestand, though:
>>
>> >On many versions of modern linux, kernel patching is not required, so I'm
>> not sure what you want to change.
>>
>> Could you indicate, please, what are the versions of Linux, where kernel
>> patching is not required? It took me ages to find Linux version 2.6.24.7
>> (I
>> eventually had to use Wayback Machine @ web.archive.org to get it), so if
>> Click could work with modern Linux kernels without patching, it would be
>> great!
>>
>> Thanks again!
>>
>> Konstantin
>>
>>
>>
>>
>> On Thu, Nov 1, 2012 at 3:15 PM, Cliff Frey <cliff at meraki.com> wrote:
>>
>> > On Thu, Oct 25, 2012 at 5:22 AM, Konstantin Zaykalov <
>> zaykalov at gmail.com>wrote:
>> >
>> >> Hi,
>> >>
>> >> I've got a few questions regarding the design of Click router:
>> >> 1) Why does Click do kernel patching (and fixing include files via
>> >> fixincludes.pl script) for g++ compiler instead of providing wrapper
>> >> functions, surrounded by "extern "C" "? Or even some abstraction layer
>> >> written in C?
>> >>
>> >
>> > kernel patching works very well.  As Lars stated, it is not possible to
>> > directly include the kernel header files in a c++ file, for many
>> different
>> > reasons (the "::" operator, use of variables name "new", etc).  If an
>> > abstraction layer was written in C, it would need to abstract *all*
>> packet
>> > access, which means that reading or writing any packet data would
>> require
>> > an extra layer of function calls, which would likely affect performance.
>> >
>> >
>> >> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>> >>
>> >
>> > Depending on the version of linux, click will use many different hooks.
>> >  If you have a specific recommendation for something that would be
>> better
>> > than the current hooks, patches would be appreciated!
>> >
>> >
>> >> 3) Why doesn't Click use NAPI for device polling?
>> >>
>> >
>> > Ethernet drivers use NAPI.  Click is not an ethernet driver.  The
>> > "PollDevice" click element, which acts as an ethernet driver, was
>> written
>> > before NAPI existed.  It would probably be possible to build a high
>> > performance framework that gave packets directly to click by somehow
>> > leveraging NAPI like interfaces... it still might require compile time
>> > changes though.
>> >
>> > Basically I am looking into possibilities to eliminate kernel patching
>> >> altogether and make it more independent/standalone.
>> >>
>> >
>> > On many versions of modern linux, kernel patching is not required, so
>> I'm
>> > not sure what you want to change.  Also, click can be run at userlevel
>> in a
>> > very standalone fashion.
>> >
>> > Cliff
>> >
>> >
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>
>

From nsclick at gmx.de  Fri Nov  9 05:30:33 2012
From: nsclick at gmx.de (nsclick at gmx.de)
Date: Fri, 09 Nov 2012 11:30:33 +0100
Subject: [Click] ns3-click packet processing delay
Message-ID: <20121109103033.116120@gmx.net>

Hello,

has NS3-Click some type of packet processing delay implemented?
For example: If I have a click element which produces a huge amount of traffic, but the created packets will be discarded at the output of the element. Will this influence the simulation beside the usage of CPU time?

Thanks,

Thomas

From suresh.lalith at gmail.com  Fri Nov  9 05:41:14 2012
From: suresh.lalith at gmail.com (Lalith Suresh)
Date: Fri, 9 Nov 2012 11:41:14 +0100
Subject: [Click] ns3-click packet processing delay
In-Reply-To: <20121109103033.116120@gmx.net>
References: <20121109103033.116120@gmx.net>
Message-ID: <CAOj7qWakBov+==YRc=7RRSBQibFKDLUiKvXpmRyeUX-3Mx5EsQ@mail.gmail.com>

On Fri, Nov 9, 2012 at 11:30 AM,  <nsclick at gmx.de> wrote:
> Hello,
>
> has NS3-Click some type of packet processing delay implemented?
> For example: If I have a click element which produces a huge amount of traffic, but the created packets will be discarded at the output of the element. Will this influence the simulation beside the usage of CPU time?
>

ns-3 has no notion of processing delay as of now. There has been work
that has looked into it [1]. I've also seen researchers conduct
measurements of processing delays on their hardware, and artificially
adding these delays into ns-3's stack before conducting simulation
experiments.

[1] http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p418.pdf

> Thanks,
>
> Thomas
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click



--
Lalith Suresh
www.lalith.in

From nsclick at gmx.de  Fri Nov  9 07:41:00 2012
From: nsclick at gmx.de (nsclick at gmx.de)
Date: Fri, 09 Nov 2012 13:41:00 +0100
Subject: [Click] ns3-click packet processing delay
Message-ID: <20121109124100.274110@gmx.net>

> ns-3 has no notion of processing delay as of now. 

Thanks Lalith for the information.
My problem is that an element with the following code (for testing purposes) influences my simulation results. If I comment the lines for scheduling, the simulation results are ok.
How can the following code influence the simulation result? The only thing the code does is configuring the scheduler for the next event. But the code does not produce packets for the simulation.
Could someone explanin me how a code that only schedules itself can influence the simulation?


int Foo::initialize( ErrorHandler * )
{
	_timer.initialize( this );
	uint32_t start = ( random() % _period );
	_timer.schedule_after_msec( start );
	return 0;
}

void Foo::run_timer(Timer *)
{
	int period = ( int ) ( _period * .95 + ( random() % ( _period / 10 ) ) );
	_timer.reschedule_after_msec( period );
}

From suresh.lalith at gmail.com  Mon Nov 12 08:58:12 2012
From: suresh.lalith at gmail.com (Lalith Suresh)
Date: Mon, 12 Nov 2012 14:58:12 +0100
Subject: [Click] ns3-click packet processing delay
In-Reply-To: <20121109124100.274110@gmx.net>
References: <20121109124100.274110@gmx.net>
Message-ID: <CAOj7qWY6owNq6Z_de+pz0Cy+3kPBys2BjG3gQtGQ0sqABd8mWg@mail.gmail.com>

Hi again,

On Fri, Nov 9, 2012 at 1:41 PM,  <nsclick at gmx.de> wrote:
>> ns-3 has no notion of processing delay as of now.
>
> Thanks Lalith for the information.
> My problem is that an element with the following code (for testing purposes) influences my simulation results. If I comment the lines for scheduling, the simulation results are ok.
> How can the following code influence the simulation result? The only thing the code does is configuring the scheduler for the next event. But the code does not produce packets for the simulation.
> Could someone explanin me how a code that only schedules itself can influence the simulation?
>
>
> int Foo::initialize( ErrorHandler * )
> {
>         _timer.initialize( this );
>         uint32_t start = ( random() % _period );
>         _timer.schedule_after_msec( start );
>         return 0;
> }
>
> void Foo::run_timer(Timer *)
> {
>         int period = ( int ) ( _period * .95 + ( random() % ( _period / 10 ) ) );
>         _timer.reschedule_after_msec( period );
> }

The above snippet of code can end up changing the sequence of events
that arrive at ns-3's scheduler.

What I meant when I said that ns-3 does not model processing delay, is
that every packet is processed by an ns-3 node in 0.0 nanoseconds in
simulation time.

> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click



--
Lalith Suresh
www.lalith.in

From nsclick at gmx.de  Mon Nov 12 09:47:06 2012
From: nsclick at gmx.de (nsclick at gmx.de)
Date: Mon, 12 Nov 2012 15:47:06 +0100
Subject: [Click] ns3-click packet processing delay
Message-ID: <20121112144706.30430@gmx.net>

> 
> Hi again,
> 
> On Fri, Nov 9, 2012 at 1:41 PM,  <nsclick at gmx.de> wrote:
>>> ns-3 has no notion of processing delay as of now.
>>
>> Thanks Lalith for the information.
>> My problem is that an element with the following code (for testing purposes) influences my simulation results. If I comment the lines for scheduling, the simulation results are ok.
>> How can the following code influence the simulation result? The only thing the code does is configuring the scheduler for the next event. But the code does not produce packets for the simulation.
>> Could someone explanin me how a code that only schedules itself can influence the simulation?
>>
>>
>> int Foo::initialize( ErrorHandler * )
>> {
>>         _timer.initialize( this );
>>         uint32_t start = ( random() % _period );
>>         _timer.schedule_after_msec( start );
>>         return 0;
>> }
>>
>> void Foo::run_timer(Timer *)
>> {
>>         int period = ( int ) ( _period * .95 + ( random() % ( _period / 10 ) ) );
>>         _timer.reschedule_after_msec( period ); }

>The above snippet of code can end up changing the sequence of events that arrive at ns-3's scheduler.

>What I meant when I said that ns-3 does not model processing delay, is that every packet is processed by an ns-3 node in 0.0 nanoseconds in simulation time.


If my scheduled dummy events (which do nothing) change the sequence of events arriving in the ns-3 scheduler and an event is processed in 0.0 nanoseconds in ns-3, then the other events are not delayed, aren't they?

If I have three events A, B, and C and my code snippet will produce the events Y and Z. All events will be scheduled to the same time, e.g. 150 seconds. Could this change the processing order of A,B,C to C,A,B for example?

I also recognized that if I add some dummy-events at 150 seconds of simulation time, also the simulation results before 150 seconds will change. How can this be?

From martindam at berkeley.edu  Fri Nov 16 11:51:47 2012
From: martindam at berkeley.edu (MARTIN DAM)
Date: Fri, 16 Nov 2012 08:51:47 -0800
Subject: [Click] ToDevice doesn't work when FromDevice is initialized
Message-ID: <CANYq72UKaVdHVq9HSJKAz=TzsTupZ4RHqBXr3OyCkcoem0_a+Q@mail.gmail.com>

Hi Click mailing list

I am having some problems with the ToDevice element after I enabled IPv6
(./configure --enable-local --enable-ip6). I tried going back and build
without IPv6 but still didn't work.
If FromDevice and ToDevice is in the same configuration for the same
interface, ToDevice does not emit any packets. It does consume them in
click, but they never appear on the interface.

I tested with a packet dump, and just feed the packet directly into
ToDevice (without initializing FromDevice) and it worked perfectly. But
when FromDevice is initialized, it stops working. See configuration below.
When the second line is removed, it emits packets to the interface.

FromDump('test.pcap') -> Queue -> Print('Output') -> ToDevice(eth0);
FromDevice(eth0) -> Print('Input') -> Discard;

Any idea how to fix this?

Regards
Martin

Ps. A great piece of software you guys created here!

PPs. My system info: Linux q-ultra 3.2.0-32-generic #51-Ubuntu SMP Wed Sep
26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

From giorgio.calarco at unibo.it  Sat Nov 17 06:48:26 2012
From: giorgio.calarco at unibo.it (Giorgio Calarco)
Date: Sat, 17 Nov 2012 12:48:26 +0100
Subject: [Click] ToDevice doesn't work when FromDevice is initialized
In-Reply-To: <CAOCbBQMVxXU4iOCr8pojiP0BuShsbJO8gXsNSEF7H6ne6MqMRQ@mail.gmail.com>
References: <CANYq72UKaVdHVq9HSJKAz=TzsTupZ4RHqBXr3OyCkcoem0_a+Q@mail.gmail.com>
	<CAOCbBQMVxXU4iOCr8pojiP0BuShsbJO8gXsNSEF7H6ne6MqMRQ@mail.gmail.com>
Message-ID: <CAOCbBQNVKLp2Ja5KUJ+Dh6mJhRzfp6=sX_JeQ9j4EDEzdwWjMA@mail.gmail.com>

Well, it sounds similar to a problem I encountered some time ago. Try like
this: the FromDevice "method" parameter, try setting it explicitly, e.g.
start with "method LINUX", the default is PCAP and not working on 3.x
kernels (the method which should be called to send a packet  seems to be
compiled correctly, but it is skipped instead, since it is silently
substituted at configure time by a fake method which just returns - check
the configure logs file to accertain this). Ah, yes, if I remember
correctly,ToDevice inherits the method parameter from the corresponding
ToDevice, so you shouldn't need to declare the method there.

Hope this helps.
Cheers,
Giorgio


> Il giorno 16/nov/2012 18:03, "MARTIN DAM" <martindam at berkeley.edu> ha
scritto:
>
> Hi Click mailing list
>
> I am having some problems with the ToDevice element after I enabled IPv6
> (./configure --enable-local --enable-ip6). I tried going back and build
> without IPv6 but still didn't work.
> If FromDevice and ToDevice is in the same configuration for the same
> interface, ToDevice does not emit any packets. It does consume them in
> click, but they never appear on the interface.
>
> I tested with a packet dump, and just feed the packet directly into
> ToDevice (without initializing FromDevice) and it worked perfectly. But
> when FromDevice is initialized, it stops working. See configuration below.
> When the second line is removed, it emits packets to the interface.
>
> FromDump('test.pcap') -> Queue -> Print('Output') -> ToDevice(eth0);
> FromDevice(eth0) -> Print('Input') -> Discard;
>
> Any idea how to fix this?
>
> Regards
> Martin
>
> Ps. A great piece of software you guys created here!
>
> PPs. My system info: Linux q-ultra 3.2.0-32-generic #51-Ubuntu SMP Wed Sep
> 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

From antoniehenning at yahoo.com  Sat Nov 17 10:53:39 2012
From: antoniehenning at yahoo.com (Antonie Henning)
Date: Sat, 17 Nov 2012 07:53:39 -0800 (PST)
Subject: [Click] ToDevice doesn't work when FromDevice is initialized
In-Reply-To: <CAOCbBQNVKLp2Ja5KUJ+Dh6mJhRzfp6=sX_JeQ9j4EDEzdwWjMA@mail.gmail.com>
References: <CANYq72UKaVdHVq9HSJKAz=TzsTupZ4RHqBXr3OyCkcoem0_a+Q@mail.gmail.com>
	<CAOCbBQMVxXU4iOCr8pojiP0BuShsbJO8gXsNSEF7H6ne6MqMRQ@mail.gmail.com>
	<CAOCbBQNVKLp2Ja5KUJ+Dh6mJhRzfp6=sX_JeQ9j4EDEzdwWjMA@mail.gmail.com>
Message-ID: <1353167619.89289.YahooMailNeo@web125301.mail.ne1.yahoo.com>

Had a similar issue recently and was resolved by adding "method LINUX" in the ToDevice element.


________________________________
 From: Giorgio Calarco <giorgio.calarco at unibo.it>
To: MARTIN DAM <martindam at berkeley.edu> 
Cc: "click at pdos.csail.mit.edu" <click at pdos.csail.mit.edu> 
Sent: Saturday, November 17, 2012 1:48 PM
Subject: Re: [Click] ToDevice doesn't work when FromDevice is initialized
 
Well, it sounds similar to a problem I encountered some time ago. Try like
this: the FromDevice "method" parameter, try setting it explicitly, e.g.
start with "method LINUX", the default is PCAP and not working on 3.x
kernels (the method which should be called to send a packet? seems to be
compiled correctly, but it is skipped instead, since it is silently
substituted at configure time by a fake method which just returns - check
the configure logs file to accertain this). Ah, yes, if I remember
correctly,ToDevice inherits the method parameter from the corresponding
ToDevice, so you shouldn't need to declare the method there.

Hope this helps.
Cheers,
Giorgio


> Il giorno 16/nov/2012 18:03, "MARTIN DAM" <martindam at berkeley.edu> ha
scritto:
>
> Hi Click mailing list
>
> I am having some problems with the ToDevice element after I enabled IPv6
> (./configure --enable-local --enable-ip6). I tried going back and build
> without IPv6 but still didn't work.
> If FromDevice and ToDevice is in the same configuration for the same
> interface, ToDevice does not emit any packets. It does consume them in
> click, but they never appear on the interface.
>
> I tested with a packet dump, and just feed the packet directly into
> ToDevice (without initializing FromDevice) and it worked perfectly. But
> when FromDevice is initialized, it stops working. See configuration below.
> When the second line is removed, it emits packets to the interface.
>
> FromDump('test.pcap') -> Queue -> Print('Output') -> ToDevice(eth0);
> FromDevice(eth0) -> Print('Input') -> Discard;
>
> Any idea how to fix this?
>
> Regards
> Martin
>
> Ps. A great piece of software you guys created here!
>
> PPs. My system info: Linux q-ultra 3.2.0-32-generic #51-Ubuntu SMP Wed Sep
> 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> _______________________________________________
> 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 giorgio.calarco at unibo.it  Sat Nov 17 11:38:08 2012
From: giorgio.calarco at unibo.it (Giorgio Calarco)
Date: Sat, 17 Nov 2012 17:38:08 +0100
Subject: [Click] ToDevice doesn't work when FromDevice is initialized
In-Reply-To: <1353167619.89289.YahooMailNeo@web125301.mail.ne1.yahoo.com>
References: <CANYq72UKaVdHVq9HSJKAz=TzsTupZ4RHqBXr3OyCkcoem0_a+Q@mail.gmail.com>
	<CAOCbBQMVxXU4iOCr8pojiP0BuShsbJO8gXsNSEF7H6ne6MqMRQ@mail.gmail.com>
	<CAOCbBQNVKLp2Ja5KUJ+Dh6mJhRzfp6=sX_JeQ9j4EDEzdwWjMA@mail.gmail.com>
	<1353167619.89289.YahooMailNeo@web125301.mail.ne1.yahoo.com>
Message-ID: <CAOCbBQM790kLQjbhPgqW_9HyvoSDaW=FKnkf-zCWwsEXnu0fJA@mail.gmail.com>

I forgot to mention that obviously if you use "method LINUX" you packets
will be crossing the kernel networking layers, with different
forwarding.performance.
Giorgio

Il giorno 17/nov/2012 16:53, "Antonie Henning" <antoniehenning at yahoo.com>
ha scritto:

Had a similar issue recently and was resolved by adding "method LINUX" in
the ToDevice element.

  ------------------------------
*From:* Giorgio Calarco <giorgio.calarco at unibo.it>
*To:* MARTIN DAM <martindam at berkeley.edu>
*Cc:* "click at pdos.csail.mit.edu" <click at pdos.csail.mit.edu>
*Sent:* Saturday, November 17, 2012 1:48 PM
*Subject:* Re: [Click] ToDevice doesn't work when FromDevice is initialized


Well, it sounds similar to a problem I encountered some time ago. Try like
this: the FromDevice "me...

From sombrutz at informatik.hu-berlin.de  Mon Nov 19 10:17:24 2012
From: sombrutz at informatik.hu-berlin.de (Robert Sombrutzki)
Date: Mon, 19 Nov 2012 16:17:24 +0100
Subject: [Click] FilterFailures
Message-ID: <201211191617.24838.sombrutz@informatik.hu-berlin.de>

Hi,
this patch decreases the number of possible output ports of FilterFailures to 
2, since this is the maximum number of used port in 
elements/wifi/filterfailures.cc.

Best regards
Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-FilterFailures-fix-port_count-port-3-is-never-used.patch
Type: text/x-diff
Size: 889 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20121119/314dfa86/attachment.patch 

From zaykalov at gmail.com  Mon Nov 19 10:33:05 2012
From: zaykalov at gmail.com (Konstantin Zaykalov)
Date: Mon, 19 Nov 2012 15:33:05 +0000
Subject: [Click] click 2.0.1 compatible kernel
Message-ID: <CALdZA=U5wT8nYUActsGqCbFSFfZk8FZgP5NTyrYkFioMo44eLw@mail.gmail.com>

Hi,

An easy question (hopefully): when click 2.0.1 was released - against which
version of linux kernel was it tested? I.e. what is the latest kernel
version that click 2.0.1 was tested against? Also what version of gcc was
used?

Thank you,

Konstantin