[Click] extending simple_action() to multiple ports

[Jesse Brown]

Hi Ian,

I originally came across this issue trying to support something similar 
to your first two examples (uniform behavior over multiple classes of 
traffic). I never considered the impact of having to write handlers (as 
I wasnt using them) or the benefit that other elements might get from a 
similar change - thanks for considering the option further.

To address your example of the Counter element there could be a similar 
AggregateCounter element (or an AGGREGATE argument). Although, the 
impact depends on the number of elements that would need this change and 
I have an admittedly limited view into the most used elements overall.


Jesse

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
>
> 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
>
>