Method using receive and transmit protocol aware logic modules for confirming checksum values stored in network packet

[0001] This application builds upon concepts in two co-pending United States provisional applications assigned to Simplified Silicon, Inc., the assignee of the present application. More specifically, this application claims priority to U.S. Provisional Application No. 60/356,248 filed Feb. 12, 2002 for Network Processor with Improved Receiver and to U.S. Provisional Application No. 60/358,525 filed Feb. 21, 2002 for Network Processor with Improved Transmitter. These applications are incorporated by reference, however, to the extent that they differ from the material in this application, (barring clerical error) the latter application controls.

[0002] 1. Field of Invention

[0003] The present invention relates generally to the packet based data communications field, and more particularly, relates to a network processor that includes a shared data buffer between the user interface, network interface, and processor. The invention also includes protocol aware logic that monitors the data being written into the shared buffer.

[0004] 2. Description of Related Art

[0005] Internet and Intranet traffic typically consist of four different types of packets, ARP, ICMP, UDP, and TCP (see FIG. 1). When sent over an Ethernet link, these packets are embedded inside an Ethernet packet. All these packets have an Ethernet header 100, one or more protocol headers 121, and a data payload 106. The most common protocol is the Internet Protocol (IP), which has two sub protocols: transmission control protocol (TCP), and user datagram protocol (UDP). An IP packet 122, consists of an IP header 102, TCP header 104 (or UDP header 110 or an ICMP header 112), and a data payload 106. TCP is used for breaking up the data to be sent into datagrams, reassembling the datagrams at the other end, resending any datagrams that are lost, and finally re-assembling them in the correct order. UDP is a much simpler protocol that also breaks up the data into datagrams but does not have all the functionality of TCP. The overlying protocol of both UDP and TCP is IP. IP is used for the actual routing of datagrams. The Internet control message protocol (ICMP) is sometimes used for diagnostics and communication between two nodes on the network. These messages are not used to pass user data.

[0006] The basic format of a network packet 120 that is an IP packet 122 sent under the Ethernet transport protocol over any Ethernet link is as follows: Ethernet header 100, IP header 102, a TCP header 104 (or an UDP header 110 or an ICMP header 112), data payload 106, and the Ethernet checksum 108. The protocol headers 121 for IP packets include the IP header 102, TCP header 104, UDP header 110, or ICMP header 112. Other network packets based on different combinations of protocols would appear differently but would repeat the general pattern of a series of two or more nested protocols with the transport protocol as the top (outer) layer.

[0007] For example, if the transport protocol is something other than Ethernet, then the Ethernet header 100 and the Ethernet checksum 108 would be replaced with the header and checksum (if any) for that particular transport protocol. Typically, for Ethernet and other transport protocols, the transport header is generated in the network stack (described below) and the transport checksum is generated in the network interface (described below).

[0008] To understand, the ARP packet, (shown as the fourth packet in FIG. 1), it is useful to introduce some of the basic functions the Internet protocol uses to communicate.

[0009] Every device on the Internet or an Intranet that uses Ethernet to communicate has a unique MAC identifier that is programmed into the device by the manufacturer of the device. When two points, (“nodes”), want to communicate, they must do so by an underlying protocol. Most frequently, this will be Internet Protocol or IP. IP also has addresses for addressing one or more nodes and are used for relaying traffic between two or more nodes. IP addresses come as two different varieties, public and private. Public IP addresses are unique addresses that are registered with the Network Information Center, www.internic.net. Private IP addresses are reserved IP address ranges that can never be registered, but can be used behind protective networking devices called routers. The router will have a unique public IP address that it uses to talk on the Internet with other devices.

[0010] The IP protocol allows nodes to communicate using the IP address of each node. Not all IP addresses are unique, yet all MAC addresses are unique. Thus, when two devices need to communicate, they must take their unique addresses (MAC) and bind them to the addresses used to route data on the Internet/Intranet which are not always unique. Therefore, when MAC identification is bound to the IP address, address resolution protocol (ARP) is used. ARP is not an IP packet, thus the packet consists of the Ethernet header 100, ARP header 114, and the Ethernet checksum 108. Once the IP address is bound to the MAC address through ARP messages, TCP or UDP communications can take place. Typically, a node maintains a list of IP addresses bound to the MAC address. ARP messages are sent if the node does not have a MAC address for the IP address being contacted, or when the communication to the stored IP/MAC address fails.

