A systematic Characterization of Application Sensitivity to Network Performance

104
SPINE I/O 
Runtime
Extension
Router
LANai
Card
Router Application
Network
Kernel
Stack
SPINE I/O 
Runtime
Extension
Router
2
3
4
5
6
1
7
Network
Kernel
User
Kernel Runtime
SPINE 
LANai
Card
8
I/O Bus
Network
Wire
Wire
Figure 6.3: SPINE IP Router Architecture
This figure shows the SPINE IP router architecture. In the common case, IP packets move directly
between LANai cards, bypassing the main CPU completely.
router is a better example of both the benefits and dangers of the overhead reduction techniques of
the SPINE approach.
6.2.1
Architecture
The SPINE system structure is illustrated in Figure 6.3. Programming re-programmable
adapters requires operating system support both on the host and on the LANai processor. A small
set of core interfaces defines the SPINE run-time. These are implemented in C, and provide a basic
execution environment (e.g. an operating system) to SPINE extensions. In a nutshell, SPINE exten-
sions are application defined code to be loaded onto the network adapter. Extensions are realized as
sets of Modula-3 procedures that have access to the interfaces defined by the SPINE run-time. In
our case, the extensions implement IP router code.
The run-time interfaces exported to extensions include support for messaging, safe access
to the underlying hardware (e.g., DMA controllers), and a subset of the Modula-3 interface. The
interface also consists of message FIFOs that enable user-level applications, peer devices, and ker-

---

105
nel modules to communicate with extensions on the network adapter using an active message style
communication layer.
User-level applications inject extensions onto the adapter using SPINE’s dynamic linker,
and send messages directly to extensions via a memory mapped FIFO using SPINE’s communication
library. The kernel run-time currently works in the context of Linux and Windows NT.
A Message-Driven Architecture
The primary purpose of a network adapter is to move messages efficiently between the
system and the network media. The network adapter’s basic unit of work is thus a message. To ef-
ficiently schedule messages and the associated message processing, the SPINE I/O run-time uses
a message driven scheduling architecture, rather than the process or thread-oriented scheduling ar-
chitecture found in conventional operating systems. The primary goal is to sustain three forms of
concurrent operation: host-to-adapter message movement, message processing on the adapter, and
adapter-to-network message movement.
Maximizing the number of concurrent operations is our attempt to maximize the effec-
tive bandwidth. If we blocked on each data-movement operation, each DMA engine in the LANai
would see a lower effective bandwidth as it would have to “wait its turn” behind other units. In the
pipelining context, we are thus attempting to maximize the effective
ü
term at the cost of increased
occupancy. The increase in occupancy arises because of the overhead in managing as many concur-
rent operations as possible. We will see the result of this tradeoff in the next section. Briefly, we see
that occupancy of the I/O processor can result in a serious performance limitation.
In SPINE the message dispatcher manages these concurrent operations. A re-programmable
network adapter not only moves data; it reacts and applies transformations to it as well. On message
arrival, the adapter may have to operate on the data in addition to moving it. This style of processing
is captured well by the Active Message programming model, which we use to program SPINE exten-
sions on the network adapter. Every message in the system is an active message. SPINE extensions
are thus expressed as a group of active message handlers. On message arrival, the SPINE dispatcher
can route messages to the host, a peer device, over the network, or invoke an active message handler
of a local SPINE extension.
As Figure 6.3 shows, the I/O run-time is a glorified message multiplexor, managing the
movement of messages between input queues from the host, the network, and peer LANai cards to the
various output queues. The key difference in the SPINE architecture from other fast message and I/O

---

106
processing schemes is that extensions provide a safe way for the user to program the interpretation
and movement of messages from any of these sources.
The two goals of handler execution, in order to determine the correct action for each mes-
sage, and rapid message flow implies that handlers must be short-lived. Thus, the contract between
the SPINE run-time and extension handlers is that the handlers are given a small, but predictable
time to execute. If a handler exceeds the threshold it is terminated in the interests of the forward
progress of other messages. Long computations are possible, but must be expressed as a sequence
of handlers. The premature termination of handlers opens a Pandora’s box of safety issues. We do
not describe these issues in this thesis, as they are tangential to the investigation of host-overhead
reduction. The reader is referred to [40] for a complete treatment of the resulting operating systems
issues.
To increase the amount of pipelining in the system, message processing is broken up into
a series of smaller events. These events are internally scheduled as active messages, which invoke
system provided handlers. Thus, only a single processing loop exists; all work is uniformly imple-
mented as active messages. We document the performance of these internal messages, and thus the
throughput and latency of the SPINE I/O run-time, in the next section.
Returning to Figure 6.3 we can trace the execution of events in the SPINE IP router. The
sequence of events needed to route an IP packet from one adapter to another are:
1. The router application communicates with the SPINE kernel run-time to obtain a queue into
the I/O run-time running on the LANai card.
2. The router application loads the router extension onto the LANai and then loads the IP routing
tables onto the extension.
3. As a packet arrives from the wire, the hardware network DMA engine spools it to card-memory.
The I/O run-time polls a set of software events; one of which polls a hardware event register.
When the packet arrives, the head of the message specifies it is for the IP router extension.
4. The I/O run-time calls the router extension receive event. If no router extension is loaded, the
run-time drops the packet.
5. After looking up the destination LANai of the packet, the router extension calls into the I/O
run-time to send the packet to the output queue on the correct LANai card.

---