Name: Execution environments
WP Leader: SICS
Participants: SICS 18 mm, INRIA 3 mm, UTS 4 mm, UCL 3 mm
The aim of this package is to investigate execution
environments for integrated protocol implementations
generated by a compiler to be designed in other workpackages.
By such an environment we mean services common to protocol
processing, such as buffer manager, event handler, name server,
interfaces to the host machine and applications and a library of
ILP/ALF functions. Of paramount importance is that the
environment is efficiently implemented, at least for the so called
common path[2]. A fundamental research issue in ILP is how to
avoid unnecessary moving of data, that is, how to move the right
amount data into the right place at the right time for processing.
This is central in this workpackage. Many of today's workstations
consist of a multiprocessor system with a
small number of processors, therefore we will focus on
environments that exploit shared memory, multiprocessor
machines.
Parallel processing of ILP/ALF messages seems to be a promising combination. ILP can substantially reduce processing time for one message while parallel processing of messages may increase the number of messages processed for an application. These two architectural approaches are orthogonal to each other and may very well create a synergy effect, since ILP and ALF will make messages more independent of each other. Increased independence means an increased potential for parallel processing. We have recently done some work on protocols implemented on multiprocessors [11]. A "processor-per-message" allocation paradigm is used for partitioning the processing on a general available shared memory multiprocessor machine (Sequent Symmetry) and equally available software (the xkernel protocol execution environment in user address space). For TCP/IP/Ethernet driver we have measured a speedup of more than three times compared to the traditional sequential implementation, thereafter locking and machine contention effects put a limit on the increase. This software testing will be used for experiments on the combination of the approaches.
In order for ILP to be feasible the architecture seems to require
non-multiplexing of application streams and knowledge about the
applications address spaces. In previous work we designed
a driver, based on the so called "non-copy principle", a single
multiplexing point and ALF [14]. The driver can copy data directly
between an ATM network interface and application address spaces,
bypassing the time consuming copying to and from operating
system buffers. This will make it feasible to implement the
environment in user address space.
ORL will probably use the application execution environment quite widely, but within this workpackage, the specific deliverable is a `name server' in the broadest sense. That is, an object and naming and resource allocation server which supports the enhanced services specified in workpackage A.
We have identified four related tasks: