WO2006119773A1

WO2006119773A1 - Method and system for data packet processing

Info

Publication number: WO2006119773A1
Application number: PCT/DK2006/000252
Authority: WO
Inventors: Andreas Magnussen
Original assignee: Ipblaze A/S
Priority date: 2005-05-13
Filing date: 2006-05-11
Publication date: 2006-11-16

Abstract

There is provided a method and a system for processing data packets of one or more data stream connections received from a network by use of first and second data packet processing entities. The data packet processing system has a first data packet processing entity (14) being designed for receiving and processing a range of data packets, a second data packet processing entity (11) being designed for processing a wider range of data packets than can be processed by the first entity (14), and a processor for establishing a first data stream connection to the network. The first entity (14) is adapted for assigning a unique packet identifier to a data packet of the first connection, when this data packet cannot be processed at the first entity, and for forwarding this data packet to the second entity (11) and giving process ownership of the data packet(s) of the first connection to the second entity (11). When one or more forwarded data packets of the first connection have been processed at the second entity (11), the second entity (11) is adapted for forwarding return process ownership data of the data packets of the first connection to the first entity (14), with the return process ownership data holding information identifying the last received data packet of the first connection which has been processed at the second entity (11). It is preferred that the first data packet processing entity (14) is substantially hardware based, and that the second data packet processing entity is substantially software based. It is also preferred that the first entity (14) comprises a so-called TCP Offload Engine, TOE.

Description

METHOD AND SYSTEM FOR DATA PACKET PROCESSING

FIELD OF THE INVENTION

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.

BACKGROUND OF THE INVENTION

Within recent years a lot of work has been put into systems for providing communication over computer networks. As different computer and network architectures have been created, many types of protocols have evolved to facilitate such communication. Conventionally, 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.

With the increasing prevalence of network communication, a large portion of the CPU's time may be devoted to such protocol processing, interfering with other tasks the CPU may need to perform. Multiple interrupts to the CPU can also be problematic when transferring many small messages or for large data transfers, which are conventionally divided into a number of packets for transmission over the network.

Several systems have been proposed in which means are provided for offloading some of the most time consuming protocol processing from a host CPU to a specialised hardware based network communication processing entity. A system of this type is described in U.S. Pat. No. 6,697,868, from which it is known to have a host CPU running a network protocol processing stack that provides instructions not only to process network messages but also to allocate processing of certain network messages to a specialized network communication device, offloading some of the most time consuming protocol processing from the host CPU to the network communication device. By allocating common and time consuming network processes to the device, while retaining the ability to handle less time intensive and more varied processing on the host stack, the network communication device can be relatively simple and cost effective. The host CPU, operating according to instructions from the stack, and the network communication device together determine whether and to what extent a given message is processed by the host CPU or by the network communication device.

In U.S. Patent Application Pub. No. 2004/0049591 is described a system and a method providing transmission control protocol, TCP, offloading and uploading. In one example, 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.

It is an object of the present invention to provide a solution, which allows control of synchronization while data and process control are moving between different process- ing entities.

SUMMARY OF THE INVENTION

According to the present invention there is provided 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.

It is preferred that 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. Here, 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.

According to an embodiment of the invention it is preferred that 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, 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.

It is within an embodiment of the invention that 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. Here, when 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.

Preferably, 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.

It is within an embodiment of a method of the invention that 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.

It is preferred that 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.

According to a preferred embodiment of the method of the invention the first entity may have a credit to forward only an allowed number of data packets of the accepted connection to the second entity. Here it is preferred that after the processing of the at least first forwarded data packet at 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.

It is within an embodiment of the method of the invention that 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.

Preferably, then for each data packet being forwarded from the first entity to the second entity, the unique packet identifier is generated at the first entity and forwarded to the second entity together with the corresponding data packet. However, it is also within an embodiment of the invention that each data packet being forwarded from the first entity to the second entity, 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.

It is within a preferred embodiment that when there is one or more non-processed data packets of the first connection which have been forwarded to and queued at the sec- ond entity, and it is not accepted to have the first entity receiving the process ownership of the data packets of the first connection, said queued one or more data packets are processed at the second entity.

According to an embodiment of the method of the invention 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.

It is preferred that the processing performed by the first entity is substantially hardware based, and the processing performed by the second entity is substantially software based. Here, the first entity may comprise a so-called TCP Offload Engine, TOE. It is also preferred that data is forwarded from the first entity to the second entity via a memory bus interface. Here, the memory bus interface may be a Peripheral Component Interface, PCI interface. It is preferred that the data packets have a TCP/IP header format.

