Method and apparatus for processing packets

A computer implemented method, apparatus, and computer usable program code for processing packets for transmission. A set of interface specific network buffers is identified from a plurality of buffers containing data for a packet received for transmission. A data structure describing the set of interface specific network buffers within the plurality of buffers is created, wherein a section in the data structure for an interface specific network buffer in the set of interface specific network buffers includes information about a piece of data in interface specific network buffer, wherein the data structure is used to process the packet for transmission.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to an improved data processing system and in particular to a method and apparatus for processing data. Still more particularly, the present invention relates to a computer implemented method, apparatus, and computer usable program code for processing packets for transmission on a network.

2. Description of the Related Art

Computers and other devices on a network, such as a local area network (LAN) or the Internet, often exchange data with other computers or devices. For example, a word processing application may retrieve a document from storage device located on another computer or save a document onto a storage device on another computer. A browser application may send information, such as a request for a web page. In response to the request, the browser application may receive a web page from a web site located on a server computer. Further, the browser application may send information, such as data entered into a form on a downloaded web page to a server. All of these different types of data transmissions are accomplished by sending data across a network connection using discrete segments of data. The data sent on to a network is referred to as a packet.

Operating systems typically include a network protocol stack that is used to transmit data received by an application for transmission on to a network. This data is typically received in the form of a set of memory locations, such as a set of buffers in the memory of a computer.

Normally, data for packets are stored in system buffers. The data in these types of buffers are either copied by the network device driver to pre-registered transmit buffers or the system buffers are registered dynamically or “on-the-fly” to allow the network adapter to access the data in these buffers. In transmitting data in packets, the network adapter requires access to the memory buffer.

The process of obtaining the memory address accessible by a network adapter and making the underlying memory visible to the network adapter is referred to as “registration”. The processor cycles and/or execution time for registration are significant with respect to performance in transmitting packets. If the buffer in which data for a packet is not registered or cannot be registered, then the data is copied to a buffer or memory location that can be accessed by the adapter. This process also takes time and resources.

The networking protocol in the AIX® operating system currently implements interface specific network buffers. AIX® is a registered trademark of International Business Machines Corporation. These types of buffers may be used to improve the performance or speed at which data is transmitted by a networking protocol stack on to the network, due to the fact that these interface specific network buffers are pre-registered with the network adapter.

Performance gains are obtained with these types of buffers because a network device driver does not have to copy a packet for transmission to pre-registered transmit buffers. As a result, the overhead of a copy operation needed to place data received from an application into pre-registered transmit buffers is avoided. In some cases, the network device driver does not have to perform an on-the-fly or dynamic registration of a transmit buffer containing a packet for transmission. This situation results in avoiding a series of system calls that require time in terms of processor cycles and/or completion time.

As a result, interface specific buffers provide a significant performance advantage for transmitting data because the data does not have to be copied or registered dynamically.

In some cases, however, the application may pass a list of network buffers in which this list contains both interface specific buffers and regular or non-interface specific buffers. This list may result in data for a packet for transmission to contain both interface specific buffers and non-interface specific buffers. The processing of data found in mixed types of buffers like these result in the network device driver treating the entire packet as being located in a non-interface specific buffer. As a result, both interface specific buffers and non-interface specific buffers are treated the same in which either a registration of the buffers occurs or the data is copied into pre-registered buffers.

SUMMARY OF THE INVENTION

The illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code for processing packets for transmission. A set of interface specific network buffers is identified from a plurality of buffers containing data for a packet received for transmission. A data structure describing the set of interface specific network buffers within the plurality of buffers is created, wherein a section in the data structure for an interface specific network buffer in the set of interface specific network buffers includes information about a piece of data in interface specific network buffer, wherein the data structure is used to process the packet for transmission.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures and in particular with reference toFIG. 1, a block diagram of a data processing system is depicted in which illustrative embodiments may be implemented. In the depicted example, data processing system100employs a hub architecture including a north bridge and memory controller hub (NB/MCH)102and a south bridge and input/output (I/O) controller hub (SB/ICH)104. Processing unit106, main memory108, and graphics processor110are coupled to north bridge and memory controller hub102. Processing unit106may contain one or more processors and even may be implemented using one or more heterogeneous processor systems. Graphics processor110may be coupled to the NB/MCH through an accelerated graphics port (AGP), for example.

