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 > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