According to the present invention there is also provided 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.

For the system of the invention it is preferred that 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. Here, 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. Preferably, 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. It is also preferred that 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.

It is within an embodiment of the system of the invention that 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. Here, 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.

It is preferred that 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. Here, as part of the initialisation process, the second entity may be further adapted to define an initial process ownership for incoming data packets belonging to the first data stream connection. Also, as part of said initialisation process, 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. For the system of the invention it is within a preferred embodiment that 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.

It is within an embodiment of the system of the invention that 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.

According to an embodiment of the system of the invention 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. Here it is preferred that after the processing of the one or more forwarded data packets at 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.

It is within an embodiment of the system of the invention that 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.

For the system of the invention it is preferred that for each data packet being forwarded from the first entity to the second entity, 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. However, it is also within an embodiment of the system of the invention that for each data packet being forwarded from the first entity to the second entity, 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.

For the system of the invention it is preferred that when there is one or more non-processed data packets of the first connection which have been forwarded to and queued at the second entity, and the first entity has rejected to receive the process ownership of the data packets of the first connection, then the second entity is adapted to process said queued one or more data packets.

According to an embodiment of the system of the invention, 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.

Also for the system of the invention it is preferred that the first data packet processing entity is substantially hardware based, and the second data packet processing entity is substantially software based. Here, the first entity may comprise a so-called TCP Off- load Engine, TOE. It is also preferred that 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. Also here it is preferred that the packet format of the data packets has a TCP/IP header format.

The invention will be further described in the following with the aid of the accompanying drawing.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

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.

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.

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.

For the system of Fig. 1 , Ethernet packets are received 40 by the TOE hardware 14 from the Ethernet via e.g. an optical or electrical interface.

If 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) will eventually process the queued packet.

If 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.

If 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.

By use of 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.

The packet processing performed for a data packet received by the TOE hardware 14 is discussed in connection with Fig. 2, which 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.

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. In order to keep control of packets forwarded between the TOE hardware processing entity 14 and the 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. Here, the unique packet identifier of an identified TCP connection is defined by the value of the variable "FrameNo". For the system of Fig. 2, 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. Typical initialization values are "Owner"="Sw" (meaning that process ownership is given to the software processing entity 13), "FrameNo"=0, "MaxFrame- No"=4. The parameter values given during the initialization are not important for the operation of the system.

In Fig. 2, an Ethernet packet is received from the network 100 by the TOE hardware 14. In step 101 it is checked if the packet is a TCP/IP packet with correct check sums and CRC fields. In 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.

It should be noted that packets belonging to a TCP connection, which is not to be offloaded to the TOE 14, may be forwarded to the software processing entity 13 using a separate queue (not shown).

In 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). -If the TOE hardware logic 14 was not able to process the packet, then 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.

Similar at step 120, if the value of the parameter "Owner" is set to "Sw", then 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. For a packet having the parameter "Owner" set to "Sw" and to be forwarded to the slow path software driver 13, then at step 200 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.

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. From 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.

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. When 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.

It should be noted that 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. When the data packet has been received at step 300, then at step 310 the received packet is processed by the software driver 13. After the received packet has been processed by the slow path software driver 13, then according to this embodiment of the invention, 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. Thus, in 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. This will usually be the case, unless the software driver 13 has not completed processing of the for- warded packets (waiting on more packets) or the connection is going to be closed. The return of process control ownership from the software driver 13 to the TOE hardware 14, step 330, is described in more details in connection with the flow chart of Fig. 5.

For a given TCP connection, 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. At step 340 it is decided if 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. When more credit has been given to the TOE hardware 14 at step 360 or when it has been decided at step 340 not to forward more credit, 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. Here, at step 400, which corresponds to step 360 at Fig. 3, 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. At step 410 the TOE hardware parameter "MaxFrameNumber" is increased with the amount indicated by the parameter "Credit" forwarded from the software driver 13. At step 420 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. At 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. Here, 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. At step 510 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.

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.

Process steps according to an embodiment of the invention, in which a number of incoming data packets of a data stream or connection are received by the system of Fig. 1 are listed in the diagram of Fig. 6. In Fig. 6 there are five columns named: Time, TOE Hardware, Events TOE>Driver, Driver Software, and Events Driver>TOE.

Here, 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, and the Events Driver>TOE column indicates the exchange of data from the software driver 13 to the TOE hardware 14.

