WO2007069095A2 - Method and system for transparent tcp offload - Google Patents
Method and system for transparent tcp offload Download PDFInfo
- Publication number
- WO2007069095A2 WO2007069095A2 PCT/IB2006/004098 IB2006004098W WO2007069095A2 WO 2007069095 A2 WO2007069095 A2 WO 2007069095A2 IB 2006004098 W IB2006004098 W IB 2006004098W WO 2007069095 A2 WO2007069095 A2 WO 2007069095A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- tcp
- segment
- network flow
- particular network
- state
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/10—Program control for peripheral devices
- G06F13/12—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
- G06F13/124—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine
- G06F13/128—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine for dedicated transfers to a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/19—Flow control; Congestion control at layers above the network layer
- H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/41—Flow control; Congestion control by acting on aggregated flows or links
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9063—Intermediate storage in different physical parts of a node or terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9084—Reactions to storage capacity overflow
- H04L49/9089—Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
- H04L49/9094—Arrangements for simultaneous transmit and receive, e.g. simultaneous reading/writing from/to the storage element
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/12—Protocol engines
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/166—IP fragmentation; TCP segmentation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Definitions
- Certain embodiments of the invention relate to processing of TCP data and related TCP information. More specifically, certain embodiments of the invention relate to a method and system for transparent TCP offload. BACKGROUND OF THE INVENTION
- TCP Offload Engine the offloading engine performs all or most of the TCP processing, presenting to the upper layer a stream of data.
- the TTOE is tightly coupled with the operating system and therefore requires solutions that are dependent on the operating system and may require changes in the operating system to support it.
- the TTOE may require a side by side stack solution, requiring some kind of manual configuration, either by the application, for example, . by explicitly specifying a socket address family for accelerated connections.
- the TTOE may also require some kind of manual configuration by an IT administrator, for example, by explicitly specifying an IP subnet address for accelerated connections to select which of the TCP flows will be offloaded and the offload engine is very complex as it needs to implement TCP packet processing.
- LSO Large segment offload
- TSO transmit segment offload
- MTU maximum transmission unit
- TSO transmit segment offload
- the host sends to the NIC, bigger transmit units than the maximum transmission unit (MTU) and the NIC cuts them to segments according to the MTU. Since part of the host processing is linear to the number of transmitted units, this reduces the required host processing power. While being efficient in reducing the transmit packet processing, LSO does not help with receive packet processing.
- the host would receive from the far end multiple ACKs, one for each MTU-sized segment. The multiple ACKs require consumption of scarce and expensive bandwidth, thereby reducing throughput and efficiency.
- the TCP flows may be split to multiple hardware queues, according to a hash function tnat guarantees that a specific TCP flow would always be directed into the same hardware queue.
- the mechanism takes advantage of interrupt coalescing to scan the queue and aggregate subsequent packets on the queue belonging to the same TCP flow into a single large receive unit.
- While this mechanism does not require any additional hardware from the NIC besides multiple hardware queues, it may have various performance limitations. For example, if the number of flows were larger than the number of hardware queues, multiple flows would fall into the same queue, resulting in no LRO aggregation for that queue. If the number of flows is larger than twice the number of hardware queues, no LRO aggregation is performed on any of the flows. The aggregation may be limited to the amount of packets available to the host in one interrupt period. If the interrupt period is short, and the number of flows is not small, the number of packets that are available to the host CPU for aggregation on each flow may be small, resulting in limited or no LRO aggregation, even if the number of hardware queues is large.
- the LRO aggregation may be performed on the host CPU, resulting in additional processing.
- the driver may deliver to the TCP stack a linked list of buffers comprising of a header buffer followed by a series of data buffers, which may require more processing than in the case where all the data is contiguously delivered on one buffer.
- FIG. 1A is a block diagram of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
- FIG. 1 B is a block diagram of another exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
- FIG. 1C is an alternative embodiment of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
- FIG. 1 D is a block diagram of an exemplary system for handling transparent TCP offload, in accordance with an embodiment of the invention.
- FIG. 1E is a flowchart illustrating exemplary steps for frame reception and placement in accordance with an embodiment of the invention.
- FIG. 1 F illustrates an exemplary sequence of TCP/IP frames to be aggregated and not received in order, in accordance with an embodiment of the invention.
- FIG. 2A illustrates an exemplary sequence of TCP/IP frames to be aggregated and received in order, in accordance with an embodiment of the invention.
- FIG. 2B illustrates an exemplary aggregated TCP/IP frame generated from information in the sequence of TCP frames in FIG. 2A, in accordance with an embodiment of the invention.
- FIG. 2C is a diagram illustrating exemplary steps that may be utilized for handling out-of-order data when a packet P3 and a packet P4 arrive out-of- order with respect to the order of transmission, in accordance with an embodiment of the invention.
- FIG. 2D is a state diagram illustrating exemplary transparent TCP offload, in accordance with an embodiment of the invention.
- FIG. 3 is a flow chart illustrating exemplary steps for transparent TCP offload, in accordance with an embodiment of the invention.
- Certain embodiments of the invention may be found in a method and system for transparent TCP offload.
- Aspects of the method and system may comprise a coalescer that may be utilized to collect one or more TCP segments within a network interface card (NIC) without individually transferring state information for each of these TCP segments to a host system.
- the collected TCP segments may be temporarily buffered in the coalescer.
- the coalescer may verify that the network flow associated with the collected TCP segments has an entry in a flow lookup table (FLT). In instances where the FLT may be full, the coalescer may close a current entry and assign the network flow to the available entry.
- the coalescer may update information in the FLT.
- the coalescer may generate a single aggregated TCP segment based on the collected TCP segments.
- the single aggregated TCP segment which may comprise a plurality of TCP segments, may be referred to as a large receive segment.
- the aggregated TCP segment and state information may be communicated to the host system for processing.
- each of the plurality of TCP segments received would have to be individually processed by a host processor in the host system.
- TCP processing requires extensive CPU processing power in terms of both protocol processing and data placement on the receiver side.
- Current processing systems and methods involve the transfer of TCP state to a dedicated hardware such as a NIC, where significant changes to host TCP stack and/or underlying hardware are required.
- FlG. 1A is a block diagram of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention. Accordingly, the system of FIG. 1A may be adapted to handle transparent TCP offload of transmission control protocol (TCP) datagrams or packets.
- TCP transmission control protocol
- the system may comprise, for example, a CPU 102, a memory controller 104, a host memory 106, a host interface 108, network subsystem 110 and an Ethernet 112.
- the network subsystem 110 may comprise, for example, a transparent TCP-enabled Ethernet Controller (TTEEC) or a transparent TCP offload engine (TTOE) 114.
- TTEEC transparent TCP-enabled Ethernet Controller
- TTOE transparent TCP offload engine
- the network subsystem 110 may comprise, for example, a network interface card (NIC).
- NIC network interface card
- the host interface 108 may be, for example, a peripheral component interconnect (PCI), PCI-X, PCI-Express, ISA, SCSI or other type of bus.
- the memory controller 106 may be coupled to the CPU 104, to the memory 106 and to the host interface 108.
- the host interface 108 may be coupled to the network subsystem 110 via the TTEEC/TTOE 114.
- FIG. 1B is a block diagram of another exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
- the system may comprise, for example, a CPU 102, a host memory 106, a dedicated memory 116 and a chip set 118.
- the chip set 118 may comprise, for example, the network subsystem 110 and the memory controller 104.
- the chip set 118 may be coupled to the CPU 102, to the host memory 106, to the dedicated memory 116 and to the Ethernet 112.
- the network subsystem 110 of the chip set 118 may be coupled to the Ethernet 112.
- the network subsystem 110 may comprise, for example, the TTEEC/TTOE 114 that may be coupled to the Ethernet 112.
- the network subsystem 110 may communicate to the Ethernet 112 via a wired and/or a wireless connection, for example.
- the wireless connection may be a wireless local area network (WLAN) connection as supported by the IEEE 802.11 standards, for example.
- the network subsystem 110 may also comprise, for example, an on-chip memory 113.
- the dedicated memory 116 may provide buffers for context and/or data.
- the network subsystem 110 may comprise a processor such as a coalescer 111.
- the coalescer 111 may comprise suitable logic, circuitry and/or code that may be enabled to handle the accumulation or coalescing of TCP data.
- the coalescer 111 may utilize a flow lookup table (FLT) to maintain information regarding current network flows for which TCP segments are being collected for aggregation.
- the FLT may be stored in, for example, the network subsystem 110.
- the FLT may comprise at least one of the following: a source IP address, a destination IP address, a source TCP address, a destination TCP address, for example.
- At least two different tables may be utilized, for example, a table comprising a 4-tuple lookup to classify incoming packets according to their flow.
- the 4-tuple lookup table may comprise at least one of the following: a source IP address, a destination IP address, a source TCP address, a destination TCP address, for example.
- a flow context table may comprise state variables utilized for aggregation such as TCP sequence numbers.
- the FLT may also comprise at least one of a host buffer or memory address including a scatter-gather-list (SGL) for non-continuous memory, a cumulative acknowledgments (ACKs), a copy of a TCP header and options, a copy of an IP header and options, a copy of an Ethernet header, and/or accumulated TCP flags, for example.
- the coalescer 111 may be enabled to generate a single aggregated TCP segment from the accumulated or collected TCP segments when a termination event occurs. The single aggregated TCP segment may be communicated to the host memory 106, for example.
- the present invention need not be so limited to such examples and may employ, for example, any type of processor and any type of data link layer or physical media, respectively. Accordingly, although illustrated as coupled to the Ethernet 112, the TTEEC or the TTOE 114 of FIG. 1 A may be adapted for any type of data link layer or physical media. Furthermore, the present invention also contemplates different degrees of integration and separation between the components illustrated in FIGS. 1A-B. For example, the TTEEC/TTOE 114 may be a separate integrated chip from the chip set 118 embedded on a motherboard or may be embedded in a NIC.
- the coalescer 111 may be a separate integrated chip from the chip set 118 embedded on a motherboard or may be embedded in a NIC.
- the dedicated memory 116 may be integrated with the chip set 118 or may be integrated with the network subsystem 110 of FIG. 1 B.
- FIG. 1C is an alternative embodiment of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
- a host processor 124 a host memory/buffer 126, a software algorithm block 134 and a NIC block 128.
- the NIC block 128 may comprise a NIC processor 130, a processor such as a coalescer 131 and a reduced NIC memory/buffer block 132.
- the NIC block 128 may communicate with an external network via a wired and/or a wireless connection, for example.
- the wireless connection may be a wireless local area network (WLAN) connection as supported by the IEEE 802.11 standards, for example.
- WLAN wireless local area network
- the coalescer 131 may be a dedicated processor or hardware state machine that may reside in the packet-receiving path.
- the host TCP stack may comprise software that enables management of the TCP protocol processing and may be part of an operating system, such as Microsoft Windows or Linux.
- the coalescer 131 may comprise suitable logic, circuitry and/or code that may enable accumulation or coalescing of TCP data.
- the coalescer 131 may utilize a flow lookup table (FLT) to maintain information regarding current network flows for which TCP segments are being collected for aggregation.
- the FLT may be stored in, for example, the reduced NIC memory/buffer block 132.
- the coalescer 131 may enable generation of a single aggregated TCP segment from the accumulated or collected TCP segments when a termination event occurs.
- the single aggregated TCP segment may be communicated to the host memory/buffer 126, for example.
- providing a single aggregated TCP segment to the host for TCP processing significantly reduces overhead processing by the host 124. Furthermore, since there is no transfer of TCP state information, dedicated hardware such as a NIC 128 may assist with the processing of received TCP segments by coalescing or aggregating multiple received TCP segments so as to reduce per-packet processing overhead.
- an offload mechanism may be provided that is stateless from the host stack perspective, while state-full from the offload device perspective, achieving comparable performance gain when compared to TTOE.
- TTO Transparent TCP offload
- 64 KB of processing data units (PDUs) may be processed rather than 1.5 KB PDUs in order to produce a significant reduction in the packet rate, thus reducing the host processing power for packet processing.
- TTO no handshake may be utilized between the host operating system and the NIC containing the TTO engine.
- the TTO engine may operate autonomously in identifying new flows and for offloading.
- the offload on the transmit side may be similar to LSO, where the host sends big transmission units and the TTO engine cuts them to smaller transmitted packets according to maximum segment size (MSS).
- MSS maximum segment size
- Transparent TCP offload on the receive side may be performed by aggregating a plurality of received packets of the same flow and delivering them to the host as if they were received in one packet - one bigger packet in the case of received data packets, and one aggregate ACK packet in the case of received ACK packets.
- the processing in the host may be similar to the processing of a big packet that was received.
- rules may be defined to determine whether to aggregate packets. The aggregation rules may be established to allow as much aggregation as possible, without increasing the round trip time such that the decision whether to aggregate depends on the data that is received and the importance of delivering it to the host without delay.
- the aggregation may be implemented with transmit-receive coupling, wherein the transmitter and receiver are coupled, by utilizing transmission information for offload decisions, and the flow may be treated as a bidirectional flow.
- the context information of the receive offload in TTO may be maintained per flow.
- the incoming packet header may be utilized to detect the flow it belongs to and this packet updates the context of the flow.
- the transmitted network packets may be searched along with the received network packets to determine the particular network flow to which the packet belongs.
- the transmitted network packet may enable updating of the context of the flow, which may be utilized for receive offload.
- FIG. 1D is a block diagram of a system for handling transparent TCP offload, in accordance with an embodiment of the invention.
- an incoming packet frame 141 a frame parser 143, an association block 149, a context fetch block 151 , a plurality of on-chip cache blocks 147, a plurality of off-chip storage blocks 160, a plurality of on-chip storage blocks 162, a RX processing block 150, a frame buffer 154, a DMA engine 163, a TCP code block 157, a host bus 165, and a plurality of host buffers 167.
- the RX processing block 150 may comprise a coalescer 152.
- the frame parser 143 may comprise suitable logic, circuitry and/or code that may enable L2 Ethernet processing including, for example, address filtering, frame validity and error detection of the incoming frames 141.
- the next stage of processing may comprise, for example, L3 such as IP processing and L4 such as TCP processing within the frame parser 143.
- the TTEEC 114 may reduce the host CPU 102 utilization and memory bandwidth, for example, by processing traffic on coalesced TCP/IP flows.
- the TTEEC 114 may detect, for example, the protocol to which incoming packets belong based on the packet parsing information and tuple 145.
- the TTEEC 114 may detect whether the packet corresponds to an offloaded TCP flow, for example, a flow for which at least some TCP state information may be kept by the TTEEC 114. If the packet corresponds to an offloaded connection, then the TTEEC 114 may direct data movement of the data payload portion of the frame. The destination of the payload data may be determined from the flow state information in combination with direction information within the frame. The destination may be a host memory 106, for example. Finally, the TTEEC 114 may update its internal TCP and higher levels of flow state, without any coordination with the state of the connection on the host TCP stack, and may obtain the host buffer address and length from its internal flow state.
- an offloaded TCP flow for example, a flow for which at least some TCP state information may be kept by the TTEEC 114. If the packet corresponds to an offloaded connection, then the TTEEC 114 may direct data movement of the data payload portion of the frame. The destination of the payload data may be determined from the flow state information in combination with direction
- the receive system architecture may comprise, for example, a control path processing 140 and data movement engine 142.
- the system components above the control path as illustrated in upper portion of FIG. 1D may be designed to deal with the various processing stages used to complete, for example, the L3/L4 or higher processing with maximal flexibility and efficiency and targeting wire speed.
- the result of the stages of processing may comprise, for example, one or more packet identification cards that may provide a control structure that may carry information associated with the frame payload data. This may have been generated inside the TTEEC 114 while processing the packet in the various blocks.
- a data path 142 may move the payload data portions or raw packets 155 of a frame along from, for example, an on-chip packet frame buffer 154 and upon control processing completion, to a direct memory access (DMA) engine 163 and subsequently to the host buffer 167 via the host bus 165 that was chosen via processing.
- the data path 142 to the DMA engine may comprise packet data are and optional headers 161.
- the receiving system may perform, for example, one or more of the following: parsing the TCP/IP headers 145; associating the frame with a TCP/IP flow in the association block 149; fetching the TCP flow context in the context fetch block 151; processing the TCP/IP headers in the RX processing block 150; determining header/data boundaries and updating state 153; mapping the data to a host buffers; and transferring the data via a DMA engine 163 into these host buffers 167.
- the headers may be consumed on chip or transferred to the host buffers 167 via the DMA engine 163.
- the packet frame buffer 154 may be an optional block in the receive system architecture. It may be utilized for the same purpose as, for example, a first-in-first-out (FIFO) data structure is used in a conventional L2 NIC or for storing higher layer traffic for additional processing.
- the packet frame buffer 154 in the receive system may not be limited to a single instance.
- the data path 142 may store the data between data processing stages one or more times.
- coalescing operations described for the coalescer 111 in FIG. 1 B and/or for the coalescer 131 in FIG. 1C may be implemented in a coalescer 152 in the RX processing block 150 in FIG. 1D.
- buffering or storage of TCP data may be performed by, for example, the frame buffer 154.
- the FLT utilized by the coalescer 152 may be implemented using the off-chip storage 160 and/or the on-chip storage 162, for example.
- a new flow may be detected at some point during the flow lifetime.
- the flow state is unknown when the new flow is detected and the first packets are utilized to update the flow state until the flow is known to be in-order.
- a device performing TTO may also support other offload types, for example, TOE, RDMA, or iSCSI offload.
- the FLT for TTO may be shared with the connection search for other offload types with each entry in the FLT indicating the offload type for that flow. Packets that belong to flows of other offload types may not be candidates for TTO.
- the flow Upon detecting a new flow, the flow may be initiated with the basic initialization context. An entry in the FLT with a flow ID may be created.
- a plurality of segments of the same flow may be aggregated in TTO up to a receive aggregation length (RAL), presenting to the host a bigger segment for processing.
- RAL receive aggregation length
- the received packet may be placed in the host memory 126 but will not be delivered to the host. Instead, the host processor 124 may update the context of the flow this packet belongs to. The new incoming packet may either cause the packet to be delivered immediately alone if there were no prior aggregated packets that were not delivered or as a single packet that represents both that packet and the previously received packets.
- the packet may not be delivered but may update the flow's context.
- a termination event may occur and the packet may not be aggregated if at least one of the following occurs at the TCP level: (1) the data is not in-order as derived from the received sequence number (SN) and the flow's context; (2) at least one packet with TCP flags other than ACK flag, for example, a PUSH flag is detected; (3) at least one packet with selective acknowledgement (SACK) information is detected; or (4) if the ACK SN received is bigger than the delivered ACK SN, and requires stopping the aggregation.
- a termination event may occur and the packet may not be aggregated if at least one of the following occurs at the IP level: (1) the type of service (TOS) field in the IP header is different than the TOS field of the previous packets that were aggregated; or (2) the received packet is an IP fragment.
- TOS type of service
- the aggregated packet's header may contain the aggregated header of all the individual packets it contains.
- a plurality of TCP rules for the aggregation may be as follows.
- the SN in the aggregated header is the SN of the first or oldest packet; (2) the ACK SN is the SN of the last or youngest segment; (3) the length of the aggregated header is the sum of the lengths of all the aggregated packets; (4) the window in the aggregated header is the window received in the last or youngest aggregated packet; (5) the time stamp (TS) in the aggregated header is the TS received in the first or oldest aggregated packet; (6) the TS-echo in the aggregated header is the TS-echo received in the first or oldest aggregated packet; and (7) the checksum in the aggregated header is the accumulated checksum of all aggregated packets.
- TS time stamp
- a plurality of IP field aggregation rules may be provided.
- the TOS of the aggregated header may be that of all the aggregated packets;
- the time-to- live (TTL) of the aggregated header is the minimum of all incoming TTLs;
- the length of the aggregated header is the sum of the lengths in the aggregated packets;
- the fragment offset of the aggregated header may be zero for aggregated packets; and
- the packet ID of the aggregated header is the last ID received.
- the received packets may be aggregated until the received packet cannot be aggregated due to the occurrence of a termination event, or if a timeout has expired on that flow, or if the aggregated packet exceeds RAL.
- the timeout may be implemented by setting a timeout to a value, timeout aggregation value, when the first packet on a flow is placed without delivery.
- the following packets that are aggregated may not change the timeout.
- the timeout may be canceled and may be set again in the next first packet that is not delivered.
- other embodiments of the invention may provide timeout implementation by periodically scanning all the flows.
- the received ACK SN may be relevant to determine the rules to aggregate pure ACKs and to determine the rules to stop aggregation of packets with data due to the received ACK SN.
- the duplicated pure ACKs may never be aggregated. When duplicated pure ACKs are received, they may cause prior aggregated packets to be delivered and the pure ACK may be delivered immediately separately.
- the received ACK SN may also be utilized to stop the aggregation and deliver the pending aggregated packet to the host TCP/IP stack.
- a plurality of rules may be provided for stopping the aggregation according to the ACK SN. For example, (1) if the number of acknowledged (ACKed) bytes that are not yet delivered, taking into account the received segments and the prior segments that were not delivered exceeds a threshold, ReceiveAckedBytesAggretation, for example, in bytes; or (2) the time from the arrival of the first packet that advanced the received ACK SN exceeds a threshold, TimeoutAckAggregation, for example.
- a second timer per flow may be required or other mechanisms, such as periodically scanning the flows may be implemented.
- the flows may be removed from the host memory if one of the following occurs: (1 ) a reset (RST) flag was detected in the receive side; (2) a finish (FIN) flag was detected in the receive side; (3) there was no receive activity on the flow for a predefined time TerminateNoActivityTime, for example; (4) a KeepAlive packet in the receive direction was not acknowledged.
- RST reset
- FIN finish
- a least recently used (LRU) cache may be used instead of a timeout rule to remove the flows from the host memory.
- FIG. 1E is a flowchart illustrating exemplary steps for frame reception and placement in accordance with an embodiment of the invention.
- the network subsystem 110 may receive a frame from, for example, the Ethernet 112.
- a frame parser may parse the frame, for example, to find the L3 and L4 headers.
- the frame parser may process the L2 headers leading up to the L3 header, for example, IP version 4 (IPv4) header or IP version 6 (IPv6) header.
- IPv4 IP version 4
- IPv6 IP version 6
- the frame may carry an IPv4 datagram. If, for example, the IP header version field carries a value of 6, then the frame may carry an IPv6 datagram.
- the IP header fields may be extracted, thereby obtaining, for example, the IP source (IP SRC) address, the IP destination (IP DST) address, and the IPv4 header "Protocol” field or the IPv6 "Next Header”. If the IPv4 "Protocol" header field or the IPv6 "Next Header" header field carries a value of 6, then the following header may be a TCP header.
- the rest of the IP processing may subsequently occur in a manner similar to the processing in a conventional off-the-shelf software stack.
- Implementation may vary from the use of firmware on an embedded processor to a dedicated, finite state machine (FSM), or a hybrid of a processor and a state machine.
- the implementation may vary with, for example, multiple stages of processing by one or more processors, state machines, or hybrids.
- the IP processing may comprise, but is not limited to, extracting information relating to, for example, length, validity and fragmentation.
- the located TCP header may also be parsed and processed. The parsing of the TCP header may extract information relating to, for example, the source port and the destination port of the particular network flow associated with the received frame.
- the TCP processing may be divided into a plurality of additional processing stages.
- the frame may be associated with an end-to- end TCP/IP connection.
- the present invention may provide that the TCP checksum be verified.
- the flow may be defined by, for example, at least a portion of the following 4-tuple: IP Source • address (IP SRC addr); IP destination address (IP DST addr); TCP source port number (TCP SRC); and TCP destination port number (TCP DST).
- IP SRC addr IP Destination protocol
- IP DST addr IP destination address
- TCP SRC TCP source port number
- TCP DST TCP destination port number
- the process may be applicable for IPv4 or IPv6 with the choice of the relevant IP address.
- the 4-tuple may be completely extracted.
- Association hardware may compare the received 4-tuple with a list of 4-tuples stored in the TTEEC/TTOE 114.
- the TTEEC/TTOE 114 may maintain a list of tuples representing, for example, aggregated flows or offloaded connections being managed by the TTEEC/TTOE 114.
- the memory resources used for storing the association information may be costly for on-chip and off-chip options. Therefore, it is possible that not all of the association information may be housed on chip.
- a cache may be used to store the most active connections on chip. If a match is found, then the TTEEC/TTOE 114 may be managing the particular TCP/IP flow with the matching 4-tuple.
- the TCP flow context may be fetched.
- the TCP/IP headers may be processed.
- header/data boundaries may be determined.
- a coalescer may collect or accumulate a plurality of frames that may be associated with a particular network flow. The collected TCP segments and the collected information regarding the TCP/IP connection may be utilized to generate a TCP/IP frame comprising a single aggregated TCP segment, for example.
- the process may proceed to step 196.
- a termination event may be an incident, instance, and/or a signal that indicates to the coalescer that collection or accumulation of TCP segments may be completed and that the single aggregated TCP segment may be communicated to a host system for processing.
- payload data corresponding to the single aggregated TCP segment may be mapped to the host buffer.
- data from the single aggregated TCP segment may be transferred to the host buffer.
- FIG. 1F illustrates an exemplary sequence of TCP/IP frames to be aggregated and not received in order, in accordance with an embodiment of the invention.
- a first TCP/IP frame 202 there are shown a first TCP/IP frame 202, a second TCP/IP frame 204, a third TCP/IP frame 206, and a fourth TCP/IP frame 208.
- Each TCP/IP frame shown may comprise an Ethernet header 200a, an IP header 200b, a TCP header 200c, and a TCP options 20Od.
- each of the TCP/IP frames may comprise a payload portion that contains TCP segments comprising data being transferred.
- the Ethernet header 200a may have a value, enet_hdr, for the TCP/IP frames.
- the IP header 200b may comprise a plurality of fields.
- the IP header 200b may comprise a field, IP_LEN, which may be utilized to indicate a number of bytes in the frames.
- IP_LEN a field
- the IP header 200b may also comprise an identification field, ID, which may be utilized to identify the frame, for example.
- ID 100 for the first TCP/IP frame 202
- ID 101 for the second TCP/IP frame 204
- ID 103 for the third TCP/IP frame 206
- ID 102 for the fourth TCP/IP frame 208.
- the IP header 200b may also comprise additional fields such as an IP header checksum field, ip_csm, a source field, ip_src, and a destination field, ip_dest, for example.
- the value of ip_src and ip_dest may be the same for all frames, while the value of the IP header checksum field may be ip_csm ⁇ for the first TCP/IP frame 202, ip_csm1 for the second TCP/IP frame 204, ip_csm3 for the third TCP/IP frame 206, and ip_csm2 for the fourth TCP/IP frame 208.
- the TCP header 200c may comprise a plurality of fields.
- the TCP header 200c may comprise a source port field, src_prt, a destination port field, dest_prt, a TCP sequence field, SEQ, an acknowledgment field, ACK, a flags field, FLAGS, an advertised window field, WIN, and a TCP header checksum field, tcp_csm.
- the value of src_prt, dest_prt, FLAGS, and WIN may be the same for all frames.
- SEQ 100
- ACK 5000
- the TCP header checksum field is tcp_csm ⁇ .
- the TCP options 20Od may comprise a plurality of fields.
- the TCP options 20Od may comprise a time stamp indicator, referred to as timestamp, which is associated with the TCP frame.
- the value of the time stamp indicator may be timestampO for the first TCP/IP frame 202, timestampi for the second TCP/IP frame 204, timestamp3 for the third TCP/IP frame 206, and timestamp2 for the fourth TCP/IP frame 208.
- the exemplary sequence of TCP/IP frames shown in FIG. 1 F is received out-of-order with respect to the order of transmission by the network subsystem 110, for example.
- Information comprised in the ID field in the IP header 200b and/or in the timestamp field in the TCP options 20Od may indicate that the third TCP/IP frame 206 and the fourth TCP/IP frame 208 were received in a different order from the order of transmission.
- the fourth TCP/IP frame 208 was transmitted after the second TCP/IP frame 204 and before the third TCP/IP frame 206.
- a coalescer such as the coalescers described in FIGS.
- the coalescer may obtain information from the TCP/IP frames and may generate a single TCP/IP frame by coalescing the information received.
- the coalescer may utilize a FLT to store and/or update at least a portion of the information received from the TCP/IP frames.
- the coalescer may also utilize available memory to store or buffer the payload of the aggregated /IP frame.
- FlG. 2A illustrates an exemplary sequence of TCP/IP frames to be aggregated and received in order, in accordance with an embodiment of the invention.
- a first TCP/IP frame 202 there are shown a first TCP/IP frame 202, a second TCP/IP frame 204, a third TCP/IP frame 206, and a fourth TCP/IP frame 208.
- Each TCP/IP frame shown may comprise an Ethernet header 200a, an IP header 200b, a TCP header 200c, and a TCP options 20Od.
- each of the TCP/IP frames may comprise a payload portion that contains TCP segments comprising data being transferred.
- the Ethernet header 200a may have a value, enet__hdr, for the TCP/IP frames.
- the IP header 200b may comprise a plurality of fields.
- the IP header 200b may comprise a field, IP_LEN, which may be utilized to indicate a number of bytes in the frames.
- IP_LEN a field
- the IP header 200b may also comprise an identification field, ID, which may be utilized to identify the frame, for example.
- ID 100 for the first TCP/IP frame 202
- ID 101 for the second TCP/IP frame 204
- ID 102 for the third TCP/IP frame 206
- ID 103 for the fourth TCP/IP frame 208.
- the IP header 200b may also comprise additional fields such as an IP header checksum field, ip_csm, a source field, ip_src, and a destination field, ip_dest, for example.
- the value of ip_src and ip_dest may be the same for all frames, while the value of the IP header checksum field may be ip_csm ⁇ for the first TCP/IP frame 202, ip_csm1 for the second TCP/IP frame 204, ip_csm2 for the third TCP/IP frame 206, and ip_csm3 for the fourth TCP/IP frame 208.
- the TCP header 200c may comprise a plurality of fields.
- the TCP header 200c may comprise a source port field, src_prt, a destination port field, dest_prt, a TCP sequence field, SEQ, an acknowledgment field, ACK, a flags field, FLAGS, an advertised window field, WIN, and a TCP header checksum field, tcp_csm.
- the value of src_prt, dest_prt, FLAGS, and WIN may be the same for all frames.
- SEQ 100
- ACK 5000
- the TCP header checksum field is tcp_csm ⁇ .
- the TCP header checksum field is tcp_csm1.
- the TCP options 20Od may comprise a plurality of fields.
- the TCP options 20Od may comprise a time stamp indicator, referred to as timestamp, which is associated with the TCP frame.
- the value of the time stamp indicator may be timestampO for the first TCP/IP frame 202, timestampi for the second TCP/IP frame 204, timestamp2 for the third TCP/IP frame 206, and timestamp3 for the fourth TCP/IP frame 208.
- the exemplary sequence of TCP/IP frames shown in FIG. 2A is received in-order with respect to the order of transmission by the network subsystem 110, for example.
- a coalescer such as the coalescers described in FIGS. I B- IE may obtain information from the TCP/IP frames and may generate a single TCP/IP frame by coalescing the information received.
- the coalescer may utilize a FLT . to store and/or update at least a portion of the information received from the TCP/IP frames.
- the coalescer may also utilize available memory to store or buffer the payload of the aggregated /IP frame.
- FIG. 2B illustrates an exemplary aggregated TCP/IP frame generated from information in the sequence of TCP frames in FIG. 2A, in accordance with an embodiment of the invention.
- a single TCP/IP frame 210 that may be generated by a coalescer from the sequence of TCP/IP frames received in FIG. 2A.
- the TCP/IP frame 210 may comprise an Ethernet header 200a, an IP header 200b, a TCP header 200c, and a TCP options 20Od. While not shown, the TCP/IP frame 210 may also comprise a payload that contains TCP segments comprising actual data for received TCP/IP frames.
- the fields in the Ethernet header 200a, the IP header 200b, the TCP header 200c, and the TCP options 20Od in the TCP/IP frame 210 may be substantially similar to the fields in the TCP/IP frames in FIG. 2A.
- the value of ID 100, which corresponds to the ID value of the first TCP/IP frame 202.
- the value of the time stamp indicator is timestampO, which corresponds to the time stamp indicator of the first TCP/IP frame 202.
- the TCP/IP frame 210 may be communicated or transferred to a host system for TCP processing, for example.
- FIG. 2C is a diagram illustrating exemplary steps that may be utilized for handling out-of-order data when a packet P3 and a packet P4 arrive out-of- order with respect to the order of transmission, in accordance with an embodiment of the invention.
- the packets P3 and P4 may arrive in-order with respect to each other at the NIC 128 but before the arrival of a packet P2, as shown in the actual receive FRX traffic pattern 200.
- the packets P3 and P4 may correspond to a fourth packet and a fifth packet within an isle 211 , respectively, in a TCP transmission sequence.
- a first disjoint portion in the TCP transmission sequence may result from the arrival of the packets P3 and P4 as shown in the TCP receive sequence space 202 after the isle 213 comprising packets PO and P1.
- the rightmost portion of isle 211 rcv_nxt_R may be represented as (rcv_nxt_L + (length of isle)), where rcv_nxt_L is the leftmost portion of isle 211 and the length of isle is the sum of the lengths of packets P3 and P4.
- FIG. 2D is a state diagram illustrating exemplary transparent TCP offload, in accordance with an embodiment of the invention.
- a plurality of exemplary flow states namely, in order state 226, Out-Of-Order (OOO) state 224, or an unknown state 222.
- OOO Out-Of-Order
- the unknown state 222 may be detected for a flow for which a 3-way TCP handshake has not been detected or at some point in the life of the flow other than the initialization phase.
- the TCP 3-way handshake begins with a synchronize (SYN) segment containing an initial send sequence number (ISN) being chosen by, and sent from a first host.
- This sequence number may be the starting sequence number of the data in that packet and may increment for every byte of data sent within the segment.
- the second host may transmit a SYN segment with its own totally independent ISN number in the sequence number field along with an acknowledgment field.
- This acknowledgment (ACK) field may inform the recipient that its data was received at the other end and it expects the next segment of data bytes to be sent, and may be referred to as the SYN-ACK.
- the first host When the first host receives this SYN-ACK segment it may send an ACK segment containing the next sequence number, called forward acknowledgement and is received by the second host.
- the ACK segment may be identified by the ACK field being set. Segments that are not acknowledged within a certain time span may be retransmitted.
- the state diagram may track the out-of-order isle sequence number boundaries using, for example, the parameters rcv_nxt_R and rcv_nxt_L as illustrated in FIG. 2C.
- the first ingress segment may be referred to as an isle, for example, isle 213 (FIG. 2C) and the ordering state may be set to OOO state 224.
- the rightmost portion of isle rcv_nxt_R may be represented as (rcv_nxt_L + (length of isle)), where rcv_nxt_L is the leftmost portion of isle and the length of isle is the sum of the lengths of packets in the isle.
- transition state 232 the NIC 128 may not have the local stack acknowledgment information as the transmitter and receiver are decoupled.
- the ordering state may be modified from OOO state 224 to in-order state 226 whenever the isle length is greater than a threshold.
- the threshold may be set according to the local host stack maximum receive window because the far end may not send more data than this value without receiving an ACK.
- transition state 234 the initial ordering state may be set to the in order state 226, if the new flow is detected with the TCP 3-way handshake.
- the rcv_nxt_R may be utilized to check the condition of ingress packets according to the following algorithm.
- transition state 2308 the ordering state may be modified from in order state 226 to OOO state 224 if the isle length is not equal to rcv_nxt_R.
- the value of rcv_nxt_R may be used to check the condition of ingress packets according to the following algorithm.
- transition state 240 during OOO state 224, the boundaries of the highest OOO isle may be tracked for every ingress packet using the following exemplary algorithm.
- FIG. 3 is a flow chart illustrating exemplary steps for transparent TCP offload, in accordance with an embodiment of the invention.
- the coalescer 131 may classify the packets into non-TCP and TCP packets by examining the protocol headers.
- the coalescer 131 may continue processing without change.
- the coalescer 131 may compute the TCP checksum of the payload.
- step 308 for TCP packets with valid checksum, the coalescer 131 first searches the flow lookup table (FLT) using a tuple comprising IP source address, IP destination address, source TCP port and destination TCP port, to determine whether the packet belongs to a connection that the coalescer 131 is already aware of.
- FLT flow lookup table
- this packet may belong to a connection that is not known to the coalescer 131.
- the coalescer 131 may determine whether there is any TCP payload. If there is no TCP payload, for example, pure TCP ACK, the coalescer 131 may stop further processing and allow processing of the packet through a normal processing path and add an entry in the FLT.
- the coalescer 131 may create a new entry in the FLT for this connection. This operation may involve retiring an entry in the FLT when the FLT is full. The FLT retirement may immediately stop any further coalescing and provides an indication of any aggregated TCP segment to host TCP stack.
- step 314 if the newly created/replaced FLT entry, in addition to tuple, a TCP sequence number, a TCP acknowledgement number, a length of the TCP payload, and a timestamp option if present, may be recorded.
- any header before TCP payload may be placed into a buffer (Header Buffer), whereas the TCP payload may be placed into another buffer (Payload Buffer). This information may also be kept in the FLT and a timer also started.
- both the header and the payload may be temporarily collected at coalescer 131 until either one of the following exemplary termination events occur: a. TCP flags comprising PSH or FIN or RST bits. b.
- SACK selective TCP acknowledgment
- the PSH bit may refer to a control bit that indicates that a segment contains data that must be pushed through to the receiving user.
- the FIN bit may refer to a control bit that indicates that the sender will send no more data or control occupying sequence space.
- the RST bit may refer to a control bit that indicates a reset operation where the receiver should delete the connection without further interaction.
- the ACK bit may refer to a control bit that indicates that the acknowledgment field of the segment specifies the next sequence number the sender of this segment is expecting to receive, hence acknowledging receipt of all previous sequence numbers.
- step 320 when either one of these events happens, the coalescer 131 may modify the TCP header with the new total amount of TCP payload and indicates this large and single TCP segment to the normal TCP stack, along with a total number of TCP segments aggregated and/or a first timestamp option.
- step 322 when the large and single TCP segment reaches the host TCP stack, the host TCP stack processes it as any normal incoming frame.
- the hardware stack that may be located on the NIC is adapted to take the packets off the wire and accumulate or aggregate them independent of the TCP stack running on the host processor. For example, the data portion of a plurality of received packets may be accumulated in the host memory until a single large TCP receive packet of, for example, 8K is created. Once the single large TCP receive packet gets generated, it may be transferred to the host for processing.
- the hardware stack may be adapted to build state and context information when it recognizes the received TCP packets. This significantly reduces the computation intensive tasks associated with TCP stack processing. While the data portion of a plurality of received packets is being accumulated in the host memory, this data remains under the control of the NIC.
- Another embodiment of the invention may provide a machine-readable storage, having stored thereon, a computer program having at least one code section executable by a machine, thereby causing the machine to perform the steps as described above for transparent TCP offload.
- the present invention may be realized in hardware, software, or a combination of hardware and software.
- the present invention may be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited.
- a typical combination of hardware and software may be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
- the present invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods.
- Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
Abstract
Certain aspects of a method and system for transparent transmission control protocol (TCP) offload are disclosed. Aspects of a method may include collecting TCP segments in a network interface card (NIC) processor without transferring state information to a host system. The collected TCP segments may be buffered in a coalescer. The coalescer may verify that the network flow associated with the collected TCP segments has an entry in a flow lookup table (FLT). When the FLT is full, the coalescer may close a current entry and assign the network flow to the available entry. The coalescer may also update information in the FLT. When an event occurs that terminates the collection of TCP segments, the coalescer may generate a single aggregated TCP segment based on the collected TCP segments. The aggregated TCP segment and state information may be communicated to the host system for processing.
Description
METHOD AND SYSTEM FOR TRANSPARENT TCP OFFLOAD
CROSS-REFERENCE TO RELATED APPLICATIONS/INCORPORATION BY
REFERENCE
[01] This patent application makes reference to, claims priority to and claims benefit from United States Provisional Patent Application Serial No. 60/700,544, filed on July 18, 2005.
[02] This application also makes reference to:
United States Application Serial No. (Attorney Docket No.
17546US02) filed on even date herewith;
United States Application Serial No. _ (Attorney Docket No. 17547US02) filed on even date herewith;
United States Application Serial No. _ (Attorney Docket No. 17553US02) filed on even date herewith;
United States Application Serial No. _ (Attorney Docket No. 17554US02) filed on even date herewith;
United States Application Serial No. _ (Attorney Docket No. 17555US02) filed on even date herewith; and
United States Application Serial No. _ (Attorney Docket No. 17556US02) filed on even date herewith.
[03] Each of the above referenced applications is hereby incorporated herein by reference in their entirety.
FIELD OF THE INVENTION
[04] Certain embodiments of the invention relate to processing of TCP data and related TCP information. More specifically, certain embodiments of the invention relate to a method and system for transparent TCP offload.
BACKGROUND OF THE INVENTION
[05] There are different approaches for reducing the processing power of TCP/IP stack processing. In a TCP Offload Engine (TOE), the offloading engine performs all or most of the TCP processing, presenting to the upper layer a stream of data. There may be various disadvantages to this approach. The TTOE is tightly coupled with the operating system and therefore requires solutions that are dependent on the operating system and may require changes in the operating system to support it. The TTOE may require a side by side stack solution, requiring some kind of manual configuration, either by the application, for example, . by explicitly specifying a socket address family for accelerated connections. The TTOE may also require some kind of manual configuration by an IT administrator, for example, by explicitly specifying an IP subnet address for accelerated connections to select which of the TCP flows will be offloaded and the offload engine is very complex as it needs to implement TCP packet processing.
[06] Large segment offload (LSO)/transmit segment offload (TSO) may be utilized to reduce the required host processing power by reducing the transmit packet processing. In this approach the host sends to the NIC, bigger transmit units than the maximum transmission unit (MTU) and the NIC cuts them to segments according to the MTU. Since part of the host processing is linear to the number of transmitted units, this reduces the required host processing power. While being efficient in reducing the transmit packet processing, LSO does not help with receive packet processing. In addition, for each single large transmit unit sent by the host, the host would receive from the far end multiple ACKs, one for each MTU-sized segment. The multiple ACKs require consumption of scarce and expensive bandwidth, thereby reducing throughput and efficiency.
[07] In large receive offload (LRO), a stateless receive offload mechanism, the TCP flows may be split to multiple hardware queues, according to a hash function tnat guarantees that a specific TCP flow would always be directed into the same hardware queue. For each hardware queue, the mechanism takes advantage of interrupt coalescing to scan the queue and aggregate subsequent
packets on the queue belonging to the same TCP flow into a single large receive unit.
[08] While this mechanism does not require any additional hardware from the NIC besides multiple hardware queues, it may have various performance limitations. For example, if the number of flows were larger than the number of hardware queues, multiple flows would fall into the same queue, resulting in no LRO aggregation for that queue. If the number of flows is larger than twice the number of hardware queues, no LRO aggregation is performed on any of the flows. The aggregation may be limited to the amount of packets available to the host in one interrupt period. If the interrupt period is short, and the number of flows is not small, the number of packets that are available to the host CPU for aggregation on each flow may be small, resulting in limited or no LRO aggregation, even if the number of hardware queues is large. The LRO aggregation may be performed on the host CPU, resulting in additional processing. The driver may deliver to the TCP stack a linked list of buffers comprising of a header buffer followed by a series of data buffers, which may require more processing than in the case where all the data is contiguously delivered on one buffer.
[09] Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.
BRIEF SUMMARY OF THE INVENTION
[10] A method and/or system for transparent TCP offload, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.
[11] These and other advantages, aspects and novel features of the present invention, as well as details of an illustrated embodiment thereof, will be more fully understood from the following description and drawings.
BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS
[12] FIG. 1A is a block diagram of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
[13] FIG. 1 B is a block diagram of another exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
[14] FIG. 1C is an alternative embodiment of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention.
[15] FIG. 1 D is a block diagram of an exemplary system for handling transparent TCP offload, in accordance with an embodiment of the invention.
[16] FIG. 1E is a flowchart illustrating exemplary steps for frame reception and placement in accordance with an embodiment of the invention.
[17] FIG. 1 F illustrates an exemplary sequence of TCP/IP frames to be aggregated and not received in order, in accordance with an embodiment of the invention.
[18] FIG. 2A illustrates an exemplary sequence of TCP/IP frames to be aggregated and received in order, in accordance with an embodiment of the invention.
[19] FIG. 2B illustrates an exemplary aggregated TCP/IP frame generated from information in the sequence of TCP frames in FIG. 2A, in accordance with an embodiment of the invention.
[20] FIG. 2C is a diagram illustrating exemplary steps that may be utilized for handling out-of-order data when a packet P3 and a packet P4 arrive out-of- order with respect to the order of transmission, in accordance with an embodiment of the invention.
[21] FIG. 2D is a state diagram illustrating exemplary transparent TCP offload, in accordance with an embodiment of the invention.
[22] FIG. 3 is a flow chart illustrating exemplary steps for transparent TCP offload, in accordance with an embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[23] Certain embodiments of the invention may be found in a method and system for transparent TCP offload. Aspects of the method and system may comprise a coalescer that may be utilized to collect one or more TCP segments within a network interface card (NIC) without individually transferring state information for each of these TCP segments to a host system. The collected TCP segments may be temporarily buffered in the coalescer. The coalescer may verify that the network flow associated with the collected TCP segments has an entry in a flow lookup table (FLT). In instances where the FLT may be full, the coalescer may close a current entry and assign the network flow to the available entry. The coalescer may update information in the FLT. When an event that terminates the collection of TCP segments occurs, the coalescer may generate a single aggregated TCP segment based on the collected TCP segments. The single aggregated TCP segment, which may comprise a plurality of TCP segments, may be referred to as a large receive segment. The aggregated TCP segment and state information may be communicated to the host system for processing.
[24] Under conventional processing, each of the plurality of TCP segments received would have to be individually processed by a host processor in the host system. TCP processing requires extensive CPU processing power in terms of both protocol processing and data placement on the receiver side. Current processing systems and methods involve the transfer of TCP state to a dedicated hardware such as a NIC, where significant changes to host TCP stack and/or underlying hardware are required.
[25] FlG. 1A is a block diagram of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention. Accordingly, the system of FIG. 1A may be adapted to handle transparent TCP offload of transmission control protocol (TCP) datagrams or packets. Referring to FIG. 1A1 the system may comprise, for example, a CPU 102, a memory controller 104, a host memory 106, a host interface 108, network subsystem 110 and an Ethernet 112. The network subsystem 110 may comprise, for example, a transparent TCP-enabled Ethernet Controller (TTEEC) or a transparent TCP
offload engine (TTOE) 114. The network subsystem 110 may comprise, for example, a network interface card (NIC). The host interface 108 may be, for example, a peripheral component interconnect (PCI), PCI-X, PCI-Express, ISA, SCSI or other type of bus. The memory controller 106 may be coupled to the CPU 104, to the memory 106 and to the host interface 108. The host interface 108 may be coupled to the network subsystem 110 via the TTEEC/TTOE 114.
[26] FIG. 1B is a block diagram of another exemplary system for transparent TCP offload, in accordance with an embodiment of the invention. Referring to FIG. 1B, the system may comprise, for example, a CPU 102, a host memory 106, a dedicated memory 116 and a chip set 118. The chip set 118 may comprise, for example, the network subsystem 110 and the memory controller 104. The chip set 118 may be coupled to the CPU 102, to the host memory 106, to the dedicated memory 116 and to the Ethernet 112. The network subsystem 110 of the chip set 118 may be coupled to the Ethernet 112. The network subsystem 110 may comprise, for example, the TTEEC/TTOE 114 that may be coupled to the Ethernet 112. The network subsystem 110 may communicate to the Ethernet 112 via a wired and/or a wireless connection, for example. The wireless connection may be a wireless local area network (WLAN) connection as supported by the IEEE 802.11 standards, for example. The network subsystem 110 may also comprise, for example, an on-chip memory 113. The dedicated memory 116 may provide buffers for context and/or data.
[27] The network subsystem 110 may comprise a processor such as a coalescer 111. The coalescer 111 may comprise suitable logic, circuitry and/or code that may be enabled to handle the accumulation or coalescing of TCP data. In this regard, the coalescer 111 may utilize a flow lookup table (FLT) to maintain information regarding current network flows for which TCP segments are being collected for aggregation. The FLT may be stored in, for example, the network subsystem 110. The FLT may comprise at least one of the following: a source IP address, a destination IP address, a source TCP address, a destination TCP address, for example. In an alternative embodiment of the invention, at least two different tables may be utilized, for example, a table comprising a 4-tuple lookup to classify incoming packets
according to their flow. The 4-tuple lookup table may comprise at least one of the following: a source IP address, a destination IP address, a source TCP address, a destination TCP address, for example. A flow context table may comprise state variables utilized for aggregation such as TCP sequence numbers.
[28] The FLT may also comprise at least one of a host buffer or memory address including a scatter-gather-list (SGL) for non-continuous memory, a cumulative acknowledgments (ACKs), a copy of a TCP header and options, a copy of an IP header and options, a copy of an Ethernet header, and/or accumulated TCP flags, for example. The coalescer 111 may be enabled to generate a single aggregated TCP segment from the accumulated or collected TCP segments when a termination event occurs. The single aggregated TCP segment may be communicated to the host memory 106, for example.
[29] Although illustrated, for example, as a CPU and an Ethernet, the present invention need not be so limited to such examples and may employ, for example, any type of processor and any type of data link layer or physical media, respectively. Accordingly, although illustrated as coupled to the Ethernet 112, the TTEEC or the TTOE 114 of FIG. 1 A may be adapted for any type of data link layer or physical media. Furthermore, the present invention also contemplates different degrees of integration and separation between the components illustrated in FIGS. 1A-B. For example, the TTEEC/TTOE 114 may be a separate integrated chip from the chip set 118 embedded on a motherboard or may be embedded in a NIC. Similarly, the coalescer 111 may be a separate integrated chip from the chip set 118 embedded on a motherboard or may be embedded in a NIC. In addition, the dedicated memory 116 may be integrated with the chip set 118 or may be integrated with the network subsystem 110 of FIG. 1 B.
[30] FIG. 1C is an alternative embodiment of an exemplary system for transparent TCP offload, in accordance with an embodiment of the invention. Referring to FIG. 1C, there is shown a host processor 124, a host memory/buffer 126, a software algorithm block 134 and a NIC block 128. The NIC block 128 may comprise a NIC processor 130, a processor such as a
coalescer 131 and a reduced NIC memory/buffer block 132. The NIC block 128 may communicate with an external network via a wired and/or a wireless connection, for example. The wireless connection may be a wireless local area network (WLAN) connection as supported by the IEEE 802.11 standards, for example.
[31] The coalescer 131 may be a dedicated processor or hardware state machine that may reside in the packet-receiving path. The host TCP stack may comprise software that enables management of the TCP protocol processing and may be part of an operating system, such as Microsoft Windows or Linux. The coalescer 131 may comprise suitable logic, circuitry and/or code that may enable accumulation or coalescing of TCP data. In this regard, the coalescer 131 may utilize a flow lookup table (FLT) to maintain information regarding current network flows for which TCP segments are being collected for aggregation. The FLT may be stored in, for example, the reduced NIC memory/buffer block 132. The coalescer 131 may enable generation of a single aggregated TCP segment from the accumulated or collected TCP segments when a termination event occurs. The single aggregated TCP segment may be communicated to the host memory/buffer 126, for example.
[32] In accordance with certain embodiments of the invention, providing a single aggregated TCP segment to the host for TCP processing significantly reduces overhead processing by the host 124. Furthermore, since there is no transfer of TCP state information, dedicated hardware such as a NIC 128 may assist with the processing of received TCP segments by coalescing or aggregating multiple received TCP segments so as to reduce per-packet processing overhead.
[33] In conventional TCP processing systems, it is necessary to know certain information about a TCP connection prior to arrival of a first segment for that TCP connection. In accordance with various embodiments of the invention, it is not necessary to know about the TCP connection prior to arrival of the first TCP segment since the TCP state or context information is still solely managed by the host TCP stack and there is no transfer of state information between the hardware stack and the software stack at any given time.
[34] In an embodiment of the invention, an offload mechanism may be provided that is stateless from the host stack perspective, while state-full from the offload device perspective, achieving comparable performance gain when compared to TTOE. Transparent TCP offload (TTO) reduces the host processing power required for TCP by allowing the host system to process both receive and transmit data units that are bigger than a MTU. In an exemplary embodiment of the invention, 64 KB of processing data units (PDUs) may be processed rather than 1.5 KB PDUs in order to produce a significant reduction in the packet rate, thus reducing the host processing power for packet processing.
[35] In TTO, no handshake may be utilized between the host operating system and the NIC containing the TTO engine. The TTO engine may operate autonomously in identifying new flows and for offloading. The offload on the transmit side may be similar to LSO, where the host sends big transmission units and the TTO engine cuts them to smaller transmitted packets according to maximum segment size (MSS).
[36] Transparent TCP offload on the receive side may be performed by aggregating a plurality of received packets of the same flow and delivering them to the host as if they were received in one packet - one bigger packet in the case of received data packets, and one aggregate ACK packet in the case of received ACK packets. The processing in the host may be similar to the processing of a big packet that was received. In the case of TCP flow aggregation, rules may be defined to determine whether to aggregate packets. The aggregation rules may be established to allow as much aggregation as possible, without increasing the round trip time such that the decision whether to aggregate depends on the data that is received and the importance of delivering it to the host without delay. The aggregation may be implemented with transmit-receive coupling, wherein the transmitter and receiver are coupled, by utilizing transmission information for offload decisions, and the flow may be treated as a bidirectional flow. The context information of the receive offload in TTO may be maintained per flow. In this regard, for every received packet, the incoming packet header may be utilized to detect the flow it belongs to and this packet updates the context of the flow.
[37] When the transmitter and receiver are coupled, the transmitted network packets may be searched along with the received network packets to determine the particular network flow to which the packet belongs. The transmitted network packet may enable updating of the context of the flow, which may be utilized for receive offload.
[38] FIG. 1D is a block diagram of a system for handling transparent TCP offload, in accordance with an embodiment of the invention. Referring to FIG. 1D, there is shown an incoming packet frame 141, a frame parser 143, an association block 149, a context fetch block 151 , a plurality of on-chip cache blocks 147, a plurality of off-chip storage blocks 160, a plurality of on-chip storage blocks 162, a RX processing block 150, a frame buffer 154, a DMA engine 163, a TCP code block 157, a host bus 165, and a plurality of host buffers 167. The RX processing block 150 may comprise a coalescer 152.
[39] The frame parser 143 may comprise suitable logic, circuitry and/or code that may enable L2 Ethernet processing including, for example, address filtering, frame validity and error detection of the incoming frames 141. Unlike an ordinary Ethernet controller, the next stage of processing may comprise, for example, L3 such as IP processing and L4 such as TCP processing within the frame parser 143. The TTEEC 114 may reduce the host CPU 102 utilization and memory bandwidth, for example, by processing traffic on coalesced TCP/IP flows. The TTEEC 114 may detect, for example, the protocol to which incoming packets belong based on the packet parsing information and tuple 145. If the protocol is TCP, then the TTEEC 114 may detect whether the packet corresponds to an offloaded TCP flow, for example, a flow for which at least some TCP state information may be kept by the TTEEC 114. If the packet corresponds to an offloaded connection, then the TTEEC 114 may direct data movement of the data payload portion of the frame. The destination of the payload data may be determined from the flow state information in combination with direction information within the frame. The destination may be a host memory 106, for example. Finally, the TTEEC 114 may update its internal TCP and higher levels of flow state, without any coordination with the state of the connection on the host TCP stack, and may obtain the host buffer address and length from its internal flow state.
[40] The receive system architecture may comprise, for example, a control path processing 140 and data movement engine 142. The system components above the control path as illustrated in upper portion of FIG. 1D, may be designed to deal with the various processing stages used to complete, for example, the L3/L4 or higher processing with maximal flexibility and efficiency and targeting wire speed. The result of the stages of processing may comprise, for example, one or more packet identification cards that may provide a control structure that may carry information associated with the frame payload data. This may have been generated inside the TTEEC 114 while processing the packet in the various blocks. A data path 142 may move the payload data portions or raw packets 155 of a frame along from, for example, an on-chip packet frame buffer 154 and upon control processing completion, to a direct memory access (DMA) engine 163 and subsequently to the host buffer 167 via the host bus 165 that was chosen via processing. The data path 142 to the DMA engine may comprise packet data are and optional headers 161.
[41] The receiving system may perform, for example, one or more of the following: parsing the TCP/IP headers 145; associating the frame with a TCP/IP flow in the association block 149; fetching the TCP flow context in the context fetch block 151; processing the TCP/IP headers in the RX processing block 150; determining header/data boundaries and updating state 153; mapping the data to a host buffers; and transferring the data via a DMA engine 163 into these host buffers 167. The headers may be consumed on chip or transferred to the host buffers 167 via the DMA engine 163.
[42] The packet frame buffer 154 may be an optional block in the receive system architecture. It may be utilized for the same purpose as, for example, a first-in-first-out (FIFO) data structure is used in a conventional L2 NIC or for storing higher layer traffic for additional processing. The packet frame buffer 154 in the receive system may not be limited to a single instance. As control path 140 processing is performed, the data path 142 may store the data between data processing stages one or more times.
[43] In an exemplary embodiment of the invention, at least a portion of the coalescing operations described for the coalescer 111 in FIG. 1 B and/or for the
coalescer 131 in FIG. 1C may be implemented in a coalescer 152 in the RX processing block 150 in FIG. 1D. In this instance, buffering or storage of TCP data may be performed by, for example, the frame buffer 154. Moreover, the FLT utilized by the coalescer 152 may be implemented using the off-chip storage 160 and/or the on-chip storage 162, for example.
[44] In an embodiment of the invention, a new flow may be detected at some point during the flow lifetime. The flow state is unknown when the new flow is detected and the first packets are utilized to update the flow state until the flow is known to be in-order. A device performing TTO may also support other offload types, for example, TOE, RDMA, or iSCSI offload. In this case, the FLT for TTO may be shared with the connection search for other offload types with each entry in the FLT indicating the offload type for that flow. Packets that belong to flows of other offload types may not be candidates for TTO. Upon detecting a new flow, the flow may be initiated with the basic initialization context. An entry in the FLT with a flow ID may be created.
[45] In another embodiment of the invention, a plurality of segments of the same flow may be aggregated in TTO up to a receive aggregation length (RAL), presenting to the host a bigger segment for processing. If aggregation is allowed, the received packet may be placed in the host memory 126 but will not be delivered to the host. Instead, the host processor 124 may update the context of the flow this packet belongs to. The new incoming packet may either cause the packet to be delivered immediately alone if there were no prior aggregated packets that were not delivered or as a single packet that represents both that packet and the previously received packets. In another embodiment of the invention, the packet may not be delivered but may update the flow's context.
[46] A termination event may occur and the packet may not be aggregated if at least one of the following occurs at the TCP level: (1) the data is not in-order as derived from the received sequence number (SN) and the flow's context; (2) at least one packet with TCP flags other than ACK flag, for example, a PUSH flag is detected; (3) at least one packet with selective acknowledgement (SACK) information is detected; or (4) if the ACK SN received is bigger than the
delivered ACK SN, and requires stopping the aggregation. Similarly, a termination event may occur and the packet may not be aggregated if at least one of the following occurs at the IP level: (1) the type of service (TOS) field in the IP header is different than the TOS field of the previous packets that were aggregated; or (2) the received packet is an IP fragment.
[47] When aggregating a plurality of packets to a single packet, the aggregated packet's header may contain the aggregated header of all the individual packets it contains. In an exemplary embodiment of the invention, a plurality of TCP rules for the aggregation may be as follows. For example, (1) the SN in the aggregated header is the SN of the first or oldest packet; (2) the ACK SN is the SN of the last or youngest segment; (3) the length of the aggregated header is the sum of the lengths of all the aggregated packets; (4) the window in the aggregated header is the window received in the last or youngest aggregated packet; (5) the time stamp (TS) in the aggregated header is the TS received in the first or oldest aggregated packet; (6) the TS-echo in the aggregated header is the TS-echo received in the first or oldest aggregated packet; and (7) the checksum in the aggregated header is the accumulated checksum of all aggregated packets.
[48] In an exemplary embodiment of the invention, a plurality of IP field aggregation rules may be provided. For example, (1) the TOS of the aggregated header may be that of all the aggregated packets; (2) the time-to- live (TTL) of the aggregated header is the minimum of all incoming TTLs; (3) the length of the aggregated header is the sum of the lengths in the aggregated packets; (4) the fragment offset of the aggregated header may be zero for aggregated packets; and (5) the packet ID of the aggregated header is the last ID received.
[49] The received packets may be aggregated until the received packet cannot be aggregated due to the occurrence of a termination event, or if a timeout has expired on that flow, or if the aggregated packet exceeds RAL. The timeout may be implemented by setting a timeout to a value, timeout aggregation value, when the first packet on a flow is placed without delivery. The following packets that are aggregated may not change the timeout. When
the packets are delivered due to timeout expiration the timeout may be canceled and may be set again in the next first packet that is not delivered. Notwithstanding, other embodiments of the invention may provide timeout implementation by periodically scanning all the flows.
[50] In an exemplary embodiment of the invention, the received ACK SN may be relevant to determine the rules to aggregate pure ACKs and to determine the rules to stop aggregation of packets with data due to the received ACK SN. The duplicated pure ACKs may never be aggregated. When duplicated pure ACKs are received, they may cause prior aggregated packets to be delivered and the pure ACK may be delivered immediately separately. The received ACK SN may also be utilized to stop the aggregation and deliver the pending aggregated packet to the host TCP/IP stack.
[51] In an exemplary embodiment of the invention, a plurality of rules may be provided for stopping the aggregation according to the ACK SN. For example, (1) if the number of acknowledged (ACKed) bytes that are not yet delivered, taking into account the received segments and the prior segments that were not delivered exceeds a threshold, ReceiveAckedBytesAggretation, for example, in bytes; or (2) the time from the arrival of the first packet that advanced the received ACK SN exceeds a threshold, TimeoutAckAggregation, for example. For this purpose, a second timer per flow may be required or other mechanisms, such as periodically scanning the flows may be implemented.
[52] In another exemplary embodiment of the invention, the flows may be removed from the host memory if one of the following occurs: (1 ) a reset (RST) flag was detected in the receive side; (2) a finish (FIN) flag was detected in the receive side; (3) there was no receive activity on the flow for a predefined time TerminateNoActivityTime, for example; (4) a KeepAlive packet in the receive direction was not acknowledged. A least recently used (LRU) cache may be used instead of a timeout rule to remove the flows from the host memory.
[53] FIG. 1E is a flowchart illustrating exemplary steps for frame reception and placement in accordance with an embodiment of the invention. Referring to FIG. 1D and FIG. 1E, in step 180, the network subsystem 110 may receive a
frame from, for example, the Ethernet 112. In step 182, a frame parser may parse the frame, for example, to find the L3 and L4 headers. The frame parser may process the L2 headers leading up to the L3 header, for example, IP version 4 (IPv4) header or IP version 6 (IPv6) header. The IP header version field may determine whether the frame carries an IPv4 datagram or an IPv6 datagram.
[54] For example, if the IP header version field carries a value of 4, then the frame may carry an IPv4 datagram. If, for example, the IP header version field carries a value of 6, then the frame may carry an IPv6 datagram. The IP header fields may be extracted, thereby obtaining, for example, the IP source (IP SRC) address, the IP destination (IP DST) address, and the IPv4 header "Protocol" field or the IPv6 "Next Header". If the IPv4 "Protocol" header field or the IPv6 "Next Header" header field carries a value of 6, then the following header may be a TCP header.
[55] The rest of the IP processing may subsequently occur in a manner similar to the processing in a conventional off-the-shelf software stack. Implementation may vary from the use of firmware on an embedded processor to a dedicated, finite state machine (FSM), or a hybrid of a processor and a state machine. The implementation may vary with, for example, multiple stages of processing by one or more processors, state machines, or hybrids. The IP processing may comprise, but is not limited to, extracting information relating to, for example, length, validity and fragmentation. The located TCP header may also be parsed and processed. The parsing of the TCP header may extract information relating to, for example, the source port and the destination port of the particular network flow associated with the received frame.
[56] The TCP processing may be divided into a plurality of additional processing stages. In step 184, the frame may be associated with an end-to- end TCP/IP connection. After L2 processing, in one embodiment, the present invention may provide that the TCP checksum be verified. The flow may be defined by, for example, at least a portion of the following 4-tuple: IP Source • address (IP SRC addr); IP destination address (IP DST addr); TCP source port
number (TCP SRC); and TCP destination port number (TCP DST). The process may be applicable for IPv4 or IPv6 with the choice of the relevant IP address.
[57] As a result of the frame parsing in step 182, the 4-tuple may be completely extracted. Association hardware may compare the received 4-tuple with a list of 4-tuples stored in the TTEEC/TTOE 114. The TTEEC/TTOE 114 may maintain a list of tuples representing, for example, aggregated flows or offloaded connections being managed by the TTEEC/TTOE 114. The memory resources used for storing the association information may be costly for on-chip and off-chip options. Therefore, it is possible that not all of the association information may be housed on chip. A cache may be used to store the most active connections on chip. If a match is found, then the TTEEC/TTOE 114 may be managing the particular TCP/IP flow with the matching 4-tuple.
[58] In step 186, the TCP flow context may be fetched. In step 188, the TCP/IP headers may be processed. In step 190, header/data boundaries may be determined. In step 192, a coalescer may collect or accumulate a plurality of frames that may be associated with a particular network flow. The collected TCP segments and the collected information regarding the TCP/IP connection may be utilized to generate a TCP/IP frame comprising a single aggregated TCP segment, for example. In step 194, when a termination event occurs, the process may proceed to step 196. A termination event may be an incident, instance, and/or a signal that indicates to the coalescer that collection or accumulation of TCP segments may be completed and that the single aggregated TCP segment may be communicated to a host system for processing. In step 196, payload data corresponding to the single aggregated TCP segment may be mapped to the host buffer. In step 198, data from the single aggregated TCP segment may be transferred to the host buffer. Returning to step 194, when a termination event does not occur, the process may proceed to step 180 and a next received frame may be processed.
[59] FIG. 1F illustrates an exemplary sequence of TCP/IP frames to be aggregated and not received in order, in accordance with an embodiment of the invention. Referring to FIG. 1F, there are shown a first TCP/IP frame 202, a
second TCP/IP frame 204, a third TCP/IP frame 206, and a fourth TCP/IP frame 208. Each TCP/IP frame shown may comprise an Ethernet header 200a, an IP header 200b, a TCP header 200c, and a TCP options 20Od. While not shown in FIG. 1 F, each of the TCP/IP frames may comprise a payload portion that contains TCP segments comprising data being transferred. The Ethernet header 200a may have a value, enet_hdr, for the TCP/IP frames. The IP header 200b may comprise a plurality of fields. In this regard, the IP header 200b may comprise a field, IP_LEN, which may be utilized to indicate a number of bytes in the frames. In this example, there are 1448 TCP payload packets in each of the first TCP/IP frame 202, the second TCP/IP frame 204, the third TCP/IP frame 206, and the fourth TCP/IP frame 208.
[60] The IP header 200b may also comprise an identification field, ID, which may be utilized to identify the frame, for example. In this example, ID = 100 for the first TCP/IP frame 202, ID = 101 for the second TCP/IP frame 204, ID = 103 for the third TCP/IP frame 206, and ID = 102 for the fourth TCP/IP frame 208. The IP header 200b may also comprise additional fields such as an IP header checksum field, ip_csm, a source field, ip_src, and a destination field, ip_dest, for example. In this example, the value of ip_src and ip_dest may be the same for all frames, while the value of the IP header checksum field may be ip_csmθ for the first TCP/IP frame 202, ip_csm1 for the second TCP/IP frame 204, ip_csm3 for the third TCP/IP frame 206, and ip_csm2 for the fourth TCP/IP frame 208.
[61] The TCP header 200c may comprise a plurality of fields. For example, the TCP header 200c may comprise a source port field, src_prt, a destination port field, dest_prt, a TCP sequence field, SEQ, an acknowledgment field, ACK, a flags field, FLAGS, an advertised window field, WIN, and a TCP header checksum field, tcp_csm. In this example, the value of src_prt, dest_prt, FLAGS, and WIN may be the same for all frames. For the first TCP/IP frame 202, SEQ = 100, ACK = 5000, and the TCP header checksum field is tcp_csmθ. For the second TCP/IP frame 204, SEQ = 1548, ACK = 5100, and the TCP header checksum field is tcp_csm1. For the third TCP/IP frame 206, SEQ = 4444, ACK = 5100, and the TCP header checksum field is tcp_csm3.
For the fourth TCP/IP frame 208, SEQ = 2996, ACK = 5100, and the TCP header checksum field is tcp_csm2.
[62] The TCP options 20Od may comprise a plurality of fields. For example, the TCP options 20Od may comprise a time stamp indicator, referred to as timestamp, which is associated with the TCP frame. In this example, the value of the time stamp indicator may be timestampO for the first TCP/IP frame 202, timestampi for the second TCP/IP frame 204, timestamp3 for the third TCP/IP frame 206, and timestamp2 for the fourth TCP/IP frame 208.
[63] The exemplary sequence of TCP/IP frames shown in FIG. 1 F is received out-of-order with respect to the order of transmission by the network subsystem 110, for example. Information comprised in the ID field in the IP header 200b and/or in the timestamp field in the TCP options 20Od may indicate that the third TCP/IP frame 206 and the fourth TCP/IP frame 208 were received in a different order from the order of transmission. In this instance, the fourth TCP/IP frame 208 was transmitted after the second TCP/IP frame 204 and before the third TCP/IP frame 206. A coalescer, such as the coalescers described in FIGS. 1B-1E may obtain information from the TCP/IP frames and may generate a single TCP/IP frame by coalescing the information received. In this regard, the coalescer may utilize a FLT to store and/or update at least a portion of the information received from the TCP/IP frames. The coalescer may also utilize available memory to store or buffer the payload of the aggregated /IP frame.
[64] FlG. 2A illustrates an exemplary sequence of TCP/IP frames to be aggregated and received in order, in accordance with an embodiment of the invention. Referring to FIG. 2A, there are shown a first TCP/IP frame 202, a second TCP/IP frame 204, a third TCP/IP frame 206, and a fourth TCP/IP frame 208. Each TCP/IP frame shown may comprise an Ethernet header 200a, an IP header 200b, a TCP header 200c, and a TCP options 20Od. While not shown in FIG. 2A, each of the TCP/IP frames may comprise a payload portion that contains TCP segments comprising data being transferred. The Ethernet header 200a may have a value, enet__hdr, for the TCP/IP frames. The IP header 200b may comprise a plurality of fields. In this regard, the IP header
200b may comprise a field, IP_LEN, which may be utilized to indicate a number of bytes in the frames. In this example, there are 1448 TCP payload packets in each of the first TCP/IP frame 202, the second TCP/IP frame 204, the third TCP/IP frame 206, and the fourth TCP/IP frame 208.
[65] The IP header 200b may also comprise an identification field, ID, which may be utilized to identify the frame, for example. In this example, ID = 100 for the first TCP/IP frame 202, ID = 101 for the second TCP/IP frame 204, ID = 102 for the third TCP/IP frame 206, and ID = 103 for the fourth TCP/IP frame 208. The IP header 200b may also comprise additional fields such as an IP header checksum field, ip_csm, a source field, ip_src, and a destination field, ip_dest, for example. In this example, the value of ip_src and ip_dest may be the same for all frames, while the value of the IP header checksum field may be ip_csmθ for the first TCP/IP frame 202, ip_csm1 for the second TCP/IP frame 204, ip_csm2 for the third TCP/IP frame 206, and ip_csm3 for the fourth TCP/IP frame 208.
[66] The TCP header 200c may comprise a plurality of fields. For example, the TCP header 200c may comprise a source port field, src_prt, a destination port field, dest_prt, a TCP sequence field, SEQ, an acknowledgment field, ACK, a flags field, FLAGS, an advertised window field, WIN, and a TCP header checksum field, tcp_csm. In this example, the value of src_prt, dest_prt, FLAGS, and WIN may be the same for all frames. For the first TCP/IP frame 202, SEQ = 100, ACK = 5000, and the TCP header checksum field is tcp_csmθ. For the second TCP/IP frame 204, SEQ = 1548, ACK = 5100, and the TCP header checksum field is tcp_csm1. For the third TCP/IP frame 206, SEQ = 4444, ACK = 5100, and the TCP header checksum field is tcp_csm2. For the fourth TCP/IP frame 208, SEQ = 2996, ACK = 5100, and the TCP header checksum field is tcp_csm3.
[67] The TCP options 20Od may comprise a plurality of fields. For example, the TCP options 20Od may comprise a time stamp indicator, referred to as timestamp, which is associated with the TCP frame. In this example, the value of the time stamp indicator may be timestampO for the first TCP/IP frame
202, timestampi for the second TCP/IP frame 204, timestamp2 for the third TCP/IP frame 206, and timestamp3 for the fourth TCP/IP frame 208.
[68] The exemplary sequence of TCP/IP frames shown in FIG. 2A is received in-order with respect to the order of transmission by the network subsystem 110, for example. A coalescer, such as the coalescers described in FIGS. I B- IE may obtain information from the TCP/IP frames and may generate a single TCP/IP frame by coalescing the information received. In this regard, the coalescer may utilize a FLT . to store and/or update at least a portion of the information received from the TCP/IP frames. The coalescer may also utilize available memory to store or buffer the payload of the aggregated /IP frame.
[69] FIG. 2B illustrates an exemplary aggregated TCP/IP frame generated from information in the sequence of TCP frames in FIG. 2A, in accordance with an embodiment of the invention. Referring to FlG. 2B, there is shown a single TCP/IP frame 210 that may be generated by a coalescer from the sequence of TCP/IP frames received in FIG. 2A. The TCP/IP frame 210 may comprise an Ethernet header 200a, an IP header 200b, a TCP header 200c, and a TCP options 20Od. While not shown, the TCP/IP frame 210 may also comprise a payload that contains TCP segments comprising actual data for received TCP/IP frames. The fields in the Ethernet header 200a, the IP header 200b, the TCP header 200c, and the TCP options 20Od in the TCP/IP frame 210 may be substantially similar to the fields in the TCP/IP frames in FIG. 2A. For the TCP/IP frame 210, the total number of packets in the payload is IP_LEN = 5844, which corresponds to the sum of the packets for all four TCP/IP frames in FIG. 2A (1448*4 + 52), for example. For the TCP/IP frame 210, the value of ID = 100, which corresponds to the ID value of the first TCP/IP frame 202. Moreover, the value of the time stamp indicator is timestampO, which corresponds to the time stamp indicator of the first TCP/IP frame 202. The TCP/IP frame 210 may be communicated or transferred to a host system for TCP processing, for example.
[70] FIG. 2C is a diagram illustrating exemplary steps that may be utilized for handling out-of-order data when a packet P3 and a packet P4 arrive out-of- order with respect to the order of transmission, in accordance with an
embodiment of the invention. Regarding FIG. 2C, the packets P3 and P4 may arrive in-order with respect to each other at the NIC 128 but before the arrival of a packet P2, as shown in the actual receive FRX traffic pattern 200. The packets P3 and P4 may correspond to a fourth packet and a fifth packet within an isle 211 , respectively, in a TCP transmission sequence. In this case, there is a gap or time interval between the end of the packet P1 and the beginning of the packet P3 in the actual receive RX traffic pattern 200. A first disjoint portion in the TCP transmission sequence may result from the arrival of the packets P3 and P4 as shown in the TCP receive sequence space 202 after the isle 213 comprising packets PO and P1. The rightmost portion of isle 211 rcv_nxt_R may be represented as (rcv_nxt_L + (length of isle)), where rcv_nxt_L is the leftmost portion of isle 211 and the length of isle is the sum of the lengths of packets P3 and P4.
[71] FIG. 2D is a state diagram illustrating exemplary transparent TCP offload, in accordance with an embodiment of the invention. Referring to FIG. 2D, there is shown a plurality of exemplary flow states, namely, in order state 226, Out-Of-Order (OOO) state 224, or an unknown state 222. In transition state 228, the unknown state 222 may be detected for a flow for which a 3-way TCP handshake has not been detected or at some point in the life of the flow other than the initialization phase.
[72] The TCP 3-way handshake begins with a synchronize (SYN) segment containing an initial send sequence number (ISN) being chosen by, and sent from a first host. This sequence number may be the starting sequence number of the data in that packet and may increment for every byte of data sent within the segment. When the second host receives the SYN with the sequence number, it may transmit a SYN segment with its own totally independent ISN number in the sequence number field along with an acknowledgment field. This acknowledgment (ACK) field may inform the recipient that its data was received at the other end and it expects the next segment of data bytes to be sent, and may be referred to as the SYN-ACK. When the first host receives this SYN-ACK segment it may send an ACK segment containing the next sequence number, called forward acknowledgement and is received by the second host. The ACK segment may be identified by the ACK field being set.
Segments that are not acknowledged within a certain time span may be retransmitted.
[73] When a flow is transparent TCP offloaded, the flow may not move from the in order state 226 and OOO state 224 to the unknown state 222 unless it gets removed and detected again. In transition state 230, the state diagram may track the out-of-order isle sequence number boundaries using, for example, the parameters rcv_nxt_R and rcv_nxt_L as illustrated in FIG. 2C. The first ingress segment may be referred to as an isle, for example, isle 213 (FIG. 2C) and the ordering state may be set to OOO state 224. The rightmost portion of isle rcv_nxt_R may be represented as (rcv_nxt_L + (length of isle)), where rcv_nxt_L is the leftmost portion of isle and the length of isle is the sum of the lengths of packets in the isle.
[74] In transition state 232, the NIC 128 may not have the local stack acknowledgment information as the transmitter and receiver are decoupled. The ordering state may be modified from OOO state 224 to in-order state 226 whenever the isle length is greater than a threshold. The threshold may be set according to the local host stack maximum receive window because the far end may not send more data than this value without receiving an ACK.
[75] In transition state 234, the initial ordering state may be set to the in order state 226, if the new flow is detected with the TCP 3-way handshake. In transition state 236, the rcv_nxt_R may be utilized to check the condition of ingress packets according to the following algorithm.
If (in_packet_sn==rcv_nxt_R) // when isle is increased update rcv_nxt_L rcv_nxt_R = in_packet_sn + in_packet_len
[76] In transition state 238, the ordering state may be modified from in order state 226 to OOO state 224 if the isle length is not equal to rcv_nxt_R. The value of rcv_nxt_R may be used to check the condition of ingress packets according to the following algorithm.
If (in_packet_sn != rcv_nxt_R) rcv_nxt_L = in_packet_sn
rcv_nxt_R = in_packet_sn + in_packet_len change state to OOO 224.
[77] In transition state 240, during OOO state 224, the boundaries of the highest OOO isle may be tracked for every ingress packet using the following exemplary algorithm.
If (in_packet_sn==rcv_nxt_R) // when the isle is increased update rcv_nxt_L rcv_nxt_R = in_packet_sn + in_packet_len else if (in_packet_sn > rcv_nxt_R) // when a new higher isle is generated rcv_nxt_R = in_packet_sn + in_packet_len rcv_nxt_L = in_packet_sn
[78] FIG. 3 is a flow chart illustrating exemplary steps for transparent TCP offload, in accordance with an embodiment of the invention. Referring to FIG. 3, in step 302, for every packet received, the coalescer 131, for example, may classify the packets into non-TCP and TCP packets by examining the protocol headers. In step 304, for non-TCP packets or packet without correct checksum, the coalescer 131 may continue processing without change. In step 306, the coalescer 131 may compute the TCP checksum of the payload. In step 308, for TCP packets with valid checksum, the coalescer 131 first searches the flow lookup table (FLT) using a tuple comprising IP source address, IP destination address, source TCP port and destination TCP port, to determine whether the packet belongs to a connection that the coalescer 131 is already aware of.
[79] In step 310, in instances where the search fails, this packet may belong to a connection that is not known to the coalescer 131. The coalescer 131 may determine whether there is any TCP payload. If there is no TCP payload, for example, pure TCP ACK, the coalescer 131 may stop further processing and allow processing of the packet through a normal processing path and add an entry in the FLT. In step 312, if there is TCP payload and the connection is not in the FLT, the coalescer 131 may create a new entry in the FLT for this
connection. This operation may involve retiring an entry in the FLT when the FLT is full. The FLT retirement may immediately stop any further coalescing and provides an indication of any aggregated TCP segment to host TCP stack.
[80] In step 314, if the newly created/replaced FLT entry, in addition to tuple, a TCP sequence number, a TCP acknowledgement number, a length of the TCP payload, and a timestamp option if present, may be recorded. In step 316, any header before TCP payload may be placed into a buffer (Header Buffer), whereas the TCP payload may be placed into another buffer (Payload Buffer). This information may also be kept in the FLT and a timer also started. In step 318, both the header and the payload may be temporarily collected at coalescer 131 until either one of the following exemplary termination events occur: a. TCP flags comprising PSH or FIN or RST bits. b. An amount of TCP payload exceeds a threshold or maximum IP datagram size. c. A timer expires. d. A FLT table is full and one of the current network flow entries is replaced with an entry associated with a new network flow. e. A first IP fragment containing the same tuple is detected. f. A transmit window size changes. g. A change in TCP acknowledgement (ACK) number exceeds an ACK threshold. h. A number of duplicated ACK exceeds a duplicated ACK threshold, i. A selective TCP acknowledgment (SACK).
[81] In this regard, the PSH bit may refer to a control bit that indicates that a segment contains data that must be pushed through to the receiving user. The FIN bit may refer to a control bit that indicates that the sender will send no more data or control occupying sequence space. The RST bit may refer to a control bit that indicates a reset operation where the receiver should delete the connection without further interaction. The ACK bit may refer to a control bit
that indicates that the acknowledgment field of the segment specifies the next sequence number the sender of this segment is expecting to receive, hence acknowledging receipt of all previous sequence numbers.
[82] In step 320, when either one of these events happens, the coalescer 131 may modify the TCP header with the new total amount of TCP payload and indicates this large and single TCP segment to the normal TCP stack, along with a total number of TCP segments aggregated and/or a first timestamp option. In step 322, when the large and single TCP segment reaches the host TCP stack, the host TCP stack processes it as any normal incoming frame.
[83] The hardware stack that may be located on the NIC is adapted to take the packets off the wire and accumulate or aggregate them independent of the TCP stack running on the host processor. For example, the data portion of a plurality of received packets may be accumulated in the host memory until a single large TCP receive packet of, for example, 8K is created. Once the single large TCP receive packet gets generated, it may be transferred to the host for processing. In this regard, the hardware stack may be adapted to build state and context information when it recognizes the received TCP packets. This significantly reduces the computation intensive tasks associated with TCP stack processing. While the data portion of a plurality of received packets is being accumulated in the host memory, this data remains under the control of the NIC.
[84] Although the handling of a single TCP connection is illustrated, the invention is not limited in this regard. Accordingly, various embodiments of the invention may provide support for a plurality of TCP connections over multiple physical networking ports.
[85] Another embodiment of the invention may provide a machine-readable storage, having stored thereon, a computer program having at least one code section executable by a machine, thereby causing the machine to perform the steps as described above for transparent TCP offload.
[86] Accordingly, the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in at least one computer system, or in
a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
[87] The present invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
[88] While the present invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims.
Claims
1. A method for handling network processing of network information, the method comprising: collecting at least one transmission control protocol (TCP) segment received for a particular network flow via a network interface card (NIC) processor without transferring state information regarding said particular network flow to a host system every time said at least one TCP segment is received; generating new TCP segment comprising said collected at least one TCP segment after a termination event occurs; and communicating said generated new TCP segment and state information for said new TCP segment to said host system for processing.
2. The method according to claim 1 , further comprising generating said new TCP segment by aggregating at least a portion of a plurality of said collected TCP segments for said particular network flow.
3. The method according to claim 1, further comprising updating information in a generated entry for said particular network flow in a flow lookup table (FLT).
4. The method according to claim 3, wherein said FLT entry comprises at least one of the following: a tuple comprising: an Internet protocol (IP) source address; an IP destination address; a source TCP port; and a destination TCP port; a TCP sequence number; a TCP acknowledgment number; and a TCP payload length.
5. The method according to claim 1 , further comprising generating a TCP header for said generated new TCP segment that indicates a total number of TCP payload bytes associated with said collected at least one TCP segment.
6. The method according to claim 1 , further comprising generating a TCP header for said generated new TCP segment that indicates a first timestamp option of said collected at least one TCP segment.
7. The method according to claim 6, wherein a length of said generated TCP header for said generated new TCP segment is a sum of lengths of said collected at least one TCP segment.
8. The method according to claim 6, wherein a sequence number of said generated TCP header for said generated new TCP segment indicates a first sequence number of said collected at least one TCP segment.
9. The method according to claim 1 , wherein said termination event occurs when at least one of the following occurs: a TCP/Internet Protocol (TCP/IP) frame associated with said particular network flow comprises a TCP flag with at least one of: a PSH bit, a FIN bit, and a RST bit; a TCP/IP frame associated with said particular network flow comprises a TCP payload length that is equal to or greater than a maximum IP datagram size; a timer associated with said collecting of said at least one TCP segment expires; a new entry in a flow lookup table (FLT) is generated when said FLT is full; a first IP fragment associated with said particular network flow is received; a transmit window is modified; a change in a number of TCP acknowledgments (ACKS) is greater than or equal to an ACK threshold; a TCP/IP frame associated with said particular network flow comprises a selective TCP acknowledgment (SACK); and a TCP/IP frame associated with said particular network flow comprises a number of duplicated TCP acknowledgments that is equal to or greater than a duplicated ACK threshold.
10. The method accordincpto claim 1 , wherein in said new TCP segment comprises an aggregated TCP segment.
11. The method according to claim 1 , further comprising detecting a state of said particular network flow to be at least one of: an in order state, an out of order state, and an unknown state.
12. The method according to claim 1 , further comprising if an isle length of said collected at least one TCP segment is greater than a threshold, modifying said state of said particular network flow from said out of order state to said in order state.
13. The method according to claim 1 , further comprising initializing a state of said particular network flow to be an unknown state.
14. The method according to claim 13, further comprising updating said initialized state based on said collected at least one TCP segment.
15. A system for handling network processing of network information, the system comprising: a network interface card (NIC) processor that enables collection of at least one transmission control protocol (TCP) segment received for a particular network flow without transferring state information regarding said particular network flow to a host system every time said at least one TCP segment is received; said NIC processor enables generation of a new TCP segment comprising said collected at least one TCP segment after a termination event occurs; and said NIC processor communicates said generated new TCP segment and state information for said new TCP segment to said host system for processing.
16. The system according to claim 15, wherein said NIC processor enables generation of said new TCP segment by aggregating at least a portion of a plurality of said collected TCP segments for said particular network flow.
17. The system according to claim 15, wherein said NIC processor enables updating information in a generated entry for said particular network flow in a flow lookup table (FLT).
18. The system according to claim 17, wherein said FLT entry comprises at least one of the following: a tuple comprising: an Internet protocol (IP) source address; an IP destination address; a source TCP port; and a destination TCP port; a TCP sequence number; a TCP acknowledgment number; and a TCP payload length.
19. The system according to claim 15, wherein said NIC processor enables generation of a TCP header for said generated new TCP segment that indicates a total number of TCP payload bytes associated with said collected at least one TCP segment.
20. The system according to claim 15, wherein said NIC processor enables generation of a TCP header for said generated new TCP segment that indicates a first timestamp option of said collected at least one TCP segment.
21. The system according to claim 20, wherein a length of said generated TCP header for said generated new TCP segment is a sum of lengths of said collected at least one TCP segment.
22. The system according to claim 20, wherein a sequence number of said generated TCP header for said generated new TCP segment indicates a first sequence number of said collected at least one TCP segment.
23. The system according to claim 15, wherein said termination event occurs when at least one of the following occurs: a TCP/Internet protocol (TCP/IP) frame associated with said particular network flow comprises a TCP flag with at least one of: a PSH bit, a FIN bit, and a RST bit; a TCP/IP frame associated with said particular network flow comprises a TCP payload length that is equal to or greater than a maximum IP datagram size; a timer associated with said collecting of said at least one TCP segment expires; a new entry in a flow lookup table (FLT) is generated when said FLT is full; a first IP fragment associated with said particular network flow is received; a transmit window is modified; a change in a number of TCP acknowledgments (ACKS) is greater than or equal to an ACK threshold; a TCP/IP frame associated with said particular network flow comprises a selective TCP acknowledgment (SACK); and a TCP/IP frame associated with said particular network flow comprises a number of duplicated TCP acknowledgments that is equal to or greater than a duplicated ACK threshold.
24. The system according to claim 15, wherein said NIC processor comprises a coalescer.
25. The system according to claim 15, wherein said NIC processor enables detection of a state of said particular network flow to be at least one of: an in order state, an out of order state, and an unknown state.
26. The system according to claim 25, wherein said NIC processor enables modification of said state of said particular network flow from said out of order state to said in order state, if an isle length of said collected at least one TCP segment is greater than a threshold.
27. The system according to claim 15, wherein said NIC processor enables initialization of a state of said particular network flow to be an unknown state.
28. The system according to claim 27, wherein said NIC processor enables updating of said initialized state based on said collected at least one TCP segment.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006800262474A CN101253745B (en) | 2005-07-18 | 2006-07-18 | Method and system for transparent TCP offload |
EP06848596A EP1917782A2 (en) | 2005-07-18 | 2006-07-18 | Method and system for transparent tcp offload |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US70054405P | 2005-07-18 | 2005-07-18 | |
US60/700,544 | 2005-07-18 |
Publications (3)
Publication Number | Publication Date |
---|---|
WO2007069095A2 true WO2007069095A2 (en) | 2007-06-21 |
WO2007069095A8 WO2007069095A8 (en) | 2007-08-23 |
WO2007069095A3 WO2007069095A3 (en) | 2007-12-06 |
Family
ID=38163302
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2006/004098 WO2007069095A2 (en) | 2005-07-18 | 2006-07-18 | Method and system for transparent tcp offload |
Country Status (5)
Country | Link |
---|---|
US (7) | US7693138B2 (en) |
EP (1) | EP1917782A2 (en) |
KR (1) | KR100973201B1 (en) |
CN (1) | CN101253745B (en) |
WO (1) | WO2007069095A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2595351A1 (en) * | 2011-11-15 | 2013-05-22 | Eaton Industries GmbH | Device for a digital transfer system, digital transfer system and data transfer method |
Families Citing this family (137)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8724485B2 (en) | 2000-08-30 | 2014-05-13 | Broadcom Corporation | Home network system and method |
US9094226B2 (en) | 2000-08-30 | 2015-07-28 | Broadcom Corporation | Home network system and method |
ATE485650T1 (en) * | 2000-08-30 | 2010-11-15 | Tmt Coaxial Networks Inc | METHOD AND SYSTEM FOR A HOME NETWORK |
US7978598B1 (en) * | 2002-03-01 | 2011-07-12 | Cisco Technology, Inc. | Connection replication |
US7007103B2 (en) * | 2002-04-30 | 2006-02-28 | Microsoft Corporation | Method to offload a network stack |
US7616664B2 (en) * | 2005-02-18 | 2009-11-10 | Hewlett-Packard Development Company, L.P. | System and method of sending video and audio data over a network |
US7693138B2 (en) * | 2005-07-18 | 2010-04-06 | Broadcom Corporation | Method and system for transparent TCP offload with best effort direct placement of incoming traffic |
US7724658B1 (en) | 2005-08-31 | 2010-05-25 | Chelsio Communications, Inc. | Protocol offload transmit traffic management |
US7616563B1 (en) | 2005-08-31 | 2009-11-10 | Chelsio Communications, Inc. | Method to implement an L4-L7 switch using split connections and an offloading NIC |
US7660306B1 (en) | 2006-01-12 | 2010-02-09 | Chelsio Communications, Inc. | Virtualizing the operation of intelligent network interface circuitry |
US7660264B1 (en) | 2005-12-19 | 2010-02-09 | Chelsio Communications, Inc. | Method for traffic schedulign in intelligent network interface circuitry |
US7506080B2 (en) * | 2005-09-16 | 2009-03-17 | Inter Corporation | Parallel processing of frame based data transfers |
US7735099B1 (en) * | 2005-12-23 | 2010-06-08 | Qlogic, Corporation | Method and system for processing network data |
EP1835692B1 (en) * | 2006-03-13 | 2018-08-08 | Telefonaktiebolaget LM Ericsson (publ) | Method and system for distributing service messages from clients to service applications |
US20070246406A1 (en) | 2006-03-31 | 2007-10-25 | Dibel Kevin R | Tangential flow filtration apparatuses, systems, and processes for the separation of compounds |
US9794378B2 (en) * | 2006-11-08 | 2017-10-17 | Standard Microsystems Corporation | Network traffic controller (NTC) |
US20080120426A1 (en) * | 2006-11-17 | 2008-05-22 | International Business Machines Corporation | Selective acceleration of transport control protocol (tcp) connections |
US7782850B2 (en) * | 2006-11-20 | 2010-08-24 | Broadcom Corporation | MAC to PHY interface apparatus and methods for transmission of packets through a communications network |
US7742495B2 (en) * | 2006-11-20 | 2010-06-22 | Broadcom Corporation | System and method for retransmitting packets over a network of communication channels |
US8090043B2 (en) | 2006-11-20 | 2012-01-03 | Broadcom Corporation | Apparatus and methods for compensating for signal imbalance in a receiver |
US20080133654A1 (en) * | 2006-12-01 | 2008-06-05 | Chei-Yol Kim | Network block device using network asynchronous i/o |
US7849214B2 (en) * | 2006-12-04 | 2010-12-07 | Electronics And Telecommunications Research Institute | Packet receiving hardware apparatus for TCP offload engine and receiving system and method using the same |
US8161532B2 (en) * | 2007-04-04 | 2012-04-17 | Microsoft Corporation | Operating system independent architecture for subscription computing |
US8935406B1 (en) | 2007-04-16 | 2015-01-13 | Chelsio Communications, Inc. | Network adaptor configured for connection establishment offload |
US8589587B1 (en) * | 2007-05-11 | 2013-11-19 | Chelsio Communications, Inc. | Protocol offload in intelligent network adaptor, including application level signalling |
US8060644B1 (en) * | 2007-05-11 | 2011-11-15 | Chelsio Communications, Inc. | Intelligent network adaptor with end-to-end flow control |
US8345553B2 (en) | 2007-05-31 | 2013-01-01 | Broadcom Corporation | Apparatus and methods for reduction of transmission delay in a communication network |
US7715362B1 (en) * | 2007-11-23 | 2010-05-11 | Juniper Networks, Inc. | Identification fragment handling |
KR100936918B1 (en) * | 2007-12-17 | 2010-01-18 | 한국전자통신연구원 | TCP Offload Engine Apparatus and Method for System Call Processing for Static File Transmission |
US20100017513A1 (en) * | 2008-07-16 | 2010-01-21 | Cray Inc. | Multiple overlapping block transfers |
US8341286B1 (en) * | 2008-07-31 | 2012-12-25 | Alacritech, Inc. | TCP offload send optimization |
US9112717B2 (en) | 2008-07-31 | 2015-08-18 | Broadcom Corporation | Systems and methods for providing a MoCA power management strategy |
US8238227B2 (en) | 2008-12-22 | 2012-08-07 | Broadcom Corporation | Systems and methods for providing a MoCA improved performance for short burst packets |
US8254413B2 (en) | 2008-12-22 | 2012-08-28 | Broadcom Corporation | Systems and methods for physical layer (“PHY”) concatenation in a multimedia over coax alliance network |
US8213309B2 (en) | 2008-12-22 | 2012-07-03 | Broadcom Corporation | Systems and methods for reducing latency and reservation request overhead in a communications network |
US20100165838A1 (en) * | 2008-12-30 | 2010-07-01 | Yury Bakshi | Method and apparatus for improving data throughput in a network |
US20100238932A1 (en) * | 2009-03-19 | 2010-09-23 | Broadcom Corporation | Method and apparatus for enhanced packet aggregation |
US8553547B2 (en) * | 2009-03-30 | 2013-10-08 | Broadcom Corporation | Systems and methods for retransmitting packets over a network of communication channels |
US20100254278A1 (en) | 2009-04-07 | 2010-10-07 | Broadcom Corporation | Assessment in an information network |
US8730798B2 (en) | 2009-05-05 | 2014-05-20 | Broadcom Corporation | Transmitter channel throughput in an information network |
US8867355B2 (en) | 2009-07-14 | 2014-10-21 | Broadcom Corporation | MoCA multicast handling |
US8942250B2 (en) | 2009-10-07 | 2015-01-27 | Broadcom Corporation | Systems and methods for providing service (“SRV”) node selection |
US9015318B1 (en) | 2009-11-18 | 2015-04-21 | Cisco Technology, Inc. | System and method for inspecting domain name system flows in a network environment |
US9009293B2 (en) | 2009-11-18 | 2015-04-14 | Cisco Technology, Inc. | System and method for reporting packet characteristics in a network environment |
US9148380B2 (en) * | 2009-11-23 | 2015-09-29 | Cisco Technology, Inc. | System and method for providing a sequence numbering mechanism in a network environment |
US8737262B2 (en) * | 2009-11-24 | 2014-05-27 | Red Hat Israel, Ltd. | Zero copy transmission with raw packets |
US9535732B2 (en) * | 2009-11-24 | 2017-01-03 | Red Hat Israel, Ltd. | Zero copy transmission in virtualization environment |
CN102648455B (en) * | 2009-12-04 | 2015-11-25 | 日本电气株式会社 | Server and stream control routine |
US8792495B1 (en) | 2009-12-19 | 2014-07-29 | Cisco Technology, Inc. | System and method for managing out of order packets in a network environment |
US8611327B2 (en) | 2010-02-22 | 2013-12-17 | Broadcom Corporation | Method and apparatus for policing a QoS flow in a MoCA 2.0 network |
US8514860B2 (en) | 2010-02-23 | 2013-08-20 | Broadcom Corporation | Systems and methods for implementing a high throughput mode for a MoCA device |
US8428087B1 (en) * | 2010-09-17 | 2013-04-23 | Amazon Technologies, Inc. | Framework for stateless packet tunneling |
US9705730B1 (en) | 2013-05-07 | 2017-07-11 | Axcient, Inc. | Cloud storage using Merkle trees |
US8924360B1 (en) | 2010-09-30 | 2014-12-30 | Axcient, Inc. | Systems and methods for restoring a file |
US8589350B1 (en) | 2012-04-02 | 2013-11-19 | Axcient, Inc. | Systems, methods, and media for synthesizing views of file system backups |
US9235474B1 (en) * | 2011-02-17 | 2016-01-12 | Axcient, Inc. | Systems and methods for maintaining a virtual failover volume of a target computing system |
US10284437B2 (en) | 2010-09-30 | 2019-05-07 | Efolder, Inc. | Cloud-based virtual machines and offices |
US8954544B2 (en) | 2010-09-30 | 2015-02-10 | Axcient, Inc. | Cloud-based virtual machines and offices |
US8787303B2 (en) | 2010-10-05 | 2014-07-22 | Cisco Technology, Inc. | Methods and apparatus for data traffic offloading at a router |
JP5204195B2 (en) * | 2010-10-29 | 2013-06-05 | 株式会社東芝 | Data transmission system and data transmission program |
US8495262B2 (en) * | 2010-11-23 | 2013-07-23 | International Business Machines Corporation | Using a table to determine if user buffer is marked copy-on-write |
CN102111403B (en) * | 2010-12-17 | 2014-05-21 | 曙光信息产业(北京)有限公司 | Method and device for acquiring transmission control protocol (TCP) connection data at high speed |
CN102075416B (en) * | 2010-12-17 | 2014-07-30 | 曙光信息产业(北京)有限公司 | Method for realizing TCP (transmission control protocol) connection data buffer by combining software and hardware |
CN102082688B (en) * | 2010-12-17 | 2014-08-13 | 曙光信息产业(北京)有限公司 | Method for realizing management of TCP (transmission control protocol) out-of-order buffer by means of combination of software and hardware |
US9003057B2 (en) | 2011-01-04 | 2015-04-07 | Cisco Technology, Inc. | System and method for exchanging information in a mobile wireless network environment |
US8891532B1 (en) * | 2011-05-17 | 2014-11-18 | Hitachi Data Systems Engineering UK Limited | System and method for conveying the reason for TCP reset in machine-readable form |
US8589610B2 (en) | 2011-05-31 | 2013-11-19 | Oracle International Corporation | Method and system for receiving commands using a scoreboard on an infiniband host channel adaptor |
US8484392B2 (en) | 2011-05-31 | 2013-07-09 | Oracle International Corporation | Method and system for infiniband host channel adaptor quality of service |
US8490207B2 (en) * | 2011-05-31 | 2013-07-16 | Red Hat, Inc. | Performing zero-copy sends in a networked file system with cryptographic signing |
US8804752B2 (en) | 2011-05-31 | 2014-08-12 | Oracle International Corporation | Method and system for temporary data unit storage on infiniband host channel adaptor |
US8792353B1 (en) | 2011-06-14 | 2014-07-29 | Cisco Technology, Inc. | Preserving sequencing during selective packet acceleration in a network environment |
US8737221B1 (en) * | 2011-06-14 | 2014-05-27 | Cisco Technology, Inc. | Accelerated processing of aggregate data flows in a network environment |
US8948013B1 (en) | 2011-06-14 | 2015-02-03 | Cisco Technology, Inc. | Selective packet sequence acceleration in a network environment |
US8743690B1 (en) | 2011-06-14 | 2014-06-03 | Cisco Technology, Inc. | Selective packet sequence acceleration in a network environment |
US8688799B2 (en) | 2011-06-30 | 2014-04-01 | Nokia Corporation | Methods, apparatuses and computer program products for reducing memory copy overhead by indicating a location of requested data for direct access |
US8879579B2 (en) | 2011-08-23 | 2014-11-04 | Oracle International Corporation | Method and system for requester virtual cut through |
US9021123B2 (en) | 2011-08-23 | 2015-04-28 | Oracle International Corporation | Method and system for responder side cut through of received data |
US8832216B2 (en) | 2011-08-31 | 2014-09-09 | Oracle International Corporation | Method and system for conditional remote direct memory access write |
US8996718B2 (en) * | 2012-02-02 | 2015-03-31 | Apple Inc. | TCP-aware receive side coalescing |
US9155046B2 (en) * | 2012-09-12 | 2015-10-06 | Intel Corporation | Optimizing semi-active workloads |
US20140089467A1 (en) * | 2012-09-27 | 2014-03-27 | Andre Beck | Content stream delivery using pre-loaded segments |
US20140092754A1 (en) * | 2012-09-28 | 2014-04-03 | Fluke Corporation | Packet tagging mechanism |
US9785647B1 (en) | 2012-10-02 | 2017-10-10 | Axcient, Inc. | File system virtualization |
US9852140B1 (en) | 2012-11-07 | 2017-12-26 | Axcient, Inc. | Efficient file replication |
US9384072B2 (en) | 2012-12-20 | 2016-07-05 | Oracle International Corporation | Distributed queue pair state on a host channel adapter |
US9191452B2 (en) | 2012-12-20 | 2015-11-17 | Oracle International Corporation | Method and system for an on-chip completion cache for optimized completion building |
US9069485B2 (en) | 2012-12-20 | 2015-06-30 | Oracle International Corporation | Doorbell backpressure avoidance mechanism on a host channel adapter |
US8937949B2 (en) | 2012-12-20 | 2015-01-20 | Oracle International Corporation | Method and system for Infiniband host channel adapter multicast packet replication mechanism |
US9148352B2 (en) | 2012-12-20 | 2015-09-29 | Oracle International Corporation | Method and system for dynamic repurposing of payload storage as a trace buffer |
US9069633B2 (en) | 2012-12-20 | 2015-06-30 | Oracle America, Inc. | Proxy queue pair for offloading |
US9256555B2 (en) | 2012-12-20 | 2016-02-09 | Oracle International Corporation | Method and system for queue descriptor cache management for a host channel adapter |
US9300578B2 (en) * | 2013-02-21 | 2016-03-29 | Applied Micro Circuits Corporation | Large receive offload functionality for a system on chip |
US9336158B2 (en) | 2013-02-26 | 2016-05-10 | Oracle International Corporation | Method and system for simplified address translation support for static infiniband host channel adaptor structures |
US8850085B2 (en) | 2013-02-26 | 2014-09-30 | Oracle International Corporation | Bandwidth aware request throttling |
US9069705B2 (en) | 2013-02-26 | 2015-06-30 | Oracle International Corporation | CAM bit error recovery |
US9397907B1 (en) | 2013-03-07 | 2016-07-19 | Axcient, Inc. | Protection status determinations for computing devices |
US9292153B1 (en) | 2013-03-07 | 2016-03-22 | Axcient, Inc. | Systems and methods for providing efficient and focused visualization of data |
US9338918B2 (en) | 2013-07-10 | 2016-05-10 | Samsung Electronics Co., Ltd. | Socket interposer and computer system using the socket interposer |
US10581687B2 (en) | 2013-09-26 | 2020-03-03 | Appformix Inc. | Real-time cloud-infrastructure policy implementation and management |
US9385959B2 (en) | 2013-09-26 | 2016-07-05 | Acelio, Inc. | System and method for improving TCP performance in virtualized environments |
US10291472B2 (en) | 2015-07-29 | 2019-05-14 | AppFormix, Inc. | Assessment of operational states of a computing environment |
US10355997B2 (en) | 2013-09-26 | 2019-07-16 | Appformix Inc. | System and method for improving TCP performance in virtualized environments |
GB2519745B (en) * | 2013-10-22 | 2018-04-18 | Canon Kk | Method of processing disordered frame portion data units |
US9742682B2 (en) | 2014-03-11 | 2017-08-22 | Vmware, Inc. | Large receive offload for virtual machines |
US9384033B2 (en) | 2014-03-11 | 2016-07-05 | Vmware, Inc. | Large receive offload for virtual machines |
US9755981B2 (en) * | 2014-03-11 | 2017-09-05 | Vmware, Inc. | Snooping forwarded packets by a virtual machine |
US9906454B2 (en) | 2014-09-17 | 2018-02-27 | AppFormix, Inc. | System and method for providing quality of service to data center applications by controlling the rate at which data packets are transmitted |
CN105578524B (en) * | 2014-10-07 | 2019-01-25 | 国基电子(上海)有限公司 | Terminal device and method for processing packet |
US9838498B2 (en) * | 2014-10-30 | 2017-12-05 | ScaleFlux | Remote direct non-volatile cache access |
WO2016079626A1 (en) * | 2014-11-19 | 2016-05-26 | Strato Scale Ltd. | Reducing short-packet overhead in computer clusters |
US10298494B2 (en) | 2014-11-19 | 2019-05-21 | Strato Scale Ltd. | Reducing short-packet overhead in computer clusters |
US10212259B2 (en) | 2014-12-01 | 2019-02-19 | Oracle International Corporation | Management of transmission control blocks (TCBs) supporting TCP connection requests in multiprocessing environments |
US10320918B1 (en) * | 2014-12-17 | 2019-06-11 | Xilinx, Inc. | Data-flow architecture for a TCP offload engine |
US9846657B2 (en) | 2015-02-06 | 2017-12-19 | Mediatek Inc. | Electronic device for packing multiple commands in one compound command frame and electronic device for decoding and executing multiple commands packed in one compound command frame |
US9584628B2 (en) | 2015-03-17 | 2017-02-28 | Freescale Semiconductor, Inc. | Zero-copy data transmission system |
JP2017046325A (en) * | 2015-08-28 | 2017-03-02 | 株式会社東芝 | Communication device, communication method, and program |
US9954979B2 (en) * | 2015-09-21 | 2018-04-24 | International Business Machines Corporation | Protocol selection for transmission control protocol/internet protocol (TCP/IP) |
CN105871739B (en) * | 2016-06-17 | 2018-12-07 | 华为技术有限公司 | A kind of method and calculating equipment of processing message |
US10237183B2 (en) * | 2016-10-03 | 2019-03-19 | Guavus, Inc. | Detecting tethering in networks |
US10868742B2 (en) | 2017-03-29 | 2020-12-15 | Juniper Networks, Inc. | Multi-cluster dashboard for distributed virtualization infrastructure element monitoring and policy control |
US11068314B2 (en) | 2017-03-29 | 2021-07-20 | Juniper Networks, Inc. | Micro-level monitoring, visibility and control of shared resources internal to a processor of a host machine for a virtual environment |
US11323327B1 (en) | 2017-04-19 | 2022-05-03 | Juniper Networks, Inc. | Virtualization infrastructure element monitoring and policy control in a cloud environment using profiles |
US10313926B2 (en) | 2017-05-31 | 2019-06-04 | Nicira, Inc. | Large receive offload (LRO) processing in virtualized computing environments |
US11855898B1 (en) * | 2018-03-14 | 2023-12-26 | F5, Inc. | Methods for traffic dependent direct memory access optimization and devices thereof |
CN112154633B (en) * | 2018-05-16 | 2021-12-17 | 华为技术有限公司 | Receiving device and transmission device for TCP communication |
US10862805B1 (en) | 2018-07-31 | 2020-12-08 | Juniper Networks, Inc. | Intelligent offloading of services for a network device |
US10880124B2 (en) * | 2018-12-28 | 2020-12-29 | Alibaba Group Holding Limited | Offload controller control of programmable switch |
US11916840B2 (en) * | 2019-02-15 | 2024-02-27 | Qualcomm Incorporated | Methods and apparatus for transport protocol ACK aggregation |
US10798014B1 (en) * | 2019-04-05 | 2020-10-06 | Arista Networks, Inc. | Egress maximum transmission unit (MTU) enforcement |
CN110535827B (en) * | 2019-07-17 | 2021-08-24 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | Method and system for realizing TCP (Transmission control protocol) full-unloading IP (Internet protocol) core of multi-connection management |
US11831742B2 (en) * | 2019-12-12 | 2023-11-28 | Intel Corporation | Semi-flexible packet coalescing control path |
US11405324B1 (en) * | 2019-12-12 | 2022-08-02 | Amazon Technologies, Inc. | Packet serial number validation |
EP4131880A4 (en) * | 2020-04-17 | 2023-03-15 | Huawei Technologies Co., Ltd. | Stateful service processing method and apparatus |
KR20210137702A (en) * | 2020-05-11 | 2021-11-18 | 삼성전자주식회사 | Electronic device and method for processing a data packet received in the electronic device |
CN112953967A (en) * | 2021-03-30 | 2021-06-11 | 扬州万方电子技术有限责任公司 | Network protocol unloading device and data transmission system |
US11909851B2 (en) * | 2021-10-04 | 2024-02-20 | Nxp B.V. | Coalescing interrupts based on fragment information in packets and a network controller for coalescing |
CN117354400B (en) * | 2023-12-06 | 2024-02-02 | 商飞软件有限公司 | Acquisition and analysis service system for Beidou short message |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2003021436A2 (en) * | 2001-09-04 | 2003-03-13 | Archduke Design, Inc. | Selective offloading of protocol processing |
WO2004021150A2 (en) * | 2002-08-30 | 2004-03-11 | Broadcom Corporation | System and method for tpc/ip offload independent of bandwidth delay product |
WO2004112350A1 (en) * | 2003-06-11 | 2004-12-23 | Intel Corporation | Network protocol off-load engine memory management |
Family Cites Families (57)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5673031A (en) * | 1988-08-04 | 1997-09-30 | Norand Corporation | Redundant radio frequency network having a roaming terminal communication protocol |
US5727142A (en) * | 1996-05-03 | 1998-03-10 | International Business Machines Corporation | Method for a non-disruptive host connection switch after detection of an error condition or during a host outage or failure |
US5778414A (en) | 1996-06-13 | 1998-07-07 | Racal-Datacom, Inc. | Performance enhancing memory interleaver for data frame processing |
US5940404A (en) * | 1997-04-30 | 1999-08-17 | International Business Machines Corporation | Method and apparatus for enhanced scatter mode allowing user data to be page aligned |
US7174393B2 (en) * | 2000-12-26 | 2007-02-06 | Alacritech, Inc. | TCP/IP offload network interface device |
US6434620B1 (en) * | 1998-08-27 | 2002-08-13 | Alacritech, Inc. | TCP/IP offload network interface device |
US7284070B2 (en) * | 1997-10-14 | 2007-10-16 | Alacritech, Inc. | TCP offload network interface device |
US6157955A (en) * | 1998-06-15 | 2000-12-05 | Intel Corporation | Packet processing system including a policy engine having a classification unit |
US6347364B1 (en) * | 1998-11-20 | 2002-02-12 | International Business Machines Corp. | Schedulable dynamic memory pinning |
US6628617B1 (en) * | 1999-03-03 | 2003-09-30 | Lucent Technologies Inc. | Technique for internetworking traffic on connectionless and connection-oriented networks |
US6952409B2 (en) | 1999-05-17 | 2005-10-04 | Jolitz Lynne G | Accelerator system and method |
JP2000332817A (en) * | 1999-05-18 | 2000-11-30 | Fujitsu Ltd | Packet processing unit |
CN1246012A (en) | 1999-07-14 | 2000-03-01 | 邮电部武汉邮电科学研究院 | Adaptation method for making internet be compatible with synchronous digital system |
JP2001045061A (en) * | 1999-08-02 | 2001-02-16 | Hitachi Ltd | Communication node device |
US7046686B1 (en) | 1999-08-17 | 2006-05-16 | Mindspeed Technologies, Inc. | Integrated circuit that processes communication packets with a buffer management engine having a pointer cache |
US6799202B1 (en) * | 1999-12-16 | 2004-09-28 | Hachiro Kawaii | Federated operating system for a server |
US7275093B1 (en) * | 2000-04-26 | 2007-09-25 | 3 Com Corporation | Methods and device for managing message size transmitted over a network |
US6535969B1 (en) * | 2000-06-15 | 2003-03-18 | Lsi Logic Corporation | Method and apparatus for allocating free memory |
US6958997B1 (en) * | 2000-07-05 | 2005-10-25 | Cisco Technology, Inc. | TCP fast recovery extended method and apparatus |
US20020038373A1 (en) * | 2000-07-21 | 2002-03-28 | John Border | Method and system for improving network performance enhancing proxy architecture with gateway redundancy |
US20050203927A1 (en) * | 2000-07-24 | 2005-09-15 | Vivcom, Inc. | Fast metadata generation and delivery |
US6961539B2 (en) * | 2001-08-09 | 2005-11-01 | Hughes Electronics Corporation | Low latency handling of transmission control protocol messages in a broadband satellite communications system |
US7111162B1 (en) * | 2001-09-10 | 2006-09-19 | Cisco Technology, Inc. | Load balancing approach for scaling secure sockets layer performance |
US7359326B1 (en) * | 2002-02-05 | 2008-04-15 | 3Com Corporation | Method for splitting data and acknowledgements in a TCP session |
US7237031B2 (en) * | 2002-03-07 | 2007-06-26 | Sun Microsystems, Inc. | Method and apparatus for caching protocol processing data |
US8005966B2 (en) * | 2002-06-11 | 2011-08-23 | Pandya Ashish A | Data processing system using internet protocols |
US7277963B2 (en) * | 2002-06-26 | 2007-10-02 | Sandvine Incorporated | TCP proxy providing application layer modifications |
US7142540B2 (en) * | 2002-07-18 | 2006-11-28 | Sun Microsystems, Inc. | Method and apparatus for zero-copy receive buffer management |
US7346701B2 (en) * | 2002-08-30 | 2008-03-18 | Broadcom Corporation | System and method for TCP offload |
US7397800B2 (en) * | 2002-08-30 | 2008-07-08 | Broadcom Corporation | Method and system for data placement of out-of-order (OOO) TCP segments |
US7299266B2 (en) * | 2002-09-05 | 2007-11-20 | International Business Machines Corporation | Memory management offload for RDMA enabled network adapters |
CN1254065C (en) * | 2002-10-29 | 2006-04-26 | 华为技术有限公司 | Random storage implemented TCP connecting timer and its implementing method |
US8069225B2 (en) * | 2003-04-14 | 2011-11-29 | Riverbed Technology, Inc. | Transparent client-server transaction accelerator |
US7742473B2 (en) * | 2002-11-12 | 2010-06-22 | Mark Adams | Accelerator module |
US7313148B2 (en) * | 2002-11-18 | 2007-12-25 | Sun Microsystems, Inc. | Method and system for TCP large segment offload with ack-based transmit scheduling |
US7324540B2 (en) * | 2002-12-31 | 2008-01-29 | Intel Corporation | Network protocol off-load engines |
US7330862B1 (en) * | 2003-04-25 | 2008-02-12 | Network Appliance, Inc. | Zero copy write datapath |
WO2004102115A1 (en) | 2003-05-16 | 2004-11-25 | Fujitsu Limited | Angle measuring system |
US20050108518A1 (en) * | 2003-06-10 | 2005-05-19 | Pandya Ashish A. | Runtime adaptable security processor |
US7251745B2 (en) * | 2003-06-11 | 2007-07-31 | Availigent, Inc. | Transparent TCP connection failover |
US7359380B1 (en) * | 2003-06-24 | 2008-04-15 | Nvidia Corporation | Network protocol processing for routing and bridging |
US7420991B2 (en) * | 2003-07-15 | 2008-09-02 | Qlogic, Corporation | TCP time stamp processing in hardware based TCP offload |
US8086747B2 (en) * | 2003-09-22 | 2011-12-27 | Anilkumar Dominic | Group-to-group communication over a single connection |
US20050086349A1 (en) * | 2003-10-16 | 2005-04-21 | Nagarajan Subramaniyan | Methods and apparatus for offloading TCP/IP processing using a protocol driver interface filter driver |
US6996070B2 (en) * | 2003-12-05 | 2006-02-07 | Alacritech, Inc. | TCP/IP offload device with reduced sequential processing |
US7383483B2 (en) * | 2003-12-11 | 2008-06-03 | International Business Machines Corporation | Data transfer error checking |
US7441006B2 (en) * | 2003-12-11 | 2008-10-21 | International Business Machines Corporation | Reducing number of write operations relative to delivery of out-of-order RDMA send messages by managing reference counter |
US8195835B2 (en) * | 2004-01-28 | 2012-06-05 | Alcatel Lucent | Endpoint address change in a packet network |
US7826457B2 (en) * | 2004-05-11 | 2010-11-02 | Broadcom Corp. | Method and system for handling out-of-order segments in a wireless system via direct data placement |
US20050286526A1 (en) * | 2004-06-25 | 2005-12-29 | Sood Sanjeev H | Optimized algorithm for stream re-assembly |
US7613813B2 (en) * | 2004-09-10 | 2009-11-03 | Cavium Networks, Inc. | Method and apparatus for reducing host overhead in a socket server implementation |
US7730196B2 (en) * | 2004-12-03 | 2010-06-01 | Microsoft Corporation | Efficient transfer of messages using reliable messaging protocols for web services |
US7509419B2 (en) * | 2005-01-13 | 2009-03-24 | International Business Machines Corporation | Method for providing remote access redirect capability in a channel adapter of a system area network |
US7535907B2 (en) * | 2005-04-08 | 2009-05-19 | Oavium Networks, Inc. | TCP engine |
US7693138B2 (en) * | 2005-07-18 | 2010-04-06 | Broadcom Corporation | Method and system for transparent TCP offload with best effort direct placement of incoming traffic |
CA2514039A1 (en) * | 2005-07-28 | 2007-01-28 | Third Brigade Inc. | Tcp normalization engine |
US7596628B2 (en) * | 2006-05-01 | 2009-09-29 | Broadcom Corporation | Method and system for transparent TCP offload (TTO) with a user space library |
-
2006
- 2006-07-18 US US11/489,389 patent/US7693138B2/en not_active Expired - Fee Related
- 2006-07-18 US US11/489,078 patent/US8064459B2/en not_active Expired - Fee Related
- 2006-07-18 CN CN2006800262474A patent/CN101253745B/en not_active Expired - Fee Related
- 2006-07-18 WO PCT/IB2006/004098 patent/WO2007069095A2/en active Application Filing
- 2006-07-18 US US11/489,388 patent/US7684344B2/en active Active
- 2006-07-18 US US11/489,393 patent/US20070014246A1/en not_active Abandoned
- 2006-07-18 EP EP06848596A patent/EP1917782A2/en not_active Withdrawn
- 2006-07-18 KR KR1020087002991A patent/KR100973201B1/en not_active IP Right Cessation
- 2006-07-18 US US11/489,390 patent/US20070033301A1/en not_active Abandoned
-
2010
- 2010-03-22 US US12/728,983 patent/US8274976B2/en not_active Expired - Fee Related
- 2010-04-05 US US12/754,016 patent/US8416768B2/en not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2003021436A2 (en) * | 2001-09-04 | 2003-03-13 | Archduke Design, Inc. | Selective offloading of protocol processing |
WO2004021150A2 (en) * | 2002-08-30 | 2004-03-11 | Broadcom Corporation | System and method for tpc/ip offload independent of bandwidth delay product |
WO2004112350A1 (en) * | 2003-06-11 | 2004-12-23 | Intel Corporation | Network protocol off-load engine memory management |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2595351A1 (en) * | 2011-11-15 | 2013-05-22 | Eaton Industries GmbH | Device for a digital transfer system, digital transfer system and data transfer method |
WO2013072384A1 (en) * | 2011-11-15 | 2013-05-23 | Eaton Electrical Ip Gmbh & Co. Kg | Subscriber for use in a digital transmission system, digital transmission system and method for data transmission |
CN103959725A (en) * | 2011-11-15 | 2014-07-30 | 伊顿电气Ip两合公司 | Apparatus for use in a digital transmission system, digital transmission system and method for data transmission |
Also Published As
Publication number | Publication date |
---|---|
US20070014245A1 (en) | 2007-01-18 |
US20080310420A1 (en) | 2008-12-18 |
US20070076623A1 (en) | 2007-04-05 |
US8416768B2 (en) | 2013-04-09 |
US20100198984A1 (en) | 2010-08-05 |
WO2007069095A3 (en) | 2007-12-06 |
US8064459B2 (en) | 2011-11-22 |
CN101253745A (en) | 2008-08-27 |
US8274976B2 (en) | 2012-09-25 |
WO2007069095A8 (en) | 2007-08-23 |
US7693138B2 (en) | 2010-04-06 |
US20100174824A1 (en) | 2010-07-08 |
CN101253745B (en) | 2011-06-22 |
KR100973201B1 (en) | 2010-07-30 |
US20070033301A1 (en) | 2007-02-08 |
KR20080042812A (en) | 2008-05-15 |
US20070014246A1 (en) | 2007-01-18 |
EP1917782A2 (en) | 2008-05-07 |
US7684344B2 (en) | 2010-03-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7684344B2 (en) | Method and system for transparent TCP offload | |
EP1537695B1 (en) | System and method for tcp offload | |
US7912064B2 (en) | System and method for handling out-of-order frames | |
US7596628B2 (en) | Method and system for transparent TCP offload (TTO) with a user space library | |
US20070022212A1 (en) | Method and system for TCP large receive offload | |
US7397800B2 (en) | Method and system for data placement of out-of-order (OOO) TCP segments | |
US7912060B1 (en) | Protocol accelerator and method of using same | |
EP1460804B1 (en) | System and method for handling out-of-order frames (fka reception of out-of-order tcp data with zero copy service) | |
WO2004021143A2 (en) | Method and system for data placement of out-of-order (ooo) tcp segments |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 2006848596 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200680026247.4 Country of ref document: CN |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020087002991 Country of ref document: KR |
|
WWP | Wipo information: published in national office |
Ref document number: 2006848596 Country of ref document: EP |