Method, system, and article of manufacture for mapping programming interfaces

Provided are a method, system, and article of manufacture for mapping programming interfaces. A synchronous request for reading data is received. An asynchronous request to fill selected buffers of a plurality of buffers is sent. The synchronous request is responded to with the data from at least one buffer of the plurality of buffers.

BACKGROUND

In software systems that support an asynchronous application programming interface (API), an application may issue an asynchronous read request and perform other tasks. While executing the other tasks, the application may be notified that the data corresponding to the asynchronous read request is available. The application may then retrieve the data.

In software systems that support a synchronous API, an application may issue a synchronous read request. If the data corresponding to the synchronous read request is not currently available, then the application may enter into a wait state in which no other task is performed by the application. After being notified that the data corresponding to the synchronous read request is available, the application may retrieve the data and exit from the wait state.

Synchronous and asynchronous APIs may be used to issue other requests that are different from read requests, such as, write requests, append requests, delete requests, other Input/Output (I/O) requests, etc. If the request is asynchronous then the calling application does not wait while the request is pending, whereas if the request is synchronous then the calling application waits while the request is pending.

DETAILED DESCRIPTION

Certain embodiments provide a mapping application that maps synchronous API calls to asynchronous API calls. In certain embodiments, a first application may generate a synchronous read request and the mapping application may map the synchronous read request to an asynchronous read request directed towards a network stack. The mapping application may use the asynchronous read request to fetch an additional amount of data from the network stack that is more than the amount of data requested by the first application. Subsequent read requests from the first application may be responded to from the mapping application from the additional amount of data that may have already been fetched.

FIG. 1illustrates a computing environment100, in accordance with certain embodiments. A computational platform102is coupled to a network104via a network interface106. The computational platform102may send and receive packets from other devices (not shown) through the network104.

The computational platform102may be any suitable device including those presently known in the art, such as, a personal computer, a workstation, a server, a mainframe, a hand held computer, a palm top computer, a telephony device, a network appliance, a blade computer, a storage server, etc. The network104may comprise the Internet, an intranet, a Local area network (LAN), a Storage area network (SAN), a Wide area network (WAN), a wireless network, etc. The network104may be part of one or more larger networks or may be an independent network or may be comprised of multiple interconnected networks. The network interface106may send and receive packets over the network104. In certain embodiments the network interface106may include a network adapter.

In certain embodiments, the computational platform102may comprise a first application, such as, a legacy application108, a second application, such as, a mapping application110, and a network stack112for communication with the network interface106.

The legacy application108may provide support for synchronous APIs via a synchronous API support module114that may support socket APIs for network communications. The legacy application108does not provide support for asynchronous APIs. After generating a synchronous API call, the legacy application108that uses the synchronous API support module114waits until the response to the synchronous API call is made available to the legacy application108, i.e., a thread in the legacy application that generates the synchronous API call cannot perform any other task while the thread waits.

In certain embodiments, the mapping application110receives a synchronous API call from the legacy application108and maps the synchronous API call to an asynchronous API call for the network stack112and proceeds to perform other tasks. If the synchronous API call is a synchronous read request, then the mapping application110responds to the synchronous read request with the corresponding data.

In certain embodiments, where the network interface106is a network adapter, the network stack112may provide an interface for allowing communications through the network adapter. The network stack112may provide support for asynchronous APIs via an asynchronous API support module116that supports socket APIs for network communications. Applications that call the network stack112asynchronously may be able to utilize the support for asynchronous processing provided by the network interface106corresponding to the network stack112. In certain embodiments, support for asynchronous APIs may increase the performance of the computational platform102as asynchronous processing allows the calling application to perform other tasks without waiting for a response.

FIG. 1illustrates certain embodiments in which even though the network stack112provides support for asynchronous APIs, the legacy application108is unable to directly use the support for asynchronous APIs as the legacy application108supports synchronous APIs. The mapping application110maps the synchronous APIs of the legacy application108to the asynchronous APIs of the network stack112. The asynchronous API support provided by the network stack112is exploited by the mapping application110.

