[go: up one dir, main page]

WO2006119773A1 - Methode et systeme pour traiter des paquets de donnees - Google Patents

Methode et systeme pour traiter des paquets de donnees Download PDF

Info

Publication number
WO2006119773A1
WO2006119773A1 PCT/DK2006/000252 DK2006000252W WO2006119773A1 WO 2006119773 A1 WO2006119773 A1 WO 2006119773A1 DK 2006000252 W DK2006000252 W DK 2006000252W WO 2006119773 A1 WO2006119773 A1 WO 2006119773A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
data
connection
packet
data packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/DK2006/000252
Other languages
English (en)
Inventor
Andreas Magnussen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
IPBLAZE AS
Original Assignee
IPBLAZE AS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by IPBLAZE AS filed Critical IPBLAZE AS
Publication of WO2006119773A1 publication Critical patent/WO2006119773A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

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]
    • 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

Definitions

  • the present invention relates generally to data packet processing using first and second data packet processing entities, where the second processing entity is designed for processing a wider range of data packets than can be processed at the first entity. More particularly, the present invention relates to data packet processing where process control ownership is exchanged between the first and the second entity.
  • network messages contain information regarding a number of protocol layers that allow information within the messages to be directed to the correct destination and decoded according to appropriate instructions, although substantial differences may exist between the computers or other devices transmitting and receiving the messages. Processing of these messages is usually performed by a central processing unit, CPU, running software instructions designed to recognize and manipulate protocol information contained in the messages.
  • CPU central processing unit
  • a multiple stack system may include a software stack and a hardware stack.
  • the software stack may be adapted to process a first set of TCP packet streams.
  • the hardware stack may be adapted to process a second set of TCP packet streams and may be coupled to the software stack.
  • the software stack may be adapted to offload one or more TCP connections to the hardware stack.
  • the hardware stack may be adapted to upload one or more TCP connections to the software stack.
  • the software stack and the hardware stack may process one or more TCP connections concurrently.
  • One of the major problems when performing protocol processing in multiple entities is to maintain synchronization between the processing entities. Synchronization should be maintained at all time with any data traffic pattern, and it should be possible to pass processing control back and forth between the processing entities for any data traffic pattern.
  • the exchange of processing control from one entity to another may be per- formed by passing ownership of shared control facilities like state variables from one entity to another.
  • a method of processing data in a data packet processing system being designed for processing data packets of one or more data stream connections, said processing system having first and second entities being designed for data packet processing, said second entity being designed for processing a wider range of data packets than can be processed by the first entity, said method comprising: establishing a first data stream connection; forwarding one or more data packets of the first data stream connection from the first entity to the second entity thereby giving process ownership of the data packet(s) of the first connection to the second entity, each said forwarded data packet being assigned a unique packet identifier; processing at least one forwarded data packet of the first connection at the second entity; and forwarding return process ownership data from the second entity to the first entity, said return ownership data holding information identifying the last received data packet of the first connection which has been processed at the second entity.
  • the method of the invention further comprises determining from the forwarded return process ownership data, if there are any data packets of the first connection which have been forwarded from the first entity to the second entity and which have not yet been processed at the second entity.
  • the method may further com- prise deciding, based on the result of said step of determination, whether the first entity is to accept to receive the process ownership of the data packet(s) of the first connection or not. It is preferred that the step of determination is performed at the first entity.
  • the result of the determination step shows that there are no non-processed data packets of the first connection which have been forwarded to the second entity, then it is accepted to have the first entity receiving the process ownership of the data packets of the first connection, and when the result of the determination step shows that there is at least one non- processed data packet of the first connection which have been forwarded to the second entity, then it is not accepted to have the first entity receiving the process ownership of the data packets of the first connection.
  • the return process ownership data holds information including the unique packet identifier of the last received data packet of the first connection which has been processed at the second entity, and that said determination step comprises a comparison of the unique packet identifier of the last data packet of the first connection, which has been forwarded to the second entity, and the unique packet identifier of the last data packet of the first connection, which has been processed at the second entity.
  • the comparison of packet identifiers shows, that the compared packet identifiers are identical, then it may be accepted to have the first entity receiving the process ownership of the data packets of the first connection, and when the comparison of packet identifiers shows, that the compared packet identifiers are not identical, then it may not be accepted to have the first entity receiving the process ownership of the data packets of the first connection.
  • the step of establishing the first data stream connection comprises an initialisation process in which an incoming data packet of a non-identified connection is forwarded to the second entity, the second entity identifies and accept the data stream and establishes the connection as a first data stream connection to which the incoming packet belongs. It is preferred that during the initialisation process, the second entity defines an initial process ownership for incoming data packets belonging to the first data stream connection. It is also preferred that during the initialisation process, the second entity further defines initial credit data for the first entity, whereby the first entity is given credit to forward an allowed number of data packets of the first connection to the second entity.
  • the method before the step of forwarding one or more data packets of the first connection from the first entity to the second entity, the method comprises: receiving one or more data packets of the first connection at the first entity; deciding at the first entity for each received data packet whether it is to be processed at the first entity or not; if yes, then processing the corresponding data packet at the first entity; and if not, then forwarding the corresponding data packet to the second entity.
  • the step of deciding at the first entity whether a received data packet of the first connection it is to be processed at the first entity or not comprises determining whether the received packet is provided with a predetermined process ownership being the second entity or not; if yes, then forwarding the corresponding data packet to the second entity; and if not, then determining whether the received data packet can be processed at the first entity; if yes, then processing the data packet at the first entity; and if not, then forwarding the data packet to the second entity.
  • the first entity may have a credit to forward only an allowed number of data packets of the accepted connection to the second entity.
  • the second entity may forward increment credit data to the first entity, whereby the first entity is given credit to forward an increased number of data packets of the first connection to the second entity.
  • the increment credit data may be forwarded from the second entity to the first entity together with the return process ownership data.
  • the unique packet identifier comprises a packet frame number. It is also preferred that the credit of the first entity is represented by a maximum packet frame number.
  • the unique packet identifier is generated at the first entity and forwarded to the second entity together with the corresponding data packet.
  • a first unique packet identifier is generated at the first entity and a second unique packet identifier corresponding to the first unique packet identifier is generated at the second entity.
  • the step of forwarding re- turn process ownership data from the second entity to the first entity may be performed every time a forwarded data packet of the first connection has been processed at the second entity.
  • the processing performed by the first entity is substantially hardware based, and the processing performed by the second entity is substantially software based.
  • the first entity may comprise a so-called TCP Offload Engine, TOE.
  • data is forwarded from the first entity to the second entity via a memory bus interface.
  • the memory bus interface may be a Peripheral Component Interface, PCI interface.
  • PCI interface Peripheral Component Interface
  • the data packets have a TCP/IP header format.
  • a data packet processing system for processing data packets of one or more data stream connections received from a network, said processing system comprising: a first data packet processing entity being designed for receiving and processing a range of data packets; a second data packet processing entity being designed for processing a wider range of data packets than can be processed by the first entity; and a processor for establishing a first data stream connection to the network; wherein, for a data packet of the first connection which cannot be processed at the first entity, the first entity is adapted for assigning a unique packet identifier to said data packet, forwarding the data packet to the second entity and giving process ownership of the data packet(s) of the first connection to the second entity; and wherein, when one or more forwarded data packets of the first connection have been processed at the second entity, the second entity is adapted for forwarding return process ownership data of the data packets of the first connection to the first entity, said return process ownership data holding information identifying the last received data packet of the first connection which has been processed at the second entity.
  • the first entity is adapted for determining from the return process ownership data received from the second entity, if there are any data packets of the first connection which have been forwarded from the first entity to the second entity and which have not been processed at the second entity.
  • the first entity may be adapted for deciding, based on the result of said determi- nation step, whether the first entity is to accept to receive the process ownership of the data packet(s) of the first connection or not.
  • the first entity is adapted to accept the process ownership of the data packets of the first connection when the result of the determination step shows that there are no non-processed data packets of the first connection which have been forwarded to the second entity.
  • the first entity is further adapted to reject the process ownership of the data packets of the first connection when the result of the determination step shows that there are at least one non-processed data packet of the first connection which have been forwarded to the second entity.
  • the return process ownership data holds information including the unique packet identifier of the last received data packet of the first connection which has been processed at the second entity, and wherein the first entity is adapted to perform said determination step by performing a comparison of the packet identifier of the last data packet of the first connection, which has been forwarded to the second entity, and the packet identifier of the last data packet of the first connection, which has been processed at the second entity.
  • the first entity may be adapted to receive the process ownership of the data packets of the first connection when the comparison of packet identifiers shows, that the compared packet identifiers are identical, and the first entity may be adapted to reject the process ownership of the data packets of the first connection when the comparison of packet identifiers shows, that the compared packet identifiers are not identical.
  • the system of the invention is adapted for performing an initialisation process in which an incoming data packet of a non-identified data stream connection is forwarded to the second entity, the processor for establishing a data stream connection being part of the second entity, and the second entity being adapted to identify the data stream connection and to establish the connection as a first connection to which the incoming data packet belongs.
  • the second entity may be further adapted to define an initial process ownership for incoming data packets belonging to the first data stream connection.
  • the second entity may be further adapted to define initial credit data for the first entity, whereby the first entity is given credit to forward an allowed number of data packets of the first connection to the second entity.
  • the first entity is adapted for determining whether the received data packet of the first connection can be processed at the first entity or not, if yes, then the first entity is adapted for processing the data packet at the first entity, and if not, then the first entity is adapted forwarding the data packet to the second entity.
  • the first entity is adapted for determining whether a received data packet of the first connection is provided with a predetermined process ownership being the second entity or not; if yes, then the first entity is adapted for forwarding the corresponding data packet to the second entity; and if not, then the first entity is adapted for determining whether the received data packet can be processed at the first entity; if yes, then the first entity is adapted for processing the data packet at the first entity; and if not, then the first entity is adapted forwarding the data packet to the second entity.
  • the first entity may have a credit to forward only a maximum allowed number of data packets of the first connec- tion to the second entity.
  • the second entity may be further adapted for forwarding increment credit data to the first entity, whereby the first entity is given credit to forward an increased number of data packets of the first connection to the second entity.
  • the second entity may be adapted to forward the increment credit data to the first entity together with the return process ownership data.
  • the unique packet identifier comprises a packet frame number. It is also within an embodiment of the system of the invention that the credit of the first entity is represented by a maximum packet frame number.
  • the first entity is adapted for generating a unique packet identifier and forwarding the unique packet identifier to the second entity together with the corresponding data packet.
  • the first entity is adapted for generating a first unique packet identifier and the second entity is adapted for generating a second unique packet identifier corresponding to the first unique packet identifier.
  • the second entity is adapted to process said queued one or more data packets.
  • the second entity may be adapted for forwarding return process ownership data to the first entity every time a forwarded data packet of the first connection have been processed at the second en- tity.
  • the first data packet processing entity is substantially hardware based, and the second data packet processing entity is substantially software based.
  • the first entity may comprise a so-called TCP Off- load Engine, TOE.
  • a memory bus interface is provided for forwarding of data from the first entity to the second entity.
  • the memory bus interface may be a Peripheral Component Interface, PCI interface.
  • the packet format of the data packets has a TCP/IP header format.
  • Fig. 1 shows a block diagram of an embodiment of a data packet processing system according to the present invention
  • Fig. 2 is a flow chart illustrating an embodiment of a process that determines process ownership of a stream or connection of data packets according to the present inven- tion
  • Fig. 3 is a flow chart illustrating an embodiment of a process that returns or offloads process ownership of a stream or connection of data packets from a software based entity to a hardware based entity according to the present invention
  • Fig. 4 is a flow chart illustrating an embodiment of a process in which credit to forward an increased number of data packets of a data stream is given to the hardware based entity being part of the process of Fig. 3,
  • Fig. 5 is a flow chart illustrating an embodiment of a process that determines whether to accept or to reject the process ownership being returned according to the process of Fig. 3, and
  • Fig. 6 is a diagram listing an embodiment of process steps when a number of incoming data packets of a data stream or connection are received by the system of Fig. 1.
  • One or more embodiments according to the present invention may provide for an envi- ronment allowing for synchronization of data packet processing, where process control ownership of data packets of a data stream connection is exchanged between a fast executing entity (e.g. hardware implementation) and a general processing entity (e.g. software).
  • the fast executing entity may be able to process only a subset of the required functions but may be able to do the processing very fast.
  • the subset of func- tions, which can be processed by the fast executing entity may be selected as the most frequently occurring functions and as the functions resulting in the highest system benefits.
  • the general processing entity should be able to support the full set of functions, but the processing time may be slower and the overall system performance may be significantly lower.
  • FIG. 1 An embodiment of a data packet processing system 10 according to the present invention is illustrated in the block diagram of Fig. 1.
  • the system of Fig. 1 has a software based processing entity, CPU system 11 , which CPU system 11 is running an operation system with a network stack, OS (network part) 12.
  • the CPU system 11 further has a slow path software processing part 13 performing processing by use of a soft- ware driver, witch is able to perform full protocol processing, e. g. processing of all options.
  • the processing system 10 of Fig. 1 further comprises a so-called TCP Offload Engine, TOE, 14, which is hardware based and which is able to perform partial protocol processing, e. i. processing of packets with the most common options.
  • TOE TCP Offload Engine
  • the software based processing entity providing the slow processing path 13 may have a significantly lower performance than the hardware based processing entity 14, TOE.
  • the system 10 further has a PCI interface 15 for the exchange of data between the TOE 14 and the CPU system 11.
  • the PCI interface 15 comprises an interface bus supporting reading and writing to a memory, whereby the memory can be shared.
  • Queues between TOE 14 and CPU 11 are implemented in host memory, which is accessible from the CPU 11 and the TOE 14 (via the PCI interface 15), and in the TOE 14.
  • the PCI interface 15 can comprise PCI, PCl-X, PCI Express and other types of memory busses. It should be noted that the principles of the present invention may be used for different packet formats. For the system illustrated in Fig. 1 , the packet format uses a TCP/IP header format.
  • Ethernet packets are received 40 by the TOE hardware 14 from the Ethernet via e.g. an optical or electrical interface.
  • the packets are not recognized as belonging to a connection known by the TOE hardware 14 they may be placed on a queue 50 for received packets in order to be forwarded to the CPU system 11.
  • the queue 50 can be implemented as a DMA ring with address to the memory location for the buffer.
  • the network stack in the OS 12 e.g. Linux or Windows
  • a received Ethernet packet is a TCP/IP packet with correct format and checksums, and the TCP packet belongs to a connection known by the TOE hardware 14, then this packet is subject to a first processing by the TOE hardware 14.
  • packets subject to a first TOE processing can be further processed by the TOE 14, then payload data is copied to host memory in the CPU 11 and a notification 52 can be sent to the OS network part 12 of the CPU 11. If packets subject to the first TOE processing cannot be further processed by the TOE 14, then the TCP packet, a connection identifier (Connld) and a frame number (Frame- No) is send 53 to the software driver 13 of the CPU 11.
  • Connld connection identifier
  • Frame- No frame number
  • command queue 51 the software driver 13 can return packet process control ownership to the TOE hardware 14 and give the TOE hardware 14 more credit for forwarding an allowed number of data packets to the software driver 13.
  • Fig. 2 is a flow chart illustrating an embodiment of a process that determines process ownership of a stream or connection of data packets according to the present invention.
  • the TOE 14 Before a connection is setup in the TOE hardware 14 for protocol offload, all packets are forwarded to the CPU system 11 as generic packets with no packet processing (like a standard network interface card). For each identified TCP connection to be processed at the TOE 14, the TOE 14 may have a set of control variables, named “Owner”, “FrameNo” and “MaxFrameNo”, which is illustrated in text box 105 of Fig. 2. Note that every offloaded TCP connection is given a set of state variables. Here, the value of the variable "Owner" defines the process ownership of incoming packets of an identified TCP connection, that is whether packets of this identified connection shall be processed at the TOE hardware processing entity 14 or at the slow software processing entity 13.
  • each packet to be for- warded from the TOE 14 to the software processing entity 13 needs to have a unique identifier.
  • the unique packet identifier of an identified TCP connection is defined by the value of the variable "FrameNo".
  • the TOE processing entity 14 is allowed to forward a certain number of packets of the identified connection to the software processing entity 13.
  • the allowed number of forwarded packets is de- fined by the value of the variable "MaxFrameNo".
  • Initialization of the state variables is performed at the software based entity, CPU system 11 , and within the CPU system 11 the initialization may be performed by the OS network part 12.
  • the parameter values given during the initialization are not important for the operation of the system.
  • an Ethernet packet is received from the network 100 by the TOE hardware 14.
  • step 101 it is checked if the packet is a TCP/IP packet with correct check sums and CRC fields.
  • step 102 it is checked if the TCP packet belongs to a TCP connection known by the TOE hardware. If the packet does not belong to a TCP connection known by the TOE hardware 14 it is forwarded, step 103, to the OS network part 12 of the CPU 11 for processing. If the packet belongs to a connection known by the TOE 14, then in step 110 it is checked which TCP connection the packet belongs to and the values of the state variables for the identified TCP connection are found.
  • packets belonging to a TCP connection may be forwarded to the software processing entity 13 using a separate queue (not shown).
  • step 120 the value of the parameter "Owner” is checked. If the value of the parameter "Owner” is set to "Hw" (hardware, meaning that process ownership is given to the TOE hardware processing entity 14), then the process proceeds to step 130. In step 130 the TOE hardware logic 14 will try to process the packet. However, the packet might be with options that the TOE hardware logic 14 does not support (e.g. urgent data), and thus the TOE hardware 14 may not be able to complete the processing of the packet. This is checked in step 140. If the processing of the packet is completed at step 130, then in step 150 TCP payload data (if presents) is copied to host memory and the host CPU 11 is notified if actions are required (e.g. the "push" flag is set in the TCP header).
  • TCP payload data if presents
  • the host CPU 11 is notified if actions are required (e.g. the "push” flag is set in the TCP header).
  • the "Owner" parameter is set to "Sw", step 170, and the packet is to be forwarded to the slow path software driver 13 at the CPU 11 without protocol processing by the TOE hardware 14.
  • the packet is to be forwarded to the slow path software driver 13 at the CPU 11 without protocol processing by the TOE hardware 14.
  • the value of the parameter "FrameNo” is checked. If the value of the parameter "FrameNo” is less than the value of the parameter "MaxFrameNo”, the TOE 14 is allowed to send the packet to the software driver 13 at the CPU 11.
  • step 200 From step 200 the process moves to step 210, in which the TOE hardware 14 incre- ments the parameter "FrameNo” by one to "FrameNo + 1".
  • the parameter "FrameNo” is incremented before a packet is sent to the driver software 13 at the CPU 14 for processing.
  • step 210 the process moves to step 220 in which the packet is sent to the slow path software driver 13 at the CPU 11 for processing, and the TOE hardware 14 does not process the packet.
  • step 200 If in step 200 the value of the parameter "FrameNo" is larger than or equal than the value of the parameter "MaxFrameNo", the TOE 14 is not allowed to send the packet to the software driver 13 at the CPU 11 , and the packet is discarded, step 230, to thereby avoid overloading the driver software 13 with packets which the driver might not have capacity to process. So, at step 230 a packet is discarded to avoid overload problems in the CPU system 11. It is better to discard packets at an early stage so processing capacity is not wasted on packets, which later might be discarded.
  • the TCP protocol may retransmit packets in case of packet loss (e.g. in the network or discarded by the TOE hardware 14).
  • Fig. 3 is a flow chart illustrating an embodiment of a process according to the present invention, which process returns or offloads process ownership of a stream or connection of data packets from the slow path software based entity 13 to the hardware based entity 14 according to the present invention.
  • the flow chart of Fig. 3 may be seen in connection with the flow chart of Fig. 2, and the packet sent from the TOE hardware 14 at step 220 is received at the slow path software driver 13 at step 300.
  • the software driver 13 at the CPU 11 receives a packet from the TOE hardware 14 for a given TCP connection, then the parameter "Owner" of this packet is set to "Sw" and process control ownership of this packet is automatic handed over to the software driver 13.
  • the software driver 13 may have several parameters for each TCP connections. For the illustrated embodiment of the invention, one of these parameters is the parameter "credit" provided to the TOE hardware 14, see the discus- sion below in connection with the flow chart of Fig. 4.
  • the software driver 13 would like to return the packet process control ownership to the TOE hardware 14 in order to speed up the overall system performance.
  • step 320 it is checked if the slow path software driver 13 can return the process control ownership to the TOE hardware 14. If yes it will do so.
  • the software driver 13 may want to give more credit to the TOE hardware 14, whereby the value of the parameter "MaxFrameNo" may be increased by the amount indicated by the parameter "credit” , see the flow chart of Fig. 4.
  • the software driver 13 will give more credit to the TOE hardware 14. If yes, then the parameter "credit” is sent to the TOE 14, and in step 360 more credit is given to the TOE hardware 14.
  • the packet processing is ended, step 370.
  • Fig. 4 is a flow chart illustrating an embodiment of a process in which credit to forward an increased number of data packets of a data stream is given to the hardware based entity 14.
  • the software driver 13 wants to allow the TOE hardware 14 to forward more data packets for the given TCP connection.
  • the parameter "Credit” indicates the additional number of packets the TOE hardware may forward to the software driver 13 of the CPU system 11.
  • the TOE hardware parameter "MaxFrameNumber" is increased with the amount indicated by the parameter "Credit” forwarded from the software driver 13.
  • this operation is done.
  • Fig. 5 is a flow chart illustrating an embodiment of a process that determines whether to accept or to reject the data packet process control ownership being returned from the software driver 13 to the TOE hardware 14.
  • the process control ownership can only be returned to the TOE 14, if the value of the parameter "FrameNo" in the TOE 14 matches with the "FrameNo" value, given by the parameter "ExpectedFrameNo", forwarded by the slow path software driver 13.
  • step 500 which corresponds to step 330 in Fig. 3, the software driver 13 wants to forward the data packet process control ownership for the given TCP connection to the TOE hardware 11 and a parameter "ExpectedFrameNo" is forwarded to the TOE hardware 11 from the software driver 13.
  • the value of the parameter "ExpectedFrameNo” indicates the "FrameNo” value of the last packet being processed at the software driver 13, and thus the value that the soft- ware driver 13 expects for the current TOE hardware parameter "FrameNo” in order for the process control ownership to be returned to the TOE hardware 11.
  • the value of the TOE parameter "FrameNo” is the value being given by the TOE hardware 11 at step 210, for the last data packet being forwarded to the software driver 13.
  • the current value of the TOE hardware parameter "FrameNo” given at step 210 is com- pared with the value of the parameter "ExpectedFrameNo" forwarded from the software driver 13.
  • step 510 If there is a difference between the values compared at step 510, then one or more data packets have been forwarded from the TOE hardware 14 to the software driver 13 without yet having been processed at the software driver 13, and the process ownership cannot be returned to the TOE 14, step 520. No explicit returned message needs to be returned to the software driver 13. If the values compared at step 510 are equal, then there are no unprocessed packets being forwarded from the TOE 14 and queued for processing at the software driver 13, and the process ownership is returned to the TOE hardware 11 , step 530, and the change of process control ownership is done, step 540.
  • the Time column indicates the time or order of arrival of incoming packets from the network and the order in which process steps are performed
  • the TOE Hardware column has a first sub-column, Variables, and a second sub-column, TOE Action, with the first sub-column indicating values of the TCP connection control variables "Owner”, “FrameNo", and “MaxFrameNo”, and with the second sub-column indicating the process steps or actions performed at the TOE hardware 14,
  • the Events TOE>Driver column indicates the exchange of data and/or forwarding of packets from the TOE hard- ware 14 to the software driver 13
  • the Driver Software column indicates process steps or actions performed by the software driver 13
  • the Events Driver>TOE column indicates the exchange of data from the software driver 13 to the TOE hardware 14.
  • the parameter "Owner” is set to "Sw”
  • the value of "FrameNo” is incremented from 3 to 4
  • the packet is now forwarded to the software driver 13 for processing.
  • data holding information of the TCP connection identity, the "FrameNo” value and the packet No, which here is 21 is also for- warded to the software driver 13, while at the same time the process ownership is handed over to the driver 13.
  • the driver 13 has processed packet 21 , it tries to return the process ownership to the TOE 14, and together with the return ownership query, the value of 4 for the parameter "ExpectedFrameNo” is forwarded to the TOE 14. Since the value of "ExpectedFrameNo" is equal to the current value of "FrameNo" at the TOE 14, then the TOE 14 accepts to receive the process ownership, and the following packets 22 and 23 are processed at the TOE 14.
  • packet 25 For the next received packet, packet 25, the parameter "Owner” is already set to “Sw” and then following steps 120, 200, 210 and 220 of Fig. 2, the value of "FrameNo” is incremented from 5 to 6, and the packet is forwarded to the software driver 13 for processing.
  • the steps 120, 200, 210 and 220 of Fig. 2 are also followed for the following packet 26, and the value of "FrameNo” is incremented to 7.
  • packet 27, steps 120 and 200 of Fig. 2 are followed but now at step 200, the value 7 of "FrameNo” is equal to the value of the parameter "MaxFrameNo", and packet 27 is discarded due to no credit, going from step 200 to step 230 in Fig. 2.
  • the next received packet, packet 28, follows the same route as packet 27 and is discarded.
  • Packets 24, 25 and 26 have now all been forwarded to the software driver 13 for proc- essing, and after the processing of packet 24, the software driver 13 sends a return ownership query to the TOE 14 together with the value 5 of the packet "FrameNo" representing the value of the parameter "ExpectedFrameNo". But now the value of "ExpectedFrameNo", which is 5, is not equal to the current value of "FrameNo", which is 7, at the TOE 14, and the TOE 14 refuses to receive the process ownership, and the next packet 25 must be processed at the software driver 13.
  • the next incoming packet, packet 29, is processed at the TOE hardware 14, following steps 120, 130, 140 and 150 in Fig. 2.
  • the software driver 13 wants to increase the value of the parameter "MaxFrameNo" for the TCP connection, and a value of 4 for the parameter "credit” is forwarded from the software driver 13 to the TOE 14, whereby the value of "MaxFrameNo" is increased from 7 to 11 , and thereby again allowing packets to be forwarded from the TOE 14 for processing at the software driver 13.
  • this packet is also processed at the TOE hardware 14 following steps 120, 130, 140 and 150 of Fig. 2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne une méthode et un système pour traiter des paquets de données d'au moins une connexion de flux de données reçus à partir d'un réseau à l'aide d'une première entité de traitement de paquets de données et d'une seconde entité de traitement de paquets de données. Le système de traitement de paquets de données présente une première entité de traitement de paquets de données (14) conçue pour recevoir et pour traiter une plage de paquets de données, une seconde entité de traitement de paquets de données (11) conçue pour traiter une plage plus importante de paquets de données pouvant être traités par la première entité (14), et un processeur pour établir une première connexion de flux de données jusqu'au réseau. La première entité (14) est conçue pour attribuer un identifiant de paquet unique à un paquet de données de la première connexion, lorsque ce paquet de données ne peut pas être traité au niveau de la première entité, et pour réacheminer ce paquet de données jusqu'à une seconde entité (11) et pour donner une propriété de procédé de ce paquet de données ou de ces paquets de données de la première connexion à la seconde entité (11). Lorsqu'au moins un paquet de données réacheminé de la première connexion a été traité au niveau de la seconde entité (11), la seconde entité (11) est conçue pour réacheminer les données de propriété de procédé de retour des paquets de données de la première connexion à la première entité (14), les informations de maintient de données de propriété de procédé de retour identifiant le dernier paquet de données reçu de la première connexion qui a été traité au niveau de la seconde entité (11). Il est préférable que la première entité de traitement de paquet de données (14) soit sensiblement fondée sur du matériel, et que la seconde entité de traitement de paquets de données soit sensiblement fondée sur un logiciel. Il est également préférable que la première entité (14) comprenne un TOE :moteur de déchargement de protocole de contrôle de transmission (TCP).
PCT/DK2006/000252 2005-05-13 2006-05-11 Methode et systeme pour traiter des paquets de donnees Ceased WO2006119773A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DKPA200500705 2005-05-13
DKPA200500705 2005-05-13

Publications (1)

Publication Number Publication Date
WO2006119773A1 true WO2006119773A1 (fr) 2006-11-16

Family

ID=36778166

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DK2006/000252 Ceased WO2006119773A1 (fr) 2005-05-13 2006-05-11 Methode et systeme pour traiter des paquets de donnees

Country Status (1)

Country Link
WO (1) WO2006119773A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2919433A1 (fr) * 2014-03-13 2015-09-16 Kabushiki Kaisha Toshiba Procédé et dispositif de traitement de protocole de communication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010037397A1 (en) * 1997-10-14 2001-11-01 Boucher Laurence B. Intelligent network interface system and method for accelerated protocol processing
US20040042483A1 (en) * 2002-08-30 2004-03-04 Uri Elzur System and method for TCP offload
EP1513321A2 (fr) * 2003-08-29 2005-03-09 Broadcom Corporation Système et procédé destinés au délestage du tcp/ip indépendamment d'un produit de retard de largeur de bande

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010037397A1 (en) * 1997-10-14 2001-11-01 Boucher Laurence B. Intelligent network interface system and method for accelerated protocol processing
US20040042483A1 (en) * 2002-08-30 2004-03-04 Uri Elzur System and method for TCP offload
EP1513321A2 (fr) * 2003-08-29 2005-03-09 Broadcom Corporation Système et procédé destinés au délestage du tcp/ip indépendamment d'un produit de retard de largeur de bande

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KURMANN C ET AL: "Speculative defragmentation - a technique to improve the communication software efficiency for gigabit ethernet", HIGH-PERFORMANCE DISTRIBUTED COMPUTING, 2000. PROCEEDINGS. THE NINTH INTERNATIONAL SYMPOSIUM ON AUGUST 1-4, 2000, PISCATAWAY, NJ, USA,IEEE, 1 August 2000 (2000-08-01), pages 131 - 138, XP010511542, ISBN: 0-7695-0783-2 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2919433A1 (fr) * 2014-03-13 2015-09-16 Kabushiki Kaisha Toshiba Procédé et dispositif de traitement de protocole de communication
US9866639B2 (en) 2014-03-13 2018-01-09 Kabushiki Kaisha Toshiba Communication apparatus, information processor, communication method, and computer-readable storage medium

Similar Documents

Publication Publication Date Title
US20250030627A1 (en) System and method for facilitating efficient load balancing in a network interface controller (nic)
US7783769B2 (en) Accelerated TCP (Transport Control Protocol) stack processing
JP4150336B2 (ja) 共有属性に基づいて圧縮キューペアから複数の仮想キューペアを作成する構成
US9276854B2 (en) Scaling egress network traffic
US20010047433A1 (en) Obtaining a destination address so that a network interface device can write network data without headers directly into host memory
US8539112B2 (en) TCP/IP offload device
EP1782602A1 (fr) Appareil et procede de support de mise en place de connexion dans un dechargement de traitement de protocole de reseau
WO2006046972A1 (fr) Appareil et procede permettant de prendre en charge la gestion de memoire dans le dechargement de traitement de protocole de reseau
WO2004019165A2 (fr) Procede et systeme destines a des applications tcp/ip utilisant des tampons generiques pour des applications tcp de non mise en attente
CN114124850B (zh) 一种网络通信方法及装置、存储介质
US7400581B2 (en) Load-balancing utilizing one or more threads of execution for implementing a protocol stack
US7643502B2 (en) Method and apparatus to perform frame coalescing
CN113973091A (zh) 一种报文处理方法、网络设备以及相关设备
CN108429703B (zh) Dhcp客户端上线方法及装置
US20060153215A1 (en) Connection context prefetch
WO2006119773A1 (fr) Methode et systeme pour traiter des paquets de donnees
CN116016687B (zh) 一种基于dpdk的报文分流方法及系统
CN114615348B (zh) 基于udp gso的数据传输方法、装置、计算机设备和存储介质
US20140301393A1 (en) Preprocessing unit for network data
WO2024156226A1 (fr) Procédé, dispositif et système de transmission de paquets
EP1420561B1 (fr) Système et procédé pour le déchargement et chargement TCP
WO2009033969A1 (fr) Procédé et appareil de mémorisation de données numériques

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

122 Ep: pct application non-entry in european phase

Ref document number: 06722941

Country of ref document: EP

Kind code of ref document: A1