[0011] Referring to FIG. 2, a network nodes typically include a network interface 600, which has a network buffer 605, a DMA engine 610, a processor executing a network stack (or more simply the “network stack”) 630, at least one application 635, processor memory 625, and a user interface 620, which has a user buffer 615.

[0012] This system can be broken into three major modules: the network interface 600, processor running a network stack 630 and an application 635, and user interface 620. To allow all these modules to operate independent of each other, local buffers have been added (605, 625, and 615). When data from a first module is required in a second module, the DMA engine 610 performs a fast copy from one module to the other. Typically, there is one bus on which all three modules reside, thus the DMA engine 610 can only service one copy request at a time as the copy ties up the shared bus. (Shared bus not shown in FIG. 2 in order to avoid undue clutter in that figure).

Prior Art Processing of Packets from Network Interface

[0013] Having reference to FIG. 2 and FIG. 3, these are the steps associated with receiving a network packet 120, from the network interface 600. In order to promote the description of the process to one of skill in the art, the process is shown by a combination of interaction steps 601 to 699 on FIG. 2 and process steps 700 to 760 on FIG. 3.

[0014] STEP 601/700—As the network packet 120 is being received from the network; the network interface 600 writes the entire packet into the network buffer 605.

[0015] STEP 606/705—Once the entire network packet 120 has been received, the network interface 600, will inform the network stack 630.

[0016] STEP 611/710—The network stack 630 configures the DMA engine 610 to copy the entire network packet 120 from the network buffer 605 into the processor's memory 625.

[0017] STEP 616/621/715—The DMA engine 610 reads the network packet 120 from the network buffer 605, and writes the network packet 120 into the processor's memory 625.

[0018] STEP 626/717—The DMA engine 610 informs the network stack 630 when the copy is completed.

[0019] STEP 631/720—The network stack 630 reads the network packet 120 in the processor's memory 625 and determines which protocols are used, and if the packet is valid.

[0020] STEP 636/725—The network stack 630 must process portions of the protocol headers 121, and update the socket management data structure (not shown) stored in the processor's memory 625. (A socket is a connection between two network devices on a specific port.)

[0021] BRANCH 631/730—The network stack 630 then checks the network packet 120 stored in the processor's memory 625 to determine if the network stack 630 is the final destination, or if the data payload 106 is bound for the user's interface 620.

[0022] STEP 636/735—If the network packet 120 is to be consumed by the network stack 630, then the network packet 120 will be processed by the network stack 630, and the packet buffer will be released from the processor's memory 625.

[0023] STEP 696/737—If the network packet 120 is bound for the user interface 620, the data payload 106 is passed to the application 635.

[0024] STEP 646/740—The application 635 configures the DMA engine 610 to copy the data payload 106 of the network packet 120 from the processor's memory 625 into the user buffer 615.

[0025] STEP 651/656/745—The DMA engine 610 reads the data payload 106 from the processor's memory 625, and writes it into the user buffer 615.

[0026] STEP 661/747—The DMA engine 610 informs the application 635 when the copy is completed.

[0027] STEP 666/750—The application 635 informs the user interface 620 of a valid data payload 106 in the user buffer 615.

[0028] STEP 671/755—The user's circuitry then reads the data payload 106 in the user buffer 615 through the user interface 620.

[0029] STEP 675/760—The packet buffer is released in the user buffer 615.

Prior Art Processing of Payloads from User Interface

[0030] Having reference to FIG. 2 and FIG. 4, these are the steps associated with the prior art method of receiving a data payload 106, from the user interface 620. In order to promote the description of the process to one of skill in the art, the process is shown by a combination of interaction steps 601 to 699 on FIG. 2 and process steps 800 to 855 on FIG. 4.

[0031] STEP 675/800—The user's circuit starts by writing a data payload 106 into the user buffer 615 through the user interface 620.

[0032] STEP 681/805—When the entire data payload 106 has been written, the user interface 620 informs the application 635 that the data payload 106 for a network packet 120 is ready for transmission.

[0033] STEP 646/810—The application 635 configures the DMA engine 610 to copy the data payload 106 from the user buffer 615 into the processor—s memory 625.