In the depicted example, local area network (LAN) adapter112is coupled to south bridge and I/O controller hub104, audio adapter116, keyboard and mouse adapter120, modem122, read only memory (ROM)124, universal serial bus (USB) and other ports132, PCI/PCIe devices134are coupled to south bridge and I/O controller hub104through bus138. Hard disk drive (HDD)126and CD-ROM130are coupled to south bridge and I/O controller hub104through bus140.

PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM124may be, for example, a flash binary input/output system (BIOS). Hard disk drive126and CD-ROM130may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I/O (SIO) device136may be coupled to south bridge and I/O controller hub104.

An operating system runs on processing unit106. This operating system coordinates and controls various components within data processing system100inFIG. 1. The operating system may be a commercially available operating system, such as Microsoft® Windows XP®. (Microsoft® and Windows XP® are trademarks of Microsoft Corporation in the United States, other countries, or both). An object oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java™ programs or applications executing on data processing system100. Java™ and all Java™-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive126. These instructions and may be loaded into main memory108for execution by processing unit106. The processes of the illustrative embodiments may be performed by processing unit106using computer implemented instructions, which may be located in a memory. An example of a memory is main memory108, read only memory124, or in one or more peripheral devices.

The hardware shown inFIG. 1may vary depending on the implementation of the illustrated embodiments. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted inFIG. 1. Additionally, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system.

The systems and components shown inFIG. 1can be varied from the illustrative examples shown. In some illustrative examples, data processing system100may be a personal digital assistant (PDA). A personal digital assistant generally is configured with flash memory to provide a non-volatile memory for storing operating system files and/or user-generated data. Additionally, data processing system100can be a tablet computer, laptop computer, or telephone device.

Other components shown inFIG. 1can be varied from the illustrative examples shown. For example, a bus system may be comprised of one or more buses, such as a system bus, an I/O bus, and a PCI bus. Of course the bus system may be implemented using any suitable type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. Additionally, a communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. Further, a memory may be, for example, main memory108or a cache such as found in north bridge and memory controller hub102. Also, a processing unit may include one or more processors or CPUs.

The depicted examples inFIG. 1are not meant to imply architectural limitations. In addition, the illustrative embodiments provide for a computer implemented method, apparatus, and computer usable program code for compiling source code and for executing code. The methods described with respect to the depicted embodiments may be performed in a data processing system, such as data processing system100shown inFIG. 1.

Next,FIG. 2is a diagram of a transmission control protocol/Internet protocol (TCP/IP) and similar protocols is depicted in accordance with an illustrative embodiment. TCP/IP and similar protocols are utilized by communications architecture200. In this example, communications architecture200is a 4-layer system. This architecture includes application layer202, transport layer204, network layer206, and link layer208. Each layer is responsible for handling various communications tasks.

Link layer208also is referred to as the data-link layer or the network interface layer and normally includes the device driver in the operating system and the corresponding network interface card in the computer. This layer handles all the hardware details of physically interfacing with the network media being used, such as optical cables or Ethernet cables.

Network layer206also is referred to as the internet layer and handles the movement of packets of data around the network. For example, network layer206handles the routing of various packets of data that are transferred over the network. Network layer206in the TCP/IP suite is comprised of several protocols, including Internet protocol (IP), Internet control message protocol (ICMP), and Internet group management protocol (IGMP).

Next, transport layer204provides an interface between network layer206and application layer202that facilitates the transfer of data between two host computers. Transport layer204is concerned with things such as, for example, dividing the data passed to it from the application into appropriately sized chunks for the network layer below, acknowledging received packets, and setting timeouts to make certain the other end acknowledges packets that are sent. In the TCP/IP protocol suite, two distinctly different transport protocols are present, TCP and User datagram protocol (UDP). TCP provides reliability services to ensure that data is properly transmitted between two hosts, including dropout detection and retransmission services.

