Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-08-31
2004-05-25
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06742051
ABSTRACT:
BACKGROUND
1. Field of the Invention
This invention relates generally to data communications between a device and a network. In particular, the present invention relates to software interfaces configured to enable an increase in the speed of data communications between a device and a network.
2. Description of the Related Art
In conventional networks, the various devices on the network are virtualized into a set of start and/or end points (nodes) for data messages transferred over the network. The network has a switching fabric consisting of routers, switches, etc., which provides the logical communication links between the nodes on the network. Each node has a hardware device, typically a network interface controller (NIC), acting as the communications intermediary between the node and the network. The NIC merely passes data to and from the network in the speed and manner required by the switching fabric and is thus usually categorized by the nature of the network with which it is compatible. For example, Ethernet NICs, the most common form of network adapters, can transfer data at rates of 10 megabytes per second, 100 megabytes per second, or one gigabyte per second. The NIC does not control, distinguish or review the data being passed. Instead, a layered stack of software in each device controls the communications between the resources in the device and the network. In a computer server, there may be a large amount of data storage and communications functionality and the demand for access to the hardware device may be complex.
The communications path of a typical device
100
is illustrated in FIG.
1
. As shown, an Ethernet NIC
101
interacts strictly with the network and with device driver
102
of node
100
. The device driver
102
is a dedicated piece of software that controls the lowest level functions of Ethernet NIC
101
. Device driver
102
is strictly connected to a transport
103
, which in turn is strictly connected to a transport interface
104
. The transport interface
104
is typically a module of an operating system (OS) which controls and multiplexes direct access by software processes to transport
103
. The software stack, especially in the instance of a server, can be quite complex. The software stack implements transport and other protocols (e.g., TCP, IP) at various levels to render communications over the network switching fabric more reliable. The multiplexing and demultiplexing processes and the reliability protocols are computationally expensive. Most conventional communication operations result in buffer copies being made at multiple levels or layers, mode switches and context switches. Moreover, many user application software programs utilize methods which inevitably slow down communications. As shown in
FIG. 2
, the amount of time required to transfer data between nodes on a high speed network is affected much more by the time it takes to execute all of the layers in the software protocol stack than by the time taken by the hardware to transfer the data. As shown by
FIG. 2
, with the advent of gigabit ethernet, the overwhelming obstacle to high speed performance is the execution of the software protocol stack rather than the hardware in the network adapter cards.
The example embodiment of the invention seeks to increase the speed of data communications over the network by decreasing the execution time of the software protocol stack. One particular concern is the synchronous application programming interface (API) calls in user applications that block (wait) for operation completion, either in client-server or peer-peer communication. While some user application support asynchronous operations, they make extensive use of callbacks, which offer a convenient way for applications to be notified when an event of interest occurs. However, certain properties of callbacks manifest themselves into serious issues when trying to decrease execution time of the software. Examples of such properties include:
1. Time restriction on callback thread to prevent starvation of other clients that have registered for a callback.
2. Each asynchronous event notification requires registering for a callback. Bundling multiple async event notifications in one callback is not easily possible. This limits scalability since performance is adversely affected as the number of async operations requiring callbacks increases.
3. Supporting callback mechanisms complicates the architecture of the interface provider.
While such callbacks may be acceptable in user space, doing so in the kernel would waste precious CPU cycles adversely impacting system performance as well as scalability. Therefore, a need exists for a completely asynchronous interface to the hardware device responsible for handling communication and error reporting without using callbacks.
SUMMARY
The present invention is directed to a software interface. In an example embodiment, an interface is provided between a software application and a hardware device transferring data between the software application and a network. The interface posts a request from the software application and, in response to a polling inquiry received from the software application, determines whether or not an event signal corresponding to the request has been provided to it from the hardware device. The interface carries out a rearm routine if an event signal has not been provided at the time of the polling inquiry. A second polling inquiry is made by the software application after the interface is rearmed and the interface determines whether or not an event signal has been provided to it by the hardware device. The interface then carries out a wait routine which waits for the event signal if an event signal was not provided at the time of the second polling inquiry.
REFERENCES:
patent: 5659794 (1997-08-01), Caldarale et al.
patent: 6131118 (2000-10-01), Stupek, Jr. et al.
patent: 6157965 (2000-12-01), Mohammed et al.
-Helmy “Protocol Independent Multicast-Sparse Model (PIM-SM): Implementation Document”, Computer Science Department/ISI, University of South California, Jan. 19, 1997. pp. 1-18.*
Virtual Interface Architecture Specification, Version 1.0 Dec. 16, 1997; pp. 1-83.
Bakshi Bikram Singh
Berry Frank L.
Deleganes Ellen
Gronke Ed
Follansbee John
Kacvinsky John F.
Nguyen V. H.
LandOfFree
Kernel interface does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Kernel interface, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Kernel interface will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3226521