[0034] STEP 686/621/812—The DMA engine 610 copies the entire data payload 106 from the user buffer 615 into the processor's memory 625.

[0035] STEP 661/815—The DMA engine 610 informs the application 635 that the copy has been completed.

[0036] STEP 697/820—The application 625 passes a pointer to the data payload 106 stored in the processor's memory 625 to the network stack 630, and informs the network stack 630 what socket to send the network packet 120 on the network.

[0037] STEP 636/825—The network stack 630 builds the protocol headers 121. When there are a series of nested protocols below the transport layer, the network stack 630 would build all of the lower layer protocol headers. The protocol headers 121 are based on the socket identified supplied by the application 625 in STEP 697/820. Thus, a socket using IP would get an appropriate IP header.

[0038] STEP 636/830—The network stack 630 calculates the checksums for each protocol below the transport layer, and writes the values into the protocol headers 121. (For purposes of this application, CRC values (cyclical redundancy check values) and are a type of checksum). (The transport layer checksum is calculated by the network interface 600.)

[0039] STEP 611/835—The network stack 630 then configures the DMA engine 610 to copy the network packet 120 from the processor'memory 625 to the network buffer 605

[0040] STEP 651/696/837—The DMA engine 610 reads the network packet 120 from the processor's buffer 625 and writes it into the network buffer 605.

[0041] STEP 626/840—The DMA engine 610 informs the network stack 630 when the copy has been completed.

[0042] STEP 698/845—The network stack 630 informs the network interface 600 that a network packet 120 is ready for transmission.

[0043] STEP 699/850—The network interface 600 reads the network packet 120 from the network buffer 605 and sends it across the network after adding the transport layer header and checksum, in this case 100 and 106. .

[0044] STEP 601/855—The network interface 600 releases the packet buffer from the network buffer 605.

[0045] As illustrated by FIGS. 2 to 4 and the associated descriptions, the prior art suffers from several drawbacks. First, large amounts of memory are required. The network interface 600, processor 630, and user interface 620 must all contain buffers, which increase system cost and complexity. Another drawback is the network packet 120 must be copied between the network interface 600, processor 630, and user interface 620, which consume time that could be used for packet processing. As network data rates increase, these copies affect system bandwidth. Typically, the network buffer 605, user buffer 616, and processor memory 625 only have one bus (not shown) to transfer data between each of the buffers. As packet transfer rates increase, this bus becomes a limiting element in bandwidth. Finally, many protocol-processing tasks are better suited for a hardware implementation that allows for parallel processing, as opposed to the current sequential methods used in a pure software implementation.

[0046] While the prior art has suggested the use of a state machine in order to address previously recognized shortcomings with the prior art, this solution does not address the issue of future protocol support. Since a state machine solution calls for the protocol processing to be handled purely in hardware, the addition of new protocols would require a new device to be built. Replacing those devices already in use becomes very difficult and expensive. Another problem with the state machine solution is special user software cannot be performed in the device. Therefore, another processor must be attached to the state machine device in order to run a user's application. Finally, the state machine solution becomes very complex and expensive for certain protocols. For example, a web server is very complex, and must be configurable to handle many different user web pages. The state machines to handle these pages would become far too large and complex to be commercially viable.

[0047] While the prior art has taught that offloading the steps of checksum generation and verification from the processor can be beneficial, this offloading by it self is not sufficient to provide a highly efficient method for handling incoming and outgoing packets. This prior art solution does not eliminate the number of buffers required, nor does it remove the need to copy the packet between each of these buffers. Likewise, this prior art solution does not allow for the protocol header to be processed in parallel with the data payload reception.

[0048] While the prior art has taught filtering for established socket connections that allow the network interface to pass the protocol headers to the network stack and the data payload to the user application, it only occurs after the protocol headers and data payload are completely received in the network buffer. Both the protocol headers and data payload must still be copied into the processor's memory. The data payload must then be copied into the user interface. This prior art solution is adapted for interfacing with a user application residing on a personal computer. This solution could also be applied to an embedded environment in which the application is replaced with a user buffer and user interface. In this case, three separate buffers are still required; the network buffer, processor memory, and user buffer. Data copies are also still required to move the packet portions between the buffers. This prior art solution also has shortcomings for packet transmissions from the user interface to the network interface. The protocol checksums are based on the data payload, and protocol headers. Since these two parts are separated in the prior art, the transmit protocol checksum generation becomes difficult.