Conversely, UDP provides a much simpler service to the application layer by merely sending packets of data called datagrams from one host to the other, without providing any mechanism for guaranteeing that the data is properly transferred. When using UDP, the application layer must perform the reliability functionality.

Application layer202handles the details of the particular application. Many common TCP/IP applications are present for almost every implementation, including a Telnet for remote login; a file transfer protocol (FTP); a simple mail transfer protocol (SMTP) for electronic mail; and a simple network management protocol (SNMP).

The different illustrative embodiments may be implemented in link layer208in these examples. More specifically, different embodiments for processing data for transmission in packets onto a network may be implemented in a network device driver in link layer208.

The different illustrative embodiments recognize that mixed buffers containing interface specific network buffers and non-interface specific network buffers, may be received for processing. Currently, the processing of these types of buffers is to process the buffers for a packet as all being non-interface specific network buffers. This type of processing reduces the performance gain intended by the use of interface specific network buffers. As a result, processing buffers in this manner wastes resources because interface specific network buffers are being processed in a slower manner than intended.

Thus, the different illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code processing packets for transmission. A set of interface specific network buffers are identified from a plurality of buffers containing data for a packet that is received for transmission. The set of interface network buffers is a set of one or more interface specific network buffers in these examples. A data structure is created in which the data structure describes the set of interface specific network buffers within the plurality of buffers. A section in the data structure for an interface specific network buffer in the set of interface specific network buffers includes information about a piece of data in the interface specific network buffer.

The data structure is used to process the packet for transmission. In this manner, buffers that are identified as interface specific network buffers may be processed as intended, while other buffers may be processed by copying data to a pre-registered transmission buffer or dynamically registering the buffer with the adapter.

Turning now toFIG. 3, a diagram illustrating components used in processing data for packets for transmission is depicted in accordance with an illustrative embodiment. In this example, application300may generate data for transmission onto a network.

In this particular example, application300stores may store or write data to a location that in accessed across a network. When application300writes the data to transport layer301, this layer may write data302in interface specific network buffers304. Data302may be stored in one or more buffers in interface specific network buffers304. Transport layer301also may write data306to system buffers308. Data306may be stored in one or more buffers in system buffers308.

In these examples, interface specific network buffers and transmit buffers309are buffers assigned to network driver310. Interface specific network buffers304may be passed up to application300through the stack for use in placing data302. In these examples, system buffers308are buffers that may be accessed by the application, are not mapped to network adapter311, and do not belong to network device driver310.

Access to interface specific network buffers is obtained by transport layer301making a request to network device driver310for these types of buffers. System buffers308are accessible to transport layer301without requiring a request to be made to network device driver310. System buffers308are buffers do not belong to network device driver310and are not visible or accessible by network adapter311for transmission onto a network. These types of buffers are used when interface specific network buffers304are not provided by network device driver310.

After transport layer301stores data302in interface specific network buffers304and data306in system buffers308, transport layer301informs network device driver310that data is present for transmission. Transport layer301passes data302and data306to network device driver310for processing by sending buffer list312to network device driver310. Buffer list312identifies buffers containing data302and data306. In these examples, buffer list312identifies interface specific network buffers304and system buffers308as buffers containing data302and data306as being present for transmission as a packet.

In these illustrative examples, network device driver310normally would process interface specific network buffers304in the same manner as system buffers308because buffer list312contains both types of buffers. In the illustrative embodiments, however, this type of performance degradation is avoided because network device driver310generates a description of the different types of buffers present in buffer list312that contain data for a packet that is to be transmitted by network adapter311.

Network device driver310uses buffer list312to examine each of the buffers on buffer list312. The header of the buffer is parsed to identify interface specific network buffers in these examples.

From examining the buffers on buffer list312, network device driver310creates an entry in table314for each buffer in buffer list312that is identified as an interface specific network buffer. As a result, table314contains an identification of all of interface specific network buffers304that contain data for a packet. In the depicted examples, network device driver310also may create entries for buffers in buffer list312that are found in system buffers308.