FIG. 2illustrates the mapping of synchronous read requests to asynchronous read requests in the computing environment100ofFIG. 1, in accordance with certain embodiments.

The mapping application110includes a plurality of buffers200, such as, buffers200a,200b,200c,200d,200e, . . . ,200m,200n. A buffer may be capable of storing a certain number of bytes of data. For example, buffer200amay be capable of storing 512 bytes of data. One buffer of the plurality of buffers200is designated as a primary buffer. For example, inFIG. 2buffer200bis designated as an exemplary primary buffer202. The buffer designated as the primary buffer is the first buffer whose data is returned by the mapping application110to the legacy application108, in response to a read request from the legacy application108. The buffers200may be arranged in sequence, such as200a,200b,200c,200d, . . . ,200m,200n, where after the data of the primary buffer has been returned to the legacy application108, the next buffer is designated as the primary buffer. After the last buffer200nis designated as the primary buffer, the next buffer to be designated as the primary buffer is first buffer200a, i.e., buffers200a. . .200nform a circular buffer.

In certain embodiments the legacy application108generates a synchronous read request204to the mapping application110. The synchronous read request204may request the mapping application110to send the first n bytes of data available at the mapping application110. The mapping application110may interpret the first n bytes of data to start at the designated primary buffer202, where the first n bytes of data may span a plurality of buffers. For example, if the legacy application108requests 1024 bytes of data, and the exemplary primary buffer202, i.e., buffer200b, includes 512 bytes of data, and the next buffer to the primary buffer202also includes 512 bytes of data, then data from two buffers200b,200cmay be returned to the legacy application108.

In response to receiving the synchronous read request204, the mapping application110generates an asynchronous read request206to the network stack112, where the asynchronous read request206may request from the network stack112a greater number of bytes than the number of bytes requested by the legacy application204. The number of bytes requested from the network stack112may be adjusted dynamically. The asynchronous read request206may be generated whether or not the data requested by the legacy application108is present in the buffers200. If the data requested by the legacy application108is present in the buffers200, then the legacy application108does not have to wait, whereas if the data requested by the legacy application108is not present in the buffers200, then the legacy application108has to wait at least until the data is filled into the buffers200by the network stack112.

In certain embodiments, the legacy application108may request n bytes from the mapping application110, whereas the mapping application may request x bytes from the network stack112, where x>n. For example, while the data requested by the legacy application108may be designated for inclusion in buffers200b,200c, the mapping application110may also fetch buffers200d,200ein anticipation of a future requirement of data by the legacy application108, i.e., the mapping application110prefetches data. Subsequent synchronous read request204from the legacy application108may be satisfied with data already present in the buffers200, and the legacy application108may not have to wait because the request for data is satisfied from data available in the buffers200to the mapping application.

In certain embodiments, the amount of prefetched data to the buffers200can vary depending on system resources and other requirements. If the legacy application108is reading at a rate faster than the rate at which the buffers200are being filled, then a greater number of buffers may be used for prefetching data. As the rate at which buffers are being read decreases a fewer number of buffers may be used for prefetching data. The computing platform can dynamically adjust to suit the data requirements of the legacy application108.

The network stack112receives the asynchronous read request206and may write the data to the buffers200. While writing data to the buffers200, the network stack112may write data to the buffers that have already been read by the legacy application108or to buffers that are empty. Subsequently, the network stack112sends a read complete notification208to the mapping application110, where the read complete notification208indicates that the asynchronous read request206has been satisfied. In the time period between the generation of the asynchronous read request206and the receipt of the read complete notification208the mapping application110may perform other tasks.

If the legacy application108was waiting for the synchronous read request204to be satisfied, then the mapping application110sends a return210corresponding to the synchronous read request204, where the return210includes the data for which the synchronous read request204was waiting. For example, in certain embodiments the legacy application108may have received part of the requested data from data stored in the buffers220, but was waiting for the rest of the requested, data. The buffers whose data are returned to the legacy application108may be filled at a subsequent time by the network stack112.