[0049] It is an object of the present invention to provide an improved method for handling the receipt of incoming packets in order to improve the efficiency of handling incoming packets.

[0050] It is another object of the present invention to provide an improved method for handling the outgoing packets in order to improve the efficiency of handling outgoing packets.

[0051] It is a further object of the present invention to develop a method that uses a shared buffer such that data may be shared among the network interface, the user interface, or the processor without the need to be copied for each subsystem to use the data.

[0052] It is yet another object of the present invention to use “protocol aware logic” in conjunction with the write path to the shared buffer to offload a portion of the processor workload.

[0053] It is yet another object of the present invention to develop a more efficient method for processing packets by processing solely the header portion of packets and not the data payload.

[0054] It is yet another object of the present invention to develop a method that increases throughput through use of parallel processing and the avoidance of memory copies of packets.

[0055] It is yet another object of the present invention to allow certain packets to be passed from the network receiver to the user interface without the use of the processor.

[0056] These and other advantages of the present invention are apparent from the drawings and the detailed description that follows.

[0057] The invention provides a low-cost, low-power, and high-bandwidth network interface. The packet receive and transmit paths have been highly optimized through the use of a shared memory buffer and protocol aware logic. The shared memory buffer eliminates data copies between the network interface and user interface, while allowing the processor to analyze and build the protocol headers for the packet. Protocol aware logic has been added to reduce the physical size of the processor, reduce the amount of code required for the network stack, and allow for parallel processing of the protocols. These improvements greatly reduce cost and power requirements, while increasing bandwidth.

[0067] The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

[0068] FIG. 5 illustrates the preferred embodiment of the improved network processor. The device still contains three basic modules: network interface 900, processor unit with a network stack 925, (or more simply “network stack”) and user interface 910. The user interface is capable of supporting more than one type of interface signaling method. For example, a synchronous FIFO interface could be enabled in the user interface by the processor, or another interface signaling method such as a standard memory mapped interface could be enabled instead.

[0069] All processor data structures and program instructions are located in the processor's memory 930. All data flow between the network interface and user interface is handled in one shared buffer 905. To reduce the workload of the processor and network stack 925, transmit protocol aware logic 920 and receive protocol aware logic 915 have been added to the transmit data path 916 and receive data path 911. Any packet to or from the network is stored in the shared buffer 905, and in the preferred embodiments never gets copied in the ways described in connections with FIGS. 2, 3, and 4. Therefore, a DMA engine (610 in FIG. 2) is not required for user packet processing.

Processing of Packets from Network Interface

[0070] The preferred sequence of events for a packet received on the network interface 900 is shown in FIG. 5, and represented in FIG. 6. The data packets are illustrated in FIG. 1.

[0071] STEP 911/1000—As the Ethernet header 100 and packet header 121 is being received through the network interface 900, and written into the shared buffer 905, the receive protocol aware logic 915 is analyzing the packet protocols to determine the protocols being used, protocol checksum values, and which socket the packet is going to. The receive protocol aware logic 915 determines the above information through the use of protocol based checksum logic, and through analysis of the packet headers 121.

[0072] STEP 931/1007—The receive protocol aware logic 915 will determine if all lower level protocol checksum values are correct, and if the network packet 120 is bound for an existing socket. The network interface 900 determines if the Ethernet checksum is correct 108. If any of the checksums are incorrect, the network stack 925 will be informed. (A socket is a connection between two network devices on a specific port.)

[0073] STEP 902/1008—The receive protocol aware logic 915 passes the data payload's 106 length, and location to the user interface 910.

[0074] BRANCH 1009—The receive protocol aware logic 915 determines if the incoming network packet 120 is on a “fast path” socket. A “fast path” socket is configured by the processor 925, and must be a socket in which no response packet is required. Any socket using the UDP protocol would be a candidate. The “fast path” socket data payload 106 is passed directly from the network interface 900 to the user interface 910 without the use of the network stack 925. The receive protocol aware logic 915 passes all necessary data payload 106 information to the user interface 910, as described in STEP 902/1010.