For the first periods of time there is a phase of identifying and setup of one or more TCP connections, and for each connection there is an initialization phase of the state or control variables to be used for a TCP connection by the TOE hardware 14. The connection set up and the initialization phase have been described above. Following the diagram of Fig. 6, the set of control variables of an identified TCP connection are first set to: "Owner" ="Sw", "FrameNo"=0, and "MaxFrameNo"=0. Then in a next step of initialization, the software driver 13 gives a credit value of 7 to the TCP connection, whereby the value of the parameter "MaxFrameNo" is set to 7. At this stage, no packets have been forwarded from the TOE 14 to the software driver 13, and the current value of the variable "FrameNo" in both the TOE 14 and the software driver 13 is 0. The process control ownership is now returned by the software driver 13 to the TOE hardware 14, and the return of ownership is accepted at the TOE hardware 14, since the value of the received parameter "Expected FrameNo" is 0 and equals the current value of the parameter "FrameNo" at the TOE hardware 14.

Following the diagram of Fig. 6 then at a time an incoming packet 20 of the identified TCP connection is received. At this point in time, the state variables for this TCP connection is: "Owner"="Hw", "FrameNo"=3, and "MaxFrameNo"=7. The packet is processed at the TOE hardware 14, see steps 120, 130, 140 and 150 in Fig. 2. For the next incoming packet 21 , the state variables for the TCP connection are the same. But then following steps 130 and 140 of Fig. 2, the packet cannot be processed at the TOE hardware 14, and then following steps 170, 200, 210 and 220 of Fig. 2, the parameter "Owner" is set to "Sw", the value of "FrameNo" is incremented from 3 to 4, and the packet is now forwarded to the software driver 13 for processing. When forwarding the packet 21 to the software driver 13, then 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. When 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.

When receiving packet 24, then again following steps 130 and 140 of Fig. 2, the packet cannot be processed at the TOE hardware 14, and following steps 170, 200, 210 and 220 of Fig. 2, the parameter Owner" is set to "Sw", the value of "FrameNo" is incremented from 4 to 5, and the packet is forwarded to the software driver 13 for processing.

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. Also for the next packet, 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. When packet 25 has been processed then again the software driver 13 sends a return ownership query to the TOE 14 together with the value 6 of the packet "FrameNo" representing the value of the parameter "ExpectedFrameNo". But again the value of "ExpectedFrameNo", which is 6, 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 26 must be processed at the software driver 13. When packet 26 has been processed then again the software driver 13 sends a return ownership query to the TOE 14 together with the value 7 of the packet "FrameNo" representing the value of the parameter "Expected- FrameNo". Now the value of "ExpectedFrameNo", which is 7, is equal to the current value of "FrameNo" at the TOE 14, and the TOE 14 accepts to receive the process ownership.

The next incoming packet, packet 29, is processed at the TOE hardware 14, following steps 120, 130, 140 and 150 in Fig. 2. At this point in time, 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.

For the final incoming packet of Fig. 6, packet 30, this packet is also processed at the TOE hardware 14 following steps 120, 130, 140 and 150 of Fig. 2.

It should be understood that various modifications may be made to the above de- scribed embodiments and it is desired to include all such modifications and functional equivalents as fall within the scope of the accompanying claims.

Claims

1. 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.

2. A method according to claim 1 , said method further comprising: 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.

3. A method according to claim 2, said method further comprising: 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.

4. A method according to claim 2 or 3, wherein said step of determination is performed at the first entity.

5. A method according to any one of the claims 2-4, wherein 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, 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 are 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.

6. A method according to any one of the claims 1 -5, wherein 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 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.

7. A method according to claim 6, wherein when the comparison of packet identifiers shows, that the compared packet identifiers are identical, then it is 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 is not accepted to have the first entity receiving the proc- ess ownership of the data packets of the first connection.

8. A method according to any one of the claims 1-7, wherein 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.

9. A method according to claim 8, wherein during said initialisation process, the second entity defines an initial process ownership for incoming data packets belonging to the first data stream connection.

10. A method according to claim 8 or 9, wherein during said 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.

11. A method according to any one of the claims 1-10, wherein before the step of forwarding one or more data packets of the first connection from the first entity to the second entity, said 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.

12. A method according to claim 9 and 11 , wherein 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.

13. A method according to any one of the claims 1 -12, wherein the first entity has a credit to forward only an allowed number of data packets of the accepted connection to the second entity.