FIG. 2illustrates an embodiment in which the network stack112stores data received from the network interface106in the plurality of buffers200of a mapping application110, in response to asynchronous read requests206from the mapping application110. The mapping application110maps synchronous read requests204from the legacy application to asynchronous read requests206for the network stack112. Additionally, the mapping application110prefetches data from the network stack112anticipating future requirements of data from the legacy application108.

FIG. 3illustrates first operations for mapping programming interfaces in the computing environment100ofFIG. 1, in accordance with certain embodiments. The first operations may be implemented in the mapping application110.

Control starts at block300, where the mapping application110receives a synchronous request204for sending data to a legacy application108. In response to the synchronous request204, the mapping application110sends (at block302) an asynchronous request206to the network stack112. In certain embodiments, the mapping application110may send the asynchronous request206to the network stack112whether or not the synchronous request204can be satisfied from data already stored in the buffers200.

The mapping application110responds (at block304) to the synchronous request204with the data from at least one buffer202of a plurality of buffers200. In certain embodiments, the at least one buffer202is the primary buffer202. Data from additional buffers may also be returned after data from the primary buffer202has been returned to the legacy application108and the next buffer has been designated as the primary buffer.

FIG. 3illustrates certain embodiments in which the mapping application110maps synchronous read requests204from a legacy application108to asynchronous read requests206for a network stack112. The mapping application110also prefetches data from the network stack112so that subsequent synchronous requests204from the legacy application108can be satisfied from data already stored in the buffers200, such that the legacy application108does not have to wait.

FIG. 4illustrates second operations for mapping programming interfaces in the computing environment100ofFIG. 1, in accordance with certain embodiments. The second operations may be implemented in the computational platform102by a first application108, such as, the legacy application, a second application110, such as, the mapping application, and a network stack112.

Control starts at block400, where the first application108, i.e., the legacy application, generates a synchronous request204for reading data, where the first application108waits until the synchronous request is responded to by the second application110, i.e., the mapping application.

The second application110, receives (at block402) the synchronous request204for reading data. The data may or may not be present in the buffers200that are filled by the network stack112.

The second application110sends (at block404) an asynchronous request206to fill selected buffers of a plurality of buffers200, where operations can be executed by the second application110without waiting for the asynchronous request206to be satisfied, and where the selected buffers may be empty or may have already been read. For example, the second application110may request the network stack112to fill selected buffers200b,200c,200dwhere no data corresponding to the synchronous read204is present in the buffers200. The selected buffers200b,200c,200dmay be either empty or may contain data that has been read previously by the legacy application108.

The network stack112, receives (at block406) the asynchronous request206from the second application110. The network stack112initiates (at block408) the filling of the selected buffers in response to the asynchronous request, and responds to the asynchronous request. After the selected buffers have been filled the network stack112may send a read complete notification208to the mapping application.

The second application110responds (at block410) to the synchronous request204with the data from at least one buffer of the plurality of buffers200. The second application110may further respond with data from additional buffers beyond the at least one buffer if the synchronous read request from the first application108spans more than the at least one buffer.

FIG. 4illustrates an embodiment in which a first application108sends a synchronous request204to a second application110, and the second application110maps the synchronous request204to an asynchronous request206for a network stack112. The second application110also prefetches data from the network stack112in anticipation of future data requirements of the first application108.

In certain embodiments, the mapping application110may also receive the read completion notification208from the network stack112so that the state of buffers200may be changed from waiting to be filled to filled.

Certain embodiments reduce the time period that the legacy application108is blocked, i.e., waiting, to provide lower latency and lower processor utilization in the computing platform102. The number of buffers200in use may be dynamically adjusted during runtime based on available resources and system load.

WhileFIGS. 1-4have been illustrated with reference to a network stack112, in alternative embodiments the mapping of the synchronous requests204to asynchronous requests206may be for other applications, such as, graphics processing and disk I/O.

