[Click] extending simple_action() to multiple ports

[Eddie Kohler]

Hey,

More cleanup:

On 05/03/2010 11:37 AM, Ian Rose wrote:
> Howdy -
>
> A few months ago there was an email to the list concerning (in part) the
> fact that simple_action always operates on input port 0 (when pulling)
> and output port 0 (when pushing):
>
> http://pdos.csail.mit.edu/pipermail/click/2010-March/008810.html
>
> Eddie pointed out that there were very few existing N-to-N elements
> where packets entering on port i exit only on port i, and since these
> are essentially the only kinds of elements that would benefit from the
> proposed change to simple action, the code would be left as-is.
>
> At the time this logic seemed reasonable to me, but now I am beginning
> to think that maybe simple_action *should* be changed as proposed
> (namely, input and output ports should match).  AND a number of existing
> elements could be changed to N-to-N in order to make use of this.
>
> For example:
>
> all of the Counter elements can be used to count the sum of multiple
> independent packet flows

I am convinced.  The necessary change to the Click core and devirtualizer is 
committed.  I'd be happy to look at patches for Counter, etc.  Thanks!

Eddie



> many of the Timestamp and TCP/IP Measurement elements can be used to
> monitor multiple independent packet flows
>
> many modification elements (e.g. RandomBitErrors, EtherEncap,
> IPsecEncap, Paint, etc.) can be used to modify multiple packet flows -
> although you can of course do this with 1 element per flow, the
> advantage to using a single element is that it can simplify code,
> especially handlers (e.g. just 1 write handler call to change some
> property, rather than N write handlers - 1 per flow)
>
>
> Its certainly possible to accomplish all of these currently, but its not
> always very clean.  For example, Paint and PaintSwitch can be used to
> mux and demux multiple streams, but that assumes that there is a free
> annotation byte somewhere that you can use on ALL input packets.  And
> this combo only works in a push context - in pull contexts you'd have to
> use N CheckPaint elements in a chain (one per packet stream - yuck).
>
> The one downside that I can think of is that things will appear slightly
> more complex for new users.  Currently the fact that Counter (for
> example is a 1-to-1 make sense to a new user - if instead Counter is an
> N-to-N, the reason for that takes a bit longer to understand.
>
> Thoughts?
> - Ian
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click