Patent Application
20230336503
The present disclosure relates generally to data handling in a computer system, and in particular, to receiving packet data over a network.
Computer systems are regularly connected together across networks to exchange data for a wide variety of purposes. Data is typically sent across a network in packets. In modern systems, computers may be required to process a large volume of packets at very high speeds. However, handling all this data in each computer can be time consuming and challenging. For example, all packets may not have the same amount of data. Additionally, some packets with very large data payloads may produce errors in a computer system receiving such data because the computer system may not be able to handle the large payload size. Such failures may slow down the computers performance and cause undesirable delays in data processing, for example.
Embodiments described herein advantageously eliminate delays caused by large data payloads received across a network.
Described herein are techniques for processing packet data. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of some embodiments. Various embodiments as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below and may further include modifications and equivalents of the features and concepts described herein.
Features and advantages of the present disclosure include techniques for improving packet throughput speeds by employing an overflow buffer (aka a “skid” buffer) that stores data from each packet that does not fit within typical data buffers assigned to each packet as they are processed. It has been observed that data overflows can slow down packet processing in some applications. For example, when a packet arrives in a network interface, a network interface driver program may assign each packet one or more buffers (herein, “packet buffers) to store packet data. If the data in the packet is greater than a data capacity of the available packet buffers, the packet cannot be processed, and a failure occurs. However, recovering from a packet data overflow where remaining data in the packet (e.g., data that did not have room in the packet buffers) can be time consuming and slow down packet processing. It has been observed in some applications that storing the remaining data in an overflow buffer and then continuing packet processing may not incur the same time penalties as some other approaches, and may be an advantageous approach for processing packets, for example.
L2 NIC Driver program 410 may configure each packet with scatter/gather lists (SGL) 411. A scatter/gather list may comprise a list of pointer/length tuples (pointer, length), which specify storage locations and available lengths in each storage location to store data from the packet, for example. SGLs may include points to packet buffers and to a shared overflow buffer. In this example, L2 NIC driver 410 configures a first packet 420 with an SGL pointing to one or more packet buffers 430 and to overflow buffer 440 for storing any remaining data that does not fit within buffer(s) 430. Likewise, L2 NIC driver 410 configures a second packet 421 with an SGL pointing to one or more packet buffers 431 and to overflow buffer 440 for storing any remaining data that does not fit within buffer(s) 431. As mentioned above, when data received with a packet does not fit within allocated packet buffers assigned by the driver 410, the remaining data is automatically and seamlessly stored in overflow buffer 440. The oversized packet may then be deleted without any delays resulting from the overflow, for example.
In one embodiment, a “pointer” in the scatter/gather list is not pointing to any actually allocated memory, but instead contains some nominal or invalid value (e.g., 0 or 0xBADCOFFE), which is never used as an actual pointer. Rather, the pointer is used as a trigger to the network interface hardware to discard this data. One potential advantage of such an implementation is that it may avoid writing the data to the host memory.
In yet another embodiment, instead of allocating an overflow buffer large enough to store the entire overflow from a packet, the network interface driver program may write an SGL as follows: {data buffer, overflow buffer, overflow buffer, overflow buffer}. This allows using a smaller overflow buffer to absorb bigger packets using a larger receive descriptor provided to the NIC for each packet. In another embodiment, an input-output memory management unit (IOMMU) may map multiple IO virtual addresses to the same overflow page, for example, and use this mapping as the overflow buffer.
Bus subsystem 504 can provide a mechanism for letting the various components and subsystems of computer system 500 communicate with each other as intended. Although bus subsystem 504 is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple busses.
Network interface subsystem 516 can serve as an interface for communicating data between computer system 500 and other computer systems or networks. Embodiments of network interface subsystem 516 can include, e.g., Ethernet, a Wi-Fi and/or cellular adapter, a modem (telephone, satellite, cable, ISDN, etc.), digital subscriber line (DSL) units, and/or the like.
Storage subsystem 506 includes a memory subsystem 508 and a file/disk storage subsystem 510. Subsystems 508 and 510 as well as other memories described herein are examples of non-transitory computer-readable storage media that can store executable program code having the functionality of embodiments of the present disclosure.
Memory subsystem 508 includes a number of memories including a main random access memory (RAM) 518 for storage of instructions and data during program execution and a read-only memory (ROM) 520 in which fixed instructions are stored. File storage subsystem 510 can provide persistent (e.g., non-volatile) storage for program and data files, and can include a magnetic or solid-state hard disk drive, an optical drive along with associated removable media (e.g., CD-ROM, DVD, Blu-Ray, etc.), a removable flash memory-based drive or card, and/or other types of storage media known in the art.
It should be appreciated that computer system 500 is illustrative and many other configurations having more or fewer components than system 500 are possible.
Each of the following non-limiting features in the following examples stand on their own or are combined with the other features in the examples below.
In various embodiments, the present disclosure includes computer system, method of processing packets from a network, or computer readable medium storing a program.
In one embodiment, the computer system comprises a network interface; a processor; and a non-transitory machine-readable medium storing a program executable by the processor, the program comprising sets of instructions for controlling the network interface.
In one embodiment, the network interface receives a plurality of packets comprising data.
In one embodiment, the program configures the network interface to store data in each packet in a corresponding packet buffer.
In one embodiment, when a size of the data in a particular packet is greater than a capacity of the buffer, the network interface stores remaining data from the particular packet in at least one overflow buffer, and the particular packet is deleted.
In one embodiment, for each received packet, the program configures the network interface with one or more storage locations for storing the data in each packet and at one location of the at least one overflow buffer.
In one embodiment, the program is a layer two (2) network interface driver program.
In one embodiment, the overflow buffer is a single overflow buffer having a capacity larger than a largest data packet received by the network interface.
In one embodiment, the program sends, for each received packet, a plurality of tuples comprising a pointer and a data length specifying storage locations for the data in each corresponding packet.
In one embodiment, the program further sends, for each received packet, at least one pointer to the at least one overflow buffer.
In one embodiment, the overflow buffer has a capacity large enough to prevent packet deletion due to packet size.
In one embodiment, the computer system is a server.
In one embodiment, a plurality of packets comprising data are received in a network interface.
In one embodiment, the network interface is configured to store data in each packet in a corresponding packet buffer.
In one embodiment, when a size of the data in a particular packet is greater than a capacity of the particular packet buffer, configuring the network interface to store remaining data from the particular packet in an overflow location and deleting the particular packet.
In one embodiment, for each received packet, the program configures the network interface with one or more storage locations for storing the data in each packet and one or more pointers to the overflow location.
In one embodiment, the program is a network interface driver program.
In one embodiment, the program sends, for each received packet, a plurality of tuples comprising a pointer and a data length specifying storage locations for the data in each corresponding packet.
In one embodiment, the program further sends, for each received packet, one or more pointers to the overflow location.
In one embodiment, the overflow location is an overflow buffer.
In one embodiment, the overflow buffer has a capacity larger than a largest data packet received by the network interface.
In one embodiment, the overflow buffer has a capacity large enough to prevent packet deletion due to packet size.
In one embodiment, configuring the network interface to store remaining data from the particular packet in an overflow location triggers the network interface to delete the packet without storing the remaining data.
In one embodiment, the present disclosure includes a non-transitory machine-readable medium storing a network interface driver program executable by a server.
In one embodiment, the method, system, or program perform the steps of: receiving, in a network interface, a plurality of packets comprising data; configuring the network interface to store data in each packet in a corresponding packet buffer, wherein the network interface driver program sends a plurality of tuples comprising a pointer and a data length specifying storage locations for the data in each corresponding packet and a pointer to an overflow buffer; and when a size of the data in a particular packet is greater than a capacity of the particular packet buffer, configuring the network interface to store remaining data from the particular packet in the overflow buffer and deleting the particular packet, wherein the plurality of packets receive a pointer to the same overflow buffer, and the overflow buffer has a capacity greater than a largest amount of data in a packet of the plurality of packets received by the network interface.
In one embodiment, for each received packet, the program configures the network interface with one or more storage locations for storing the data in each packet and the location of the overflow buffer.
In one embodiment, the overflow buffer has a capacity larger than a largest data packet received by the network interface.
The above description illustrates various embodiments along with examples of how aspects of some embodiments may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of some embodiments as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents may be employed without departing from the scope hereof as defined by the claims.
