8.8 Exercises 195 Dynamic compilation at the time of the CSPF design was probably slow and also not portable across systems; the gains at that time would have also been marginal because of other bottlenecks. However, by the time DPF was being designed, a number of systems, including VCODE [Eng96], had designed fairly fast and portable dynamic compilation infrastructure. The other classifier implementations in DPF's lineage had also eliminated other bottlenecks, which allowed the benefits of dynamic compilation to stand out more clearly. 8.7 CONCLUSIONS While it may be trite to say that necessity is the mother of invention, it is also often true. New needs drive new innovations; the lack of a need explains why innovations did not occur earlier. The CSPF filter was implemented when the major need was to avoid a process context switch; having achieved that, improved filter performance was only a second-order effect. BPF was implemented when the major need was to implement a few filters very efficiently to enable monitoring tools like tcpdump to run at close to wire speeds. Having achieved that, scaling to a large number of filters seemed less important. Pathfinder was implemented to support user-level networking in the x-kernel [HP91], and to allow Scout [MP96] to use paths as a first-class object that could be exploited in many ways. Having found a plausible hardware implementation, perhaps improved software perfor- mance seemed less important. DPF was implemented to provide high-performance networking together with complete application-level flexibility in the context of an extensible operating system [EKO95]. Figure 8.2 presents a summary of the techniques used in this chapter, together with the major principles involved. As in the H. G. Wells quote at the start of the chapter, the DPF species does represent the accumulation of the experiments of all its successful individuals. All filter implementations