[0075] STEP 902/1010—If the network packet 120 is on a “fast path” socket, then the receive protocol aware logic 915 informs the user interface 910 of a valid data payload 106. The data flow will continue at STEP 906/1030.

[0076] BRANCH 1011—If the network packet 120 is bound for an existing socket, the receive protocol aware logic 915 will provide the network stack 925 a pointer to the socket management data structure stored in the processor memory 930. The data flow will continue at STEP 931/1014.

[0077] STEP 961/1012—If the network packet 120 is not on an existing socket, the network stack 925 builds a new socket management data structure in the processor memory 930.

[0078] STEP 971/1013—The network stack 925 then configures the receive protocol aware logic 915 such that it can identify the newly created socket. Data flow will continue at STEP 921/926/1015.

[0079] STEP 931/1014—If the network packet 120 is on an existing socket, the receive protocol aware logic 915 will pass the network stack 925 a pointer to the socket management data structure stored in the processor memory 930.

[0080] STEP 921/926/1015—The network stack 925 starts to process the protocol headers 121 and builds any response needed in the shared buffer 905.

[0081] STEP 911/1005—While steps 931/1007 to 931/1014 are occurring, the network interface 900 writes the remainder of the network packet 106 into the shared buffer 905.

[0082] STEP 931/1017—The network stack 925 waits for the receive protocol aware logic 915 to signal the end of the network packet 120.

[0083] BRANCH 1020—The network stack 925 then determines if the network packet 120 is bound for the network stack 925, or the user interface 910.

[0084] STEP 921/1035—If the network packet 120 is bound for the network stack 925, it will process the data payload 106 and release the packet buffer from the shared buffer 905.

[0085] STEP 955/1025—If the data payload 106 is bound for the user interface 910, then the network stack 925 informs the user interface 910 of a valid data payload 106.

[0086] STEP 906/1030—The user's circuitry then reads the data payload 106 from the shared buffer 905 through the user interface 910. The data payload 106 will always appear to be located at the beginning of the shared buffer 905 to the user's circuitry, since the receive protocol aware logic 915 has determined the start of the data payload 106 based on the protocol being used. By removing the offset to the data payload 106, the user's circuitry does not need to have knowledge of the protocol used for any given socket. The offset and length were passed to the user interface in step 902/1008.

[0087] STEP 916/1040—Once the user's circuitry reads the entire data payload 106 from the shared buffer 905, the user interface 910 will release the entire network packet 120 from the shared buffer 905.

[0088] The invention has a number of major advantages for packet reception from the network interface 900 including:

[0089] First, data can move from the network interface 900 to the user interface 910 without any data copies. In contrast the prior art process illustrated in FIGS. 2 and 3 made copies at step 616/621/715 and at step 651/656/745;

[0090] Second, the shared buffer 905 eliminates the use of three separate buffers as used in the current state of the art (605, 615, and 625). The reduction of these three buffers into one equates to a significant decrease in silicon size, and thus a large reduction in device cost;

[0091] Third, the receive protocol aware logic 915 removes the time consuming tasks such as protocol and CRC verification by the processor;

[0092] Fourth, the protocol CRC calculations are performed in parallel while the packet is being written into the shared buffer 905, therefore the packet is known to be good or bad immediately after it has been received;

[0093] Fifth, the receive protocol aware logic 915 identifies packets bound for established sockets. For those packets, the receive protocol aware logic 915 provides a pointer to the socket management data structure stored in the processor's memory 930. This feature eliminates many sequential byte compares typically performed by the network stack, and a search through a socket table for every received packet; and

[0094] Sixth, the receive protocol aware logic 915 utilizing the “fast path” is capable of identifying packets in which no processor intervention is needed. Instead, a pointer to the data payload 106 is directly passed to the user interface 910. Thus bandwidth is greatly increased by reducing the burden on the processor and allowing the processor to perform other tasks.

Processing of Payloads From User Interface

[0095] The preferred sequence of events for a data payload 106 received from the user interface 910 is shown in FIG. 5, and represented in FIG. 7. The data packets are illustrated in FIG. 1.

[0096] STEP 916/1100—The user's circuitry writes the data payload 106 into the shared buffer 905 through the user interface 910.

