Design and Implementation of TinyGALS: A Programming Model for ...

pull() method of Null calls pull() on its input port, which calls the pull() method
of the Queue. The Queue element dequeues the packet and returns it through the return of
the pull() calls.
Overhead in Click Modularity in Click results in two main sources of overhead. The first
source of overhead comes from passing packets between elements. This causes one or two
virtual function calls, which involves loading the relevant function pointer from a virtual
function table, as well as an indirect jump through that function pointer. This overhead is
avoidable – the Click distribution contains a tool to eliminate all virtual function calls from
a Click configuration. The second source of overhead comes from unnecessarily general
element code. The authors of [25] found that element generality had a relatively small
effect on Click’s performance since not many elements in a particular configuration offered
much opportunity for specialization.
Comparison of Click to TinyGALS An element in Click is comparable to a component
in TinyGALS in the sense that both are objects with private state. Rules in Click on con-
necting elements together are similar to those for connecting components in TinyGALS
– push outputs must be connected exactly once, but push inputs may be connected more
than once (see Sections 2.3.3 and 3). Both types of objects (Click elements and TinyGALS
components) communicate with other objects via method calls. In Click, there is no funda-
mental difference between push processing and pull processing in Click at the method call
level of view; they are sets of method calls that differ only in name. However, the direction
of control flow with respect to data flow in the two types of processing are opposite of
each other. Push processing can be thought of as event-driven computation (if we ignore
the polling aspect of Click), where control and data flow downstream in response to an
upstream event. Pull processing can be thought of as demand-driven computation, where
control flows upstream in order to compute data needed downstream.
Figure 24 helps to provide a more detailed analysis of the difference in control and data
51