The described techniques may be implemented as a method, apparatus or article of manufacture involving software, firmware, micro-code, hardware and/or any combination thereof. The term “article of manufacture” as used herein refers to program instructions, code and/or logic implemented in circuitry [e.g., in integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.] and/or a computer readable medium (e.g., magnetic storage medium, such as hard disk drive, floppy disk, tape), optical storage (e.g., CD-ROM, DVD-ROM, optical disk, etc.), volatile and non-volatile memory device (e.g., Electrically Erasable Programmable Read Only Memory (EEPROM), Read Only Memory (ROM), Programmable Read Only Memory (PROM), Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), flash, firmware, programmable logic, etc.). Code in the computer readable medium may be accessed and executed by a machine, such as, a processor. In certain embodiments, the code in which embodiments are made may further be accessible through a transmission medium or from a file server via a network. In such cases, the article of manufacture in which the code is implemented may comprise a transmission medium, such as a network transmission line, wireless transmission media, computer accessible signals propagating through space, computer accessible radio waves, computer accessible infrared signals, etc. Of course, those skilled in the art will recognize that many modifications may be made without departing from the scope of the embodiments, and that the article of manufacture may comprise any information bearing medium known in the art. For example, the article of manufacture comprises a storage medium having stored therein instructions that when executed by a machine results in operations being performed. Furthermore, program logic that includes code may be implemented in hardware, software, firmware or many combinations thereof. The described operations ofFIGS. 1-4may be performed by circuitry, where “circuitry” refers to either hardware or software or a combination thereof. The circuitry for performing the operations of the described embodiments may comprise a hardware device, such as an integrated circuit chip, a PGA, an ASIC, etc. The circuitry may also comprise a processor component, such as an integrated circuit, and code in a computer readable medium, such as memory, wherein the code is executed by the processor to perform the operations of the described embodiments.

Certain embodiments illustrated inFIG. 5may implement a system500comprising processor502coupled to a memory504, wherein the processor502is operable to perform the operations described inFIGS. 2-4.

FIG. 6illustrates a block diagram of a system600in which certain embodiments may be implemented. Certain embodiments may be implemented in systems that do not require all the elements illustrated in the block diagram of the system600. The system600may include circuitry602coupled to a memory604, wherein the described operations ofFIGS. 2-5may be implemented by the circuitry602. In certain embodiments, the system600may include a processor606and a storage608, wherein the storage608may be associated with program logic610including code612, that may be loaded into the memory604and executed by the processor606. In certain embodiments the program logic610including code612is implemented in the storage608. In certain embodiments, the operations performed by program logic610including code612may be implemented in the circuitry602. Additionally, the system600may also include a video controller614. The operations described inFIGS. 2-4may be performed by the system600.

Certain embodiments may be implemented in a computer system including a video controller614to render information to display on a monitor coupled to the system600, where the computer system may comprise a desktop, workstation, server, mainframe, laptop, handheld computer, etc. An operating system may be capable of execution by the computer system, and the video controller614may render graphics output via interactions with the operating system. Alternatively, some embodiments may be implemented in a computer system that does not include a video controller, such as a switch, router, etc. Furthermore, in certain embodiments the device may be included in a card coupled to a computer system or on a motherboard of a computer system.

Certain embodiments may be implemented in a computer system including a storage controller, such as, a Small Computer System Interface (SCSI), AT Attachment Interface (ATA), Redundant Array of Independent Disk (RAID), etc., controller, that manages access to a non-volatile storage device, such as a magnetic disk drive, tape media, optical disk, etc. Certain alternative embodiments may be implemented in a computer system that does not include a storage controller, such as, certain hubs and switches.

At least certain of the operations ofFIGS. 2-4can be performed in parallel as well as sequentially. In alternative embodiments, certain of the operations may be performed in a different order, modified or removed. Furthermore, many of the software and hardware components have been described in separate modules for purposes of illustration. Such components may be integrated into a fewer number of components or divided into a larger number of components. Additionally, certain operations described as performed by a specific component may be performed by other components.

The data structures and components shown or referred to inFIGS. 1-6are described as having specific types of information. In alternative embodiments, the data structures and components may be structured differently and have fewer, more or different fields or different functions than those shown or referred to in the figures. Therefore, the foregoing description of the embodiments has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Many modifications and variations are possible in light of the above teaching.