14. A method according to claim 13, wherein after the processing of the at least first forwarded data packet at the second entity, the second entity forwards 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.

15. A method according to claim 14, wherein the increment credit data is forwarded from the second entity to the first entity together with the return process ownership data.

16. A method according to any one of the claims 1-15, wherein the unique packet identifier comprises a packet frame number.

17. A method according to nay one of the claims 10-15 and claim 16, wherein the credit of the first entity is represented by a maximum packet frame number.

18. A method according to any one of the claims 1-17, wherein for each data packet being forwarded from the first entity to the second entity, the unique packet identifier is generated at the first entity and forwarded to the second entity together with the corresponding data packet.

19. A method according to any one of the claims 1-17, wherein for each data packet being forwarded from the first entity to the second entity, 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.

20. A method according to any one of the claims 3-19, wherein when there is one or more non-processed data packets of the first connection which have been forwarded to and queued at the second entity, and it is not accepted to have the first entity receiving the process ownership of the data packets of the first connection, said queued one or more data packets are processed at the second entity.

21. A method according to any one of the claims 1-20, wherein the step of forwarding return process ownership data from the second entity to the first entity is performed every time a forwarded data packet of the first connection has been processed at the second entity.

22. A method according to any one of the preceding claims, wherein the processing performed by the first entity is substantially hardware based, and the processing performed by the second entity is substantially software based.

23. A method according to any one of the preceding claims, wherein data is forwarded from the first entity to the second entity via a memory bus interface.

24. A method according to claim 23, wherein said memory bus interface is a Periph- eral Component Interface, PCI interface.

25. A method according to any one of the preceding claims, wherein the packet format of the data packets has a TCP/IP header format.

26. A method according to any one of the claims 22-25, wherein the first entity comprises a so-called TCP Offload Engine, TOE.

27. 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.

28. A system according to claim 27, wherein 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.

29. A system according to claim 28, wherein the first entity is adapted for deciding, based on the result of said determination step, whether the first entity is to accept to receive the process ownership of the data packet(s) of the first connection or not.

30. A system according to claim 29, wherein 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, and wherein 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.

31. A system according to any one of the claims 28-30, wherein 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.

32. A system according to claim 31 , wherein the first entity is 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 wherein the first entity is 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.

33. A system according to any one of the claims 27-32, wherein the system 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.

34. A system according to claim 33, wherein as part of the initialisation process the second entity is adapted to define an initial process ownership for incoming data packets belonging to the first data stream connection.

35. A system according to claim 33 or 34, wherein as part of said initialisation process, the second entity is 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.

36. A system according to any one of the claims 27-36, wherein 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.

37. A system according to any one of the claims 27-36, wherein 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 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.

38. A system according to any one of the claims 27-37, wherein the first entity has a credit to forward only a maximum allowed number of data packets of the first connec- tion to the second entity.

39. A system according to claim 38, wherein after the processing of the one or more forwarded data packets at the second entity, the second entity is 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.

40. A system according to claim 39, wherein the second entity is adapted to forward the increment credit data to the first entity together with the return process ownership data.

41. A system according to any one of the claims 27-40, wherein the unique packet identifier comprises a packet frame number.

42. A system according to claim any one of the claims 35-40 and 41 , wherein the credit of the first entity is represented by a maximum packet frame number.

43. A system according to any one of the claims 27-42, wherein for each data packet being forwarded from the first entity to the second entity, 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.

44. A system according to any one of the claims 27-42, wherein for each data packet being forwarded from the first entity to the second entity, 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.

45. A system according to any one of the claims 30-44, wherein when there is one or more non-processed data packets of the first connection which have been forwarded to and queued at the second entity, and the first entity has rejected to receive the process ownership of the data packets of the first connection, the second entity is adapted to process said queued one or more data packets.

46. A system according to any one of the claims 27-45, wherein the second entity is 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 entity.

47. A system according to any one of the preceding claims, wherein the first data packet processing entity is substantially hardware based, and the second data packet processing entity is substantially software based.

48. A system according to any one of the preceding claims, wherein a memory bus interface is provided for forwarding of data from the first entity to the second entity.

49. A system according to claim 48, wherein said memory bus interface is a Peripheral Component Interface, PCI interface.

50. A system according to any one of the preceding claims, wherein the packet for- mat of the data packets has a TCP/IP header format.

51. A system according to any one of the claims 47-50, wherein the first entity comprises a so-called TCP Offload Engine, TOE.