|
|
Performance analysis has shown that it is theoretically possible to saturate an Ethernet using 1500-byte packets with any kind of 16-bit card that allows send-ahead.
The send-ahead algorithm, called frame pre-loading, involves loading frames onto the adapter while it is transmitting. As a point of comparison, most 32-bit adapters have send-ahead/frame pre-loading inherent in their interfaces.
Frame Pre-loading works in the following way. Multiple transmit buffers are allocated in a manner specific to the network adapter being used. If two buffers are used, they are filled alternately, so that while the adapter transmits buffer #1, buffer #2 is being filled. The two buffers then reverse roles, and so on for each subsequent frame.
An additional modification to transmit-side processing is to eliminate the write service routine, and service the queue at transmit complete time. This technique is called Service From Interrupt. The reason for eliminating the service routine is that there is a delay between the point that the intr(D2mdi) routine calls qenable(D3str) and the point that the STREAMS scheduler calls the uwsrv( ) routine. The length of delay depends on the amount of STREAMS processing queued up. Even in a system with no other activity, there is a small delay attributable to streams scheduling overhead. Even this small delay can be significant in the case of a 16-bit adapter running on a slow machine. In this case, there might not be enough time to get the next frame pre-loaded before the next transmit complete interrupt comes in. In this case, the driver will not be able to achieve/sustain maximum media throughput.
Service From Interrupt has a clear performance advantage over streams service routine scheduling, but it is up to the device driver writer to weigh the benefits against the impact to overall system performance.
Frame Pre-Loading with Service From Interrupt works as follows. When a transmit complete interrupt occurs, the interrupt routine first checks whether there is a buffer pre-loaded. If so, the buffer is transmitted. The interrupt routine then attempts to de-queue messages from the write queue of the MDI driver and loads them onto the adapter.
The following diagram illustrates a processing algorithm which includes both frame pre-loading and service from interrupt. Note that the routine names XXdequeue( ) and XXhwput( ) are generic names used to refer to driver-specific sub-routines or tasks that are assumed to exist in any given driver, implemented with any collection of routines (in other words, the names dequeue and hwput are just examples, not reserved keywords). The dequeue( ) task is assumed to dequeue and process pending frames, and the processing logic denoted by hwput( ) is assumed to deliver a frame to the network device in a manner specific to the particular hardware.
Frame pre-loading/service from interrupt