Although the depicted examples use a data structure in the form of table314to describe buffers identified in buffer list312, the data structure may take other forms. One example is a linked list.

After table314is created, network device driver310then processes the data found in buffers identified in buffer list312for processing by network adapter311. If all of the buffers are located in interface specific network buffers304, network device driver310does not need to perform any further processing of the data.

If all of the data is located in system buffers308, each of the buffers may be copied to transmit buffers309to pass the network adapter311for transmission onto a network. These buffers are pre-registered buffers that belong to network adapter311. These are buffers that have not been provided to transport layer301in the form of interface specific network buffers. In other words, if network device driver310does not provide any of these buffers to transport layer301, no interface specific network buffers304will be present.

Alternatively, system buffers308may be registered so that network adapter311can access them to send data for the packets in system buffers308onto the network. In any event, these are extra processing steps that are performed for data located in system buffers308.

In this example, data is located both in interface specific network buffers304and system buffers308. With the different illustrative embodiments, data302located in interface specific network buffers304do not require this additional processing even though data302for the same packet also is located in system buffers308.

Instead, with a mixed list of interface specific network buffers and non-interface specific network buffers in buffer list312, performance gains still may achieved because the additional processing does not have to be performed for the data found in interface specific network buffers304. This differentiation of buffers is provided through table314in these examples. In this manner, the buffers identified as interface specific network buffers304in table314do not have to be copied or registered as a transmit buffer by network device driver310.

Network device driver310traverses table314and constructs a transmit descriptor list for use by network adapter310. In processing the buffers, network device driver310may copy the data in that buffer into transmit buffers309or register that buffer as a transmit buffer for each entry that is not an interface specific network buffer associated or assigned to network device driver310. Thereafter, the descriptor for that entry is filled out for the data in this buffer.

If on-the-fly or dynamic registration of non-interface specific network buffers for network device driver310is excluded, an entry in table314may describe a linked list of adjacent buffers. In this case, the data in those buffers may be automatically traversed in the linked list. The number of bytes specified in the length field in this entry beginning at the offset value found for the entry.

For each entry that contains an interface specific network buffer usable or assigned to network device driver310, network device driver310bypasses the copy or dynamic registration of the data for the buffer associated with the entry. Network device driver310only needs to fill out the transmit descriptor for that entry. When all of the buffers in table314are processed by network device driver310, network adapter311sends the packet onto the network.

Turning now toFIG. 4, a diagram illustrating an entry in a table of buffers is depicted in accordance with an illustrative embodiment. Entry400is an example of an entry in table314inFIG. 3.

In this example, entry400contains starting address402, length404, offset406, and registration key408. The information in entry400is used to identify a buffer and the information stored by the buffer in these examples. Starting address402identifies the starting address of the buffer containing data for transmission in a packet. Length404identifies the length of the data stored in the buffer from the starting address.

Offset406is a value in bytes that is offset from the beginning of the packet to the beginning of the data for this particular buffer. Registration key408indicates whether the buffer is an interface specific network buffer. For example, a null value may indicate that the buffer is not an interface specific network buffer. Length404in these examples is a value in bytes.

Turning now toFIG. 5, a flowchart of a process for processing data for transmission on a network is depicted in accordance with an illustrative embodiment. The process illustrated inFIG. 5may be implemented in a component, such as network device driver310inFIG. 3.

The process begins by receiving request to transmit data in a packet (step500). In step500the request may be a buffer list, such as buffer list312inFIG. 3. Based on the request, interface specific network buffers assigned to or associated with the network device driver are identified in which data is contained for transmission (step502). Thereafter, a data structure is created describing the interface specific network buffers (step504). The data is then processed for transmission using the data structure (step506) with the process terminating thereafter.

In these examples, the data structure also may include descriptions of buffers that are interface specific network buffers not associated with the network device driver or buffers that are simply not interface specific network buffers.