[0097] STEP 916/936/110513 As the data payload 106 is being written, the transmit protocol aware logic 920 starts to calculate all of the protocol checksums. The transmit protocol aware logic 920 also provides the network stack 925 a pointer to the socket management data structure stored in the processor's memory 930.

[0098] STEP 946/1110—When the user—s circuit has completed writing the data payload 106, the user interface 910 signals completion to the network stack 925.

[0099] STEP 965/926/1115—The network stack 925 then writes the protocol headers 121 based on the socket management data structure into the shared buffer 905.

[0100] STEP 936/926/1117—The network stack 925 writes the protocol checksums from the transmit protocol aware logic 920 into the protocol headers 121 which are stored in the shared buffer 905.

[0101] STEP 951/1120—The network stack 925 then informs the network interface 900 of the network packet 120 to be transmitted.

[0102] STEP 901/1125—The network interface 900 reads the network packet 120 from the shared buffer 905 and transmits it across the network. The network interface 900 also generates the Ethernet checksum 108.

[0103] STEP 911/1130—When the packet has been sent, the network interface 900 releases the packet buffer from the shared buffer 905.

[0104] The invention has a number of major advantages for data payload 106 receptions from the user interface 910 including:

[0105] First, data can move from the user interface 910 to the network interface 900 without any data copies. In contrast the prior art process illustrated in FIGS. 2 and 4 made copies at step 686/621/812, and step 651/696/837;

[0106] Second, the shared buffer 905 eliminates the use of three separate buffers as used in the current state of the art 605, 615, and 625;

[0107] The reduction of these three buffers into one equates to a significant decrease in silicon size, and thus a large reduction in device cost;

[0108] Third, the transmit protocol aware logic 920 eliminates the time consuming task such as protocol CRC generation by the processor;

[0109] Fourth, the protocol CRC calculations are performed in parallel while the packet is being written into the shared buffer 905;

[0110] Fifth, the transmit protocol aware logic 920 provides a pointer to the socket management data structure in the processor memory 930 to the network stack 925 for the socket in which the data payload 106 is associated; and

[0111] Sixth, the transmit protocol aware logic 920 provides the offset in which the data payload 106 should be written into the shared buffer 905 for the protocol being used in the socket.

Processing of Packets From Network Stack

[0112] The preferred sequence of events for a network packet 120 received from the network stack 925 is shown in FIG. 5, and represented in FIG. 8. The data packets are illustrated in FIG. 1.

[0113] STEP 926/1200—The network stack 925 writes the network packet 120 into the shared buffer 905.

[0114] STEP 926/1205—As the network stack 925 is writing the network packet 120 into the shared buffer 905, the transmit protocol aware logic 920 calculates the protocol checksum.

[0115] STEP 936/926/1210—The network stack 925 writes the protocol checksums from the transmit protocol aware logic 920 into the protocol headers 121 which are stored in the shared buffer 905.

[0116] STEP 951/1215—The network stack 925 then informs the network interface 900 of the network packet 120 to be transmitted.

[0117] STEP 901/1220—The network interface 900 reads the network packet 120 from the shared buffer 905 and transmits it into the network. As part of this process the network interface 900 generates the Ethernet checksum 108 and inserts it.

[0118] STEP 911/1125—When the packet has been sent, the network interface 900 releases the packet buffer from the shared buffer 905.

Alternative Embodiments

[0119] Those skilled in the art could apply many modifications to the preferred embodiment. One such modification would be a second user interface in addition to the first, in which no protocol processing is performed in the second user interface. In the system with two user interfaces, only traffic on specific sockets would be processed by the network stack 900, receive protocol aware logic 915, transmit protocol aware logic 920, and the original user interface 910. If the traffic is not on the specific sockets, then the entire network packet 120 is sent unmodified either from the network interface 900 to the second user interface, or unmodified from the second user interface to the network interface 900. One use of such a system would be an intelligent Ethernet adapter board for personal computers. The original user interface 910 could be used to communicate with dedicated circuits on the personal computer without the need of the personal computer's operating system. These circuits would include system monitoring and diagnostic circuits. The second user interface would be a PCI interface, which would provide the main network connectivity to the personal computer's operating system.