Turning now toFIG. 6, a flowchart of a process for processing a packet of data for transmission is depicted in accordance with an illustrative embodiment. The process inFIG. 6may be implemented in a component, such as network device driver310inFIG. 3. The process inFIG. 6is employed to generate a table, such as table314inFIG. 3.

In this example, the process begins by determining whether interface specific network buffers are enabled for this interface or on-the-fly registration is supported (step600).

If the determination to either of these questions is yes, the buffer header for an unprocessed buffer is parsed (step602). In these examples, the buffer is parsed to obtain a data address, a data length, and an mpool ID. The mpool ID is the identification of which network device driver the network buffer belongs to in this example. Each network device driver has a pool or group of buffers that are assigned to the network device driver. Thereafter, the current offset in bytes is calculated from the beginning of the packet based on the data length (step604).

Next, a determination is made as to whether the buffer belongs to this interface (step606). The interface is the network device driver in these examples. The determination in step606is made using the mpool ID in these examples. If the buffer belongs to the interface processing the buffer, the buffer header is parsed to obtain a registration key (step608). This registration key indicates which registered memory region the buffer belongs to in these examples.

Afterwards, a new table entry is created for the buffer (step610). In these examples, the table entry includes a table address, data length, offset, and a registration key. The registration key value is null if the buffer is not an interface specific network buffer in these examples.

Then, a determination is made as to whether another buffer is present in the linked list for the packet (step612). If another buffer is not present, the process terminates. Otherwise, the process returns to step602to parse a buffer header for another unprocessed buffer, as described above.

With reference again to step606, if the buffer does not belong to the interface, a determination is made as to whether the previous table entry in the table is for a non-interface specific network buffer (step607). If the previous entry is not for a non-interface specific network buffer, the process proceeds to step610as described above. Otherwise, the data length of the current buffer is added to the data length value of the previous entry (step614). The process then proceeds to step612as described above.

With reference again to step600, if interface specific network buffers are not enabled or on-the-fly registration is not supported, the process creates a single table entry (step616) with the process terminating thereafter. The table entry contains the data address, data length of the packet, an offset value of zero, and a registration key equal to a null value.

Turning now toFIG. 7, a flowchart of a process for processing a table of buffers is depicted in accordance with an illustrative embodiment. The process illustrated inFIG. 7may be implemented by a software component, such as device driver310inFIG. 3.

The process begins by selecting an unprocessed entry from the table (step700). Thereafter, a determination is made as to whether the table entry value for the registration key is a null value (step702). If the registration key value for the table entry is a null value, a determination is made as to whether on-the-fly registration is supported (step704). If on-the-fly registration is supported, the buffer for the current entry is registered (step706). Next, a transmit descriptor is completed using the table entry data (step708). A determination is then made as to whether another table entry is present that as not yet been processed (step710). If another table entry has not been present, the process terminates. Otherwise, the process returns to step700as described above.

With reference again to step704, if on-the-fly registration is not supported, then the process copies the data described by the entry to a pre-registered buffer (step712). The entry in step712may describe one of more buffers.

Thereafter, the process proceeds to step708as described above. With reference again to step702, if the registration key value in the table entry is not a null value, the process proceeds to step708as described above.

The flowcharts and block diagrams in the different depicted embodiments illustrate the architecture, functionality, and operation of some possible implementations of apparatus, methods and computer program products. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified function or functions. In some alternative implementations, the function or functions noted in the block may occur out of the order noted in the figures. For example, in some cases, two blocks shown in succession may be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

Thus, the different illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code processing packets for transmission. A set of interface specific network buffers are identified from a plurality of buffers containing data for a packet received for transmission. A data structure is created describing the set of interface specific network buffers within the plurality of buffers. A section in the data structure for an interface specific network buffer in the set of the interface specific network buffers includes information about a piece of data in the interface specific network buffer. The data structure is used to process the packet for transmission.

Further, a computer storage medium may contain or store a computer readable program code such that when the computer readable program code is executed on a computer, the execution of this computer readable program code causes the computer to transmit another computer readable program code over a communications link. This communications link may use a medium that is, for example without limitation, physical or wireless.