[0120] Another embodiment that would increase packet throughput would be a modified shared buffer 905. Instead of a single buffer, the buffer would be broken into a transmit and a receive buffer. The transmit and receive buffers would consist of multiple receive packet buffers and multiple transmit packet buffers. The receive packet buffers and transmit packet buffers would have at least two ports, with one port connected to the network interface and the other port connected to either the processor or the user interface or both.

[0121] In the receive direction, the network interface would write the packet into one of the receive packet buffers. While the packet is being written into the receive packet buffer on one port, the processor would have access to the other port of the same packet buffer in order to process the protocol headers. Once the entire packet has been received, and the processor has completed the protocol header processing, the packet buffer would be passed to the user interface. The user interface would access the packet buffer through the same port that the processor had access to in the previous step.

[0122] In the transmit direction, the user interface would write the data payload into one of the transmit packet buffers. Once the data payload was completely written, the pointer to the transmit packet buffer would be passed to the processor. The processor would then write the protocol headers into the transmit packet buffer through the same port that the user interface used in the previous step. When the processor has finished writing the protocol headers, the packet would be passed to the network interface. The network interface would then read the packet from the second port and send the packet across the network.

[0123] Through the use of multiple individual multi-port memories, bandwidth is increased without the complexity of providing access to the same memory by three interfaces: the network interface, user interface, and Processor.

[0124] The single ported shared buffer could resolve the access contentions between each of these ports through the use of a higher clock rate, and time division multiplexing between the three modules. However, the multiple individual multiport memories allows for high bandwidth at a reduced clock rate. The slower clock rate allows for much lower power consumption, which is a benefit in many applications. One such application is battery powered portable equipment.

[0125] Another embodiment would be a modified receive and transmit protocol aware logic that could handle application layer protocols. One example protocol would be the real-time transport protocol, RTP. RTP is used in network video and voice communications, and uses the UDP protocol for transport through a network. Through the use of the “fast path” in the preferred embodiment, and added RTP protocol support packet reception and transmission would be maintained without any processor intervention. The processor would only be needed to establish the connection, terminate the connection, and process non-RTP packets. This alternative embodiment would allow for very low cost network enabled telephones and video equipment.

[0126] Another embodiment for the transmit direction would allow for the Ethernet header 100 and protocol headers 121 to be stored in separate header buffer. The network interface 900, would then transmit the Ethernet header 100 and protocol headers 121 from the header buffer, and then transmit the data payload 106. The advantage to this method is the network stack 925 could build the Ethernet header 100 and protocol header 121 before, or while the data payload 106 is being written into the shared buffer 905. Many times, the Ethernet header 100 and the protocol headers 121 do not change much from packet to packet. Therefore, the entire header buffer would not have to be rebuilt for each packet.

[0127] FIG. 1 was provided in order to provide context for the various manipulations to packet components by the prior art methods and the disclosed invention. The invention is not limited to the specific packet types illustrated in FIG. 1 and one of ordinary skill in the art could apply the teachings of the present invention to a device for processing another known packet format.

[0128] The preferred embodiment of the present invention implements the protocol aware logic on both the incoming and outgoing paths. One of skill in the art could implement the protocol aware logic on only one path. Such a network processor would be best used for an application with a disparity in upstream and downstream traffic such that the direction with the higher traffic flow would have the benefit of the protocol aware logic. One such application would be a video server, in which most of the data is in the outgoing path. Therefore, the receive direction would not need the speed improvements of the receive path.

[0129] The preferred embodiment offloads several tasks from the processor unit with network stack to the transmit protocol aware logic and the receive protocol aware logic. One of skill in the art could choose to retain one or more of these tasks for the processor unit with network stack. For example, the processor unit with network stack could perform the steps necessary to discern the socket for a network packet or data payload.

[0130] Those skilled in the art will recognize that the methods and apparatus of the present invention have many applications and that the present invention is not limited to the specific examples given to promote understanding of the present invention. Moreover, the scope of the present invention covers the range of variations, modifications, and substitutes for the system components described herein, as would be known to those of skill in the art.

[0131] The legal limitations of the scope of the claimed invention are set forth in the claims that follow and extend to cover their legal equivalents. Those unfamiliar with the legal tests for equivalency should consult a person registered to practice before the patent authority which granted this patent such as the United States Patent and Trademark Office or its counterpart.