JP2007537550A - Storage server architecture using digital semantic processor - Google Patents

Abstract

The storage server 200 uses the semantic processor 100 to analyze and respond to client requests. A direct execution parser 140 in the semantic processor 100 parses the input stream containing the client's storage server request according to a defined grammar. Semantic processor execution engine 150 can perform operations on data (eg, data movement, mathematical and logical operations, etc.) in response to a request from a direct execution parser to perform an operation requested by a client. Execute a microcode segment. This storage server improves work efficiency and, in some embodiments, allows the entire storage server to be miniaturized, with several relatively small integrations that can be mounted on the circuit board of the media device. It can consist of a circuit. The semantic processor itself probably only requires a few watts of power.
[Selection] Figure 3

Description

Related applications

  This application is US patent application No. 10 / 843,727 filed on May 11, 2004, US provisional patent application No. 60 / 591,978 filed on July 28, 2004, filed July 27, 2004. United States provisional patent application No. 60 / 591,663, United States provisional patent application No. 60 / 590,738 filed on July 22, 2004, and United States provisional patent application No. 60 / filed on July 28, 2004. Claims 592,000 priority.

  By quoting copending US patent application No. 10 / 351,030 entitled “Reconfigurable Semantic Processor” filed by Somsubhra Sikdar on Jan. 24, 2003, the contents of which are incorporated into this application. It shall be.

  The present invention relates to a storage server, and more particularly to an embodiment of a storage server using a digital semantic processor.

  Traditionally, a storage server is a networked computer that provides media and file access to other computers and computer equipment (hereinafter “clients”). This storage server can be accessed through a World Wide Network (WAN) or a Local Area Network (LAN). The storage server may also share a dedicated point-to-point connection with other computer equipment.

  Storage servers may be of various types including Network Attached Storage (NAS) servers, Storage Area Network (SAN) servers, application type servers, and so on.

  The NAS server has a directory structure. A request to the NAS server usually specifies a file path or file name, or specifies an action such as creation, reading, writing, or attachment. The NAS server translates the request into disc sector / block disc access transactions to one or more disk sectors or blocks, accesses the disk (or other storage medium), and is requested Perform file-level transactions. Such servers maintain and use a directory structure to find the start of a file. Such servers also maintain and use file allocation tables to reconstruct segmented files and find free sectors on disk or writable media. .

  SAN servers typically receive direct requests for transactions based on disk sectors or blocks. And the SAN server does not need to understand the relationship between file systems and data blocks. A block request may relate to a physical block location on the media device, but more typically the SAN server supports logical blocks. In this way, the server can make a physical single disk drive appear logically as multiple disk drives. Further, like a RAID (Redundant Array of Independent Disks) scheme, a plurality of disk drives can be made to appear as a single disk drive in theory.

  Application-type servers generally provide access to media in a media-specific format. For example, an application-style server (which may not know the file name or may not have permission to access the file directly) does not have a clear file path or file name from the client, Access to music or video can be provided. On the other hand, it reads the streaming media from the file and encapsulates it in the streaming packet format.

  By structure, the vast majority of storage servers are very different from general purpose computers (in some cases, they may have more high-speed disk drives and disk bus controllers than typical computers). FIG. 1 is a block diagram of a typical storage server 20. The central processing unit (CPU) 22 is typically one or more microprocessors and operates the server according to stored program instructions. This processor is often called a von Neumann (VN) processor or a von Neumann (VN) machine, after von Neumann, who has proposed and implemented an execution format that processes sequential instructions.

  The CPU 22 is connected to a memory controller / hub (MCH) 24 via a front bus (FSB) 26. This relates to connecting the CPU 22 to other system components that store microprocessor program instructions, store, supply, and consume data. The MCH 24 controls the system memory 30 via the memory bus 32. Further, the MCH 24 communicates with a PCI (Peripheral Component Interconnect) bridge 40 via the hub bus 42 to exchange data between either the memory 30 or the CPU 22 and a PCI-connected device.

  Various data sources and data sink devices can be connected to the server 20 via the PCI bridge 40 and the PCI bus 44. Two essential devices for use as a storage server are a network controller card (NIC) 50 and a media controller 60 such as an ATA (AT Attachment).

  The NIC 50 allows the server to connect directly to a local area network (LAN) or other network or Fiber Channel switch structure. It also enables point-to-point connections with other devices that make the network visible to clients and servers. Thus, NIC 50 provides a communication path to the server, receives data requests from clients, and responds to those requests. The actual network physical communication protocol, for example, inserts a different NIC and loads the software device driver for that NIC into the CPU 22 no matter what wired or wireless communication protocol is used Can be changed.

  The ATA controller 60 provides at least one ATA bus 62 for connecting a hard disk, an optical disk, a tape drive, and the like. Each ATA bus 62 allows one or two media devices 64 to be connected to the storage server 20. Depending on the server, other control devices such as a SATA (serial ATA) control device or a SCSI (Small Computer System Interface) host adapter may be used.

  In order to operate as a storage server, the CPU 22 must execute various software programs. For NAS, two common formats are NFS (Networked File System) and CIFS (Common Internet File System). The former protocol is mainly used in a UNIX environment, and the latter protocol is mainly used in a Microsoft OS environment. For the NFS server, the following software processes help run NFS: Network device driver for NIC 50, TCP / IP driver, RPC (Remote Procedure Call) driver for sending data from TCP / IP to NFS server software, XDR (External Data Representation) driver, NFS server software VFS (Virtual File System) driver, data buffering software, storage controller / host adapter (storage controller / host) to interface itself, local file system, NFS server software with local file system device drivers for adapters). For each NFS data transaction, CPU 22 must execute a process for each of these software, changing context as required between the respective software. In order to provide sufficient capacity, the storage server 20 must operate at relatively high speed and high power, including a microprocessor, chipset, network interface, memory, and other peripherals, In order to operate the cooling fan, forced air cooling and sufficient power supply are required. In the current state of the art, a network connection for 1 Gbps (Gigabit per second) full-duplex communication requires about 300 watts of power, occupies a volume of 800 cubic inches, and excludes storage media for about $ 1500 It will be an expense.

  Some manufacturers are trying to make IC hardware specifically designed to handle NAS requests. In general, the design cost of such an IC cannot be recovered by the fast-flowing remote communication protocol industry. In this industry, certain complex circuit designs created to handle the limited combination of specialized protocols and storage interfaces often quickly become obsolete.

  In many storage server applications, a microprocessor-based approach using sequential programs has been recognized as inefficient and bulky. At present, the majority of storage servers (most of the storage servers's existence) are used to perform storage server functions in response to requests from clients received by the NIC. The request itself is represented in a protocol-specific format with a limited number of requested functions and options. In response to these requests, well-defined storage system commands are sent to the media device, and the results of these commands are used to return protocol-specific datagrams to the client.

  It is a highly desirable property that the storage server is programmable and has code commonality. Therefore, high-capacity processors and chipsets (for example, those from Intel Corporation and Advanced Micro Device) have been used to allow storage servers to be programmed and standard operating systems to be used. , Thereby reducing costs. Unfortunately, with such an operational structure, the flexibility and power of a general purpose microprocessor-based system will be rarely used or only used inefficiently.

  The present invention provides a different architecture for the storage server, and in its representative embodiment, what is commonly referred to as a semantic processor is used. Such a device is configurable and is preferably reconfigurable like a VN machine whose processing depends on its "programming". As used herein, a “semantic processor” has at least two components: A direct execution parser to parse the input stream based on a defined grammar, and control data in response to requests from the direct execution parser (eg, data movement, mathematical It is a direct execution engine that can perform operations and logical operations).

  Semantic processor programming differs from the standard machine code used for VN machines. In a VN machine, the protocol input parameters of the data packet are compared sequentially with all possible inputs using sequential machine instructions, branching, looping and thread switching inefficiencies. In contrast, the semantic processor responds directly to the “semantics” of the input stream. In other words, the “code” segment executed by the semantic processor is directly driven by the input data. For example, for about 75 CIFS commands that can appear in a packet, the following is needed to allow the semantic processor to load the grammar and microinstructions associated with the actual CIFS command sent in the packet: Only a single analysis cycle in the embodiment described in.

  In the storage server application described in the examples below, the semantic processor can perform many of the functions of a conventional VN processor, chipset, and accessory equipment. The semantic processor receives datagrams from a network port or datagram interface. Some of these datagrams will contain client requests for data operations. The semantic processor parses the elements of the received datagram using a parser table designed for the server protocol grammar supported by the server. Based on what has been parsed, the semantic processor performs a response data operation with one or more data stores. Data operations are performed by invoking microinstruction code segments on single or multiple simple execution units. When a data operation is performed, the semantic processor creates a response datagram to send back to the client. Due to the resulting operational efficiency, in some embodiments, the entire storage server can be packaged into several integrated circuits that are relatively small and can be placed on a printed circuit board of a media device. Yes, the semantic processor itself will probably only consume a few watts of power.

  The present description can be best understood by reading the disclosure of the present application (the best mode for carrying out the invention) based on the accompanying drawings below.

  FIG. 2 shows a high-level block diagram representing many embodiments according to the present invention. The storage server includes a semantic processor 100 having a datagram interface 90 and a storage interface 110. The datagram interface 90 provides the client with a server connection, eg, via a network 80 (shown below) or a point-to-point connection with the client. Storage interface 110 provides the semantic processor with a path to initiate a data transaction with data storage device 120 in response to a request from a client. This data storage device may be local. In addition, this data storage device may be network-connected to the illustrated server, for example, when the semantic processor 100 is emulating a NAS server for a client. In that case, the remote SAN server is used as a physical storage device at the same time.

  FIG. 3 shows a more detailed block diagram of the storage server 200 with the semantic processor 100. Datagram interface 90 connects buffer 130 of semantic processor 100 with physical interface device (PHY) 92. Examples of physical interface devices (PHY) 92 include optical or optical interfaces for Ethernet, Fiber Channel, 802.11x, Universal Serial Bus (USB), FireWire, and other physical layer interfaces. For example, an electric or wireless driver / receiver pair. The datagram interface provides an input digital data stream to the buffer 130 and receives an output digital data stream from the buffer 130.

  In FIG. 3, the storage interface 110 is implemented as a block I / O bus between the data storage device 120 and the semantic processor 100. In various embodiments, the bus may be a cable connection (iSCSI, Fiber Channel, SATA) or a circuit board bus (SATA) depending on how the semantic processor and data storage are configured. FIG. 3 shows the main elements of a hard disk type media device such as the disk controller 122, drive electronics 124 and disk 126 (a collection of disk disks, motors and read / write heads).

  One configuration of the semantic processor 100 is shown in the storage server shown in FIG. Semantic processor 100 includes a direct execution parser (DXP) that controls the processing of incoming packets or incoming frames (eg, incoming “streams”) received at buffer 130. The DXP 140 maintains a built-in parser stack consisting of terminal symbols or non-termina symbols based on parsing from the current frame to the current symbol. If the symbol at the top of the parser stack is a terminal symbol, DXP 140 compares the data at the beginning of the input stream with the terminal symbol and expects them to match to continue working. If the symbol at the top of the parser stack is a non-terminal symbol, DXP 140 uses the non-terminal symbol and the current input data to extend the grammber production on the stack. While parsing continues, DXP 140 instructs Semantic Code Execution Engine (SEE) 150 to process the input segment or perform other operations.

  This structure is equipped with a high performance grammar parser that assigns tasks to execution engines according to data requirements, and is adaptable and highly effective for highly structured inputs such as datagram protocols. In the preferred embodiment, the semantic processor can be reconfigured by changing its table, thereby having the flexibility that is the attraction of VN machines. Semantic processors typically operate more efficiently with a smaller instruction set than VN machines because they respond to given inputs. As described below, this instruction set is useful because the semantic processor allows data processing within the machine context.

  Semantic processor 100 uses at least three tables to perform a predetermined function. A code for retrieving production rules (code for retrieving production roule) is stored in a parser table (PT) 170. Grammatical production rules (grammatical production rules) are stored in a production rule table (PRT) 180. Code segments for SEE 150 are stored in Semantic Code Table (SCT) 190.

  The code in the parser table 170 indicates the generation rule in the generation rule table 180. The parser table code is stored, for example, in a row-column format or a content addressable format. In matrix format, table rows are indexed by non-terminal code on the internal parser stack. The columns of the table are then indexed by the input data value at the beginning of the input (eg, a symbol currently on Si-Bus). In the content addressable format, input to the table can be provided by concatenating non-terminal codes and input data values.

  The production rule table 180 is indexed by the code in the parser table 170. These tables may be linked as shown in FIG. 3 so that the query to the parser table sends back directly the generation rules applicable to the non-terminal code and input data values. The direct execution parser replaces the non-terminal code at the top of the stack with the production rules sent back from the PRT, and then continues parsing its input.

  In practice, code for many different grammars can exist simultaneously in the production rule table. For example, one set of codes is assigned to MAC (Media Access Control) packet header format analysis, and the other set of codes is used for Address Resolution Protocol (ARP) packet processing and Internet Protocol (IP) packet processing. It can also be assigned to communication control protocol packet (TCP) processing, real-time transfer protocol (RTP) processing, and the like. Syntax for CIFS, NFS, and other storage server protocols is added to the production code memory to add storage server functionality. Non-terminal codes need not be assigned in any particular order in the production rule code memory 122, nor do they need to be assigned in any particular order within the blocks associated with a particular protocol.

  Semantic code table 190 can be indexed by parser table code, indexed from production rule table 180, or both. In general, the analysis results allow DXP 140 to determine whether a code segment from semantic code table 190 should be loaded and executed by SEE 150 for a given production rule.

  The semantic code execution engine 150 has an access path to the machine context 160. The machine context 160 is a configured memory interface and can be addressed by a context symbol. The machine context 160, the parser table 170, the generation rule table 180, and the semantic code table 190 include internal memory devices such as synchronous DRAM and synchronous CAM, external memory devices, or combinations of such resources. It may be used. Each table or context may simply provide one or more of the other tables or contexts to the context interface for the shared physical memory space.

  Details of the optimal design for the functional blocks of the semantic processor 100 are not within the scope of the present invention. See copending US Patent Application No. 10 / 351,030 for some examples of detailed architectures of functional blocks of applicable semantic processors. The contents of this application are hereby incorporated by reference into this application.

  The functionality of the semantic processor 100 within the storage server context can be better understood by way of example. In this example, CIFS commands and CIFS data structures are used together with structures supported by Ethernet, IP, and TCP. Those skilled in the art will appreciate that the concepts taught herein are equally applicable to other server communication protocols.

  FIG. 4 shows the header / data block associated with Ethernet / IP / TCP / CIFS frame 250 (ignoring trailers and checksums). The MAC header is intended to include the MAC address of the server 200 for every frame intended to be provided to the server 200, along with others. The server 200 supports various networks and transfer protocols. In this example, a network header of Internet protocol (IP) and a transfer protocol header of communication control protocol (TCP) are used. The TCP header is followed by a header 1 which is a CIFS storage message block (SMB) header and a buffer 1 which is an SMB data buffer having data related to the header 1. Many CIFS operation codes can be combined with other CIFS operation codes in the same SMB as needed as long as the maximum frame length does not exceed the limit. The additional headers for the second, third, etc. operation codes have only the last few fields of the first header, and all other fields are implied from the first header. As shown, the last SMB header includes a header N and a buffer N.

  FIG. 5 shows further details of the first SMB header and SMB buffer of the frame. The complete SMB header first indicates the protocol. That is, character 0xFF indicates that this is an SMB header. The command character follows the protocol character and indicates the operation code for either the requested or responded action. The status and flag fields determine how to interpret other fields in the SMB, determine whether an error has occurred, or both. A MAC signature (in this example, MAC stands for Media Authorization Code) is used for message authentication when it is valid.

  The next four fields in the SMB are the TID, PID, UID, and MID fields. A TID (Tree Identifier) is given from the server to the client when the client successfully connects to the server resource. The client makes an inquiry to the resource using the assigned TID in a later request. A PID (process identifier) is given by the client (the server writes down the PID and uses it to respond to the client, but its use is primarily by the client). The UID (user identifier) is given by the server to identify the user who authorized the connection. The MID (multiple identifier) allows the client to use the same PID for a plurality of unresolved transactions by using a different MID for each transaction.

  The parameter field is variable in length and structure, generally the first character represents the length of the next parameter, followed by the parameter word appropriate for the SMB operation code. If this operation code indicates that the second SMB header and SMB buffer follow, a portion of the parameter word indicates the subsequent operation code and makes up for the subsequent shortened header.

  SMB ends with a byte count and byte count length buffer. Such a buffer is used, for example, for transmitting a file name, transferring written data to a server, transferring read data to a client, and the like.

  Against this backdrop, a description of basic CIFS functionality for the semantic processor 100 (shown in FIG. 3) can proceed.

  As shown in FIGS. 3 and 4, each new frame received in buffer 130 begins with a MAC header. This MAC header includes a destination address, a source address, a payload type field, a payload, and a checksum. The DXP 140 analyzes the destination address in the hope that the destination address matches the address assigned to the storage server 200 and that it matches the broadcast address. If the destination address cannot be parsed, DXP will launch a SEE code segment on SEE 150 and erase this frame. Otherwise (otherwise) the source address is consumed by the SEE and saved for use in reply. The payload type field is then parsed.

  In this example, the MAC payload type is analyzed for IP. Therefore, DXP loads the production rules for parsing the IP header on its parser stack and works through the IP header. For example, this can be done by analyzing the destination IP address to check that the packet was intended to be delivered to the storage server, checking the IP header checksum, updating the addressing table, Storing the destination and source addresses for processing and other processing, and dispatching the SEE to reconstruct the fragmented IP packet. The protocol indicated by this IP header is parsed to load the production rules for the next header (TCP header in this example) on the DXP parser stack.

  The TCP header is then parsed. SEE is sent to load the TCP connection context associated with the destination IP address, source IP address, destination port, and source port (only if a valid connection exists). In this embodiment, such a case is assumed). The SEE then consumes a sequence number, an acknowledgment number, a window, a checksum, and other fields necessary to update the connection context. This context is saved for use when replying.

  Assuming that the MAC, IP, and TCP headers have been parsed for a valid connection with the storage server, the next symbol on the input stream indicates that this data contains an SMB request. DXP 140 parses this symbol and loads the CIFS grammar generation rules onto its stack.

  This next input symbol is matched with a non-terminal symbol for the CIFS command (CIFS operation code). For example, the parser table may have an entry for each possible combination of CIFS operation code and non-terminal symbol. When a CIFS command is parsed, the grammar associated with the CIFS operation code in the command field is loaded onto the parser stack.

  CIFS header status and flag fields may be parsed, but are preferably consumed by SEE 150 and stored in machine context 160 for use in interpreting packet content.

  Also, the MAC signature, TID, PID, UID, and MID fields are directed (sent) to the SEE. This SEE saves this field for use when reconstructing the reply frame, and uses the machine context 160 to authenticate that the packet is sent from a valid source and is directed to the appropriate resource. Perform a search within.

  The format of the parameter field depends on the CIFS operation code. Depending on the operation code, it may be preferable to instruct the SEE 150 to parse the parameter field elements or consume parameters that use microcode segments. Below are some examples of common CIFS commands.

  A CIFS NEGOTIATE client request is used by a new client to identify a CIFS dialect that the client can understand. The parameter field for NEGOTIATE contains a byte count followed by a byte count symbol that lists acceptable dialects as null-terminated strings. The production rules for NEGOTIATE tell DXP 140 to have SEE 150 store the byte count, and then DXP 140 parses the first input string up to the null character. If the string is parsed as a known dialect, DXP 140 causes SEE 150 to save the code for the dialect corresponding to the current frame context. SEE 150 also determines whether the byte count symbol has been analyzed (indicating that all dialects have been analyzed). Otherwise, SEE 150 places the non-terminal symbol on top of the parser stack and causes DXP 140 to parse the remaining input for the other dialects. This process continues until the byte count symbol is parsed. At the same time, SEE 150 places the symbol at the beginning of the input stream and causes DXP 140 to stop parsing the dialect. DXP 140 then finishes parsing the packet, directs SEE 150 to select a dialect (eg, according to a pre-programmed hierarchical preference), and returns a reply packet with the parameters associated with the new session. In addition, SEE 150 sets up a new session context in machine context 160.

  When the client receives a NEGOTIATE reply, the client typically sends an SMB for SESSION_SETUP_ANDX to complete the session. As soon as DXP 140 receives the SMB, it can analyze the first parameter (total number of words) and confirm that it is appropriate as an operation code. The second parameter, And X Command, indicates whether (and which second command X appears in) the second command X also appears in this frame after this command. CIFS uses “AndX” to identify an operation code that can be concatenated with the following operation code to form a multi-operation code SMB). If And X Command indicates that the second operation code does not exist (0xFF), DXP 140 can parse it and continue working. If there are separate operation codes, the process becomes more complex.

  The second operation code can be processed in various ways. The first method is to write different grammars for all possible combinations of the first and second operation codes. Although this method is feasible, it can be inefficient depending on the limitations of the parser table and the generation rule table. The second method uses multilevel grammar. In this method, the high-level grammar analyzes the operation code and processes each code for which the low-level grammar has been analyzed. The third method is to use a pushback mechanism from SEE 150. In this way, for example, the And X Command parameter loads a production rule that causes SEE 150 to save And X Command from the input stream. When the first operation code has been fully parsed, SEE 150 is instructed to activate a microcode segment that returns the And X Command parameter to the beginning of the input stream. DXP 140 then parses the new operation code and, if a second operation code exists, continues to load the parameter field grammar for the new operation code from that point. And X Command added in SMB can be processed in the same way.

  The other SESSION_SETUP_ANDX parameters will probably be consumed by SEE 150 without being parsed, since they are mostly stored in the session context or verified in the case of passwords. The parameters of null-terminated strings can be parsed to look for null-terminated symbols, followed by a save instruction for the SEE 150 whose length has been determined at this point.

  Once the SESSION_SETUP_ANDX command is analyzed, the SEE 150 can be instructed to create a reply packet. However, if the second operation code is included, the packet is not completed until each operation code is processed.

  The LOGOFF_ANDX command is used to end a session. The first function performed by the semantic processor in response to this operation code is to have the SEE 150 remove the session context for this session from the machine context 160.

  The TREE_CONNECT_ANDX command is used to associate a session with the shared server resource indicated by the parameter string path. The path string included with this command can be parsed for length only, parsed for the correct server name, or both. The rest of the path name can be parsed. However, since valid paths can be created and destroyed frequently on writable resources, it may be challenging to maintain the correct generation code for each directory. Thus, in general, the path will be sent to SEE 150 for initiation. Alternatively, DXP 140 searches for and analyzes the “/” character and sends a pass to SEE 150 one level at a time.

  SEE 150 reads the directory stored in data storage device 120 via the block I / O bus, starts from the root directory, and confirms that the requested path exists and is not restricted by the client. By confirming, it passes a specific path. Assuming the path is valid and valid, SEE 150 creates a reply packet and saves the path in the session context.

  The NT_CREATE_ANDX command creates or opens a file or directory. DXP 140 may pass most of this command to SEE 150 for block I / O transactions with data storage device 120, similar to when using the TREE_CONNECT command. SEE 150, if possible, modifies the appropriate directory, assigns a file identifier (FID) to the opened file, and creates a file context in machine context 160 for the opened file. To open and / or create a file. SEE 150 then formats an appropriate response frame indicating the result of the file creation request / file open request.

  The READ_ANDX command is used by the client to read data from the open FID, and the WRITE_X command is used by the client to write data to the open FID. When DXP analyzes down to the FID parameter, it signals SEE 150 to retrieve the FID from the Si-bus and search the corresponding file context in machine context 160. The SEE 150 then executes the appropriate block I / O transaction, reads or writes data to the data storage device 120, and constructs a reply packet to the client (construct). In some cases, the write operation return frame may be generated and transmitted before all block I / O transactions with the data storage device are completed.

  The commands described above are part of a CIFS command that can be executed. Those skilled in the art will understand from these above examples how the semantic processor performs the full CIFS function. Further, the concepts illustrated by the semantic processor executing these CIFS commands can be applied to executing other storage server protocols on the semantic processor.

  FIG. 6 shows another semantic processor embodiment 300. The semantic processor 300 includes four semantic code execution engines 152, 154, 156, and 158. Semantic code execution engine 158 communicates with block I / O circuit 112. The machine context 160 has two functional units. The two functional units are a variable machine context data memory (VMCD) 162 and an array machine context data memory (AMCD) 164. Each SEE can exchange with the VMCD 162 via the V-bus, and can exchange with the AMCD 164 via the A-bus.

  When semantic processor 300 determines that DXP 140 should start an SEE task at a particular point during analysis, DXP 140 signals one of the SEEs to load microinstructions from SCT 140. Tell. A handle to some instruction segment may cause DXP 140 to indicate that it can select any available SEE. This handle may also indicate that a particular SEE (eg, SEE 158 has only one access to block I / O) should receive that code segment. The availability of multiple SEEs allows many slow tasks (eg, block I / O) to run in parallel without disturbing all processing.

  Although not strictly necessary, a specific type of task can be assigned to a specific SEE. For example, SEE 152 can be a designated input protocol SEE. This input protocol SEE is responsible for the task of processing the input side of IP, TCP and other protocols and updating the client, session, and file context with data from the incoming CIFS frame. In addition, SEE 154 can be specified to perform file system operations. This file system operation includes, for example, understanding and updating directories, file allocation tables, and user / password lists, authenticating users and requests, and the like. Further, the SEE 156 can be designated to perform processing on the output side of the protocol such as creation of a reply frame. In addition, SEE 158 may be specified to handle exchanges with data storage devices. This division allows one SEE to launch microcode on other SEEs without having to go through DXP 140, which may have begun working on different analysis tasks. For example, the SEE 154 can activate a task on the block I / O SEE 158 and read or rewrite (update) the directory. As another example, the output protocol SEE 156 can have a semaphore set by other SEEs when the data is ready for the return packet.

  Each SEE has a pipeline register that allows the machine context to access the data. In contrast to normal CPUs, the preferred SEE embodiments do not have the concept of physical data storage used for the data they process. Instead, access to data takes the form of machine context transactions. Variable (eg scalar) data is accessed via the V-bus. Array data is accessed via the A-bus. Input stream data is accessed via the Si-bus. For example, to read an element of scalar data of length m octets located at a predetermined storage location offset in the data context ct, the SEE uses an instruction decoder and sends a bus request {read, ct, offset to the V-bus interface. , m} to issue. The context mct queries the master context of the semantic processor. Other subcontexts, such as the subcontext for each CIFS session in operation, each open file, each open transaction, etc. are typically created and destroyed as the RSP processes the input data.

  The SEE pipeline register controls the data transfer process as soon as a command is sent. When multiple bus transfers are requested to read or write m octets, the pipeline register tracks the transaction to completion. As an example, a 6 octet field is transferred from a stream input to a machine-context variable using two microinstructions. The first instruction is to read 6 octets from the Si-bus into the pipeline register. The second instruction is then to write 6 octets from this register to the variable machine context via the V-bus. This register interface implements no matter how many bus data cycles are needed to accomplish the transfer.

  VMCD 162 serves requests initiated on the V-bus. VMCD 162 can translate variable machine context data requests into physical memory transactions. To that end, VMCD 162 preferably maintains a translation table that references the machine context identifier for the physical memory start address and has a mechanism for allocation and deallocation. The VMCD 162 then allows the context to be fixed by a given SEE and ensures that the requested transaction does not fall outside the boundary of the requested context. The actual storage mechanism used can vary from application to application. The memory can be fully internal, fully external, or in two forms. Also, a cache having a large external memory can be used. External memory may be shared with external memory for other memory sections. Examples of the memory section include an AMCD, an input buffer, an output buffer, a parser table, a generation rule table, and a semantic code table in a predetermined embodiment.

  The A-bus interface and AMCD 164 operate similarly except that they have a machine context array configuration. It is preferable to be able to execute allocation, deallocation, writing, reading, searching, and even hashing and sorting using simple bus requests for different types of arrays and tables. The actual underlying physical memory may be different for different types of arrays and tables. This physical memory includes, for example, a high-speed onboard RAM, an external RAM, an external ROM, a content accessible memory, and the like.

  The storage server configuration shown in FIG. 3 is one of many possible functional partitions of a server according to an embodiment of the present invention. Several other possible configurations are shown in FIGS. 7-10 and are described below.

  FIG. 7 illustrates a storage server 500 that includes an interface to one or more conventional SATA drives. A network connection 502 (a standard electronic or optical connector port or antenna) allows a client to communicate with a PHY 510 such as Fiber Channel, Ethernet, etc. that supports the required protocol. For Ethernet, a commercially available PHY such as Broadcom BCM 5421 or Marvell 88E1011 can be used.

  The PHY 510 supplies the input frame to the RSP 520 and extracts the output frame from the RSP 520. RSP 520 consists of one of the configurations described above, one of the configurations described in co-pending US patent application No. 10 / 351,030, or any other semantic processing configuration that is functionally similar. can do.

  The RAM 530 provides the RSP 520 with physical storage for machine context and buffers, for example. The RAM 530 may be composed of several types of memory (DRAM, Flash, CAM, etc.), or may be composed of one type of memory such as Synchronous DRAM. When the parser table, the generation rule table, and the semantic code table are stored in the volatile memory during operation, the startup ROM or the startup flash memory is used to initialize the RSP 520. As long as enough code is available in the startup memory to allow the RSP 520 to communicate with other data storage devices, a portion of the non-volatile stored table is also in the data storage device. Can exist.

  The SATA controller 540 is connected to the block I / O port of the RSP 520 and controls the disk access request of the RSP 520. The SATA controller 540 may be a commercially available SATA controller such as SII 3114 or Marvell 88SX5080.

  The SATA controller 540 is connected to one or more SATA data storage devices via a SATA bus. As illustrated, the storage server 500 supports the drives 550-0 to 550-N via the SATA bus 0 to SATA bus N, respectively.

  PHY 510, RSP 520, RAM 530 and SATA controller 540 are preferably connected to each other on a common printed circuit board (not shown). This printed circuit board can be placed in a common housing together with the drive by providing the bus 0 to bus N with the SATA cable. Alternatively, the SATA bus signal may be sent on the printed circuit board to the connector of each drive or through the connector to the backplane.

  Another storage server embodiment 600 is shown in FIG. Preferably, in this embodiment, the entire server is implemented on a printed circuit board of a disk drive having a network connection 602 for providing connection with the client of the storage server. The storage server architecture 500 can be packaged in the same way, but the storage server 600 can create PHY 610 and SATA controller 640 together in the RSP 620 to create space and reduce costs. Is realized. The SATA controller 640 is preferably implemented at least partially using SEE.

  The SATA controller section of the RSP 620 interface connects to the drive electronics 660 via a SATA cable or circuit board bus. The drive electronics 660 includes a SATA interface, disk cache, and drive control electronics.

  If the entire server is used on a common circuit board in the media device, the SATA interface can be completely removed as shown in storage server 700 of FIG. In FIG. 9, the functions of the disk controller are implemented in RSP 720. A controller (eg, Marvell 88C7500), illustrated as block 770, a motor, and a servomechanism directly connect to the RSP 720.

  FIG. 10 shows a storage server 800 that is essentially a translation gateway (“translation” gateway). The storage server 800 has a first physical network interface PHY1 (block 810) that connects to the network 802, thereby connecting to the storage server client. The storage server interface 800 also provides a second physical network interface for connection to one or more physical servers (eg, the illustrated SAN server 850) via a network or point-to-point connection. PHY 2 (block 840). The RSP 820 includes an attached memory 830 and is connected to the PHY 1 and PHY 2. The PHY 1 may be an Ethernet PHY, for example, and the PHY 2 may be a Fiber Channel PHY, for example.

  In operation, the RSP 820 responds to client requests, such as NAS type requests or application type requests, by initiating the request on a remotely connected server 850. In this way, the server 800 appears to the client on the network 802 and appears to the client from the server 850. Although the server 850 is illustrated as a SAN server, the server 850 may be a NAS server, and more specifically, may be an application type server. If PHY 1 and PHY 2 support the same server protocol, the storage server 800 can perform useful functions such as an aggregation point for an expandable server farm, an encryption point, and a firewall.

  If both PHY 1 and PHY 2 are supplying datagrams to RSP 820, RSP 820 can provide analysis for both of those input streams. For example, both PHY 1 and PHY 2 input streams can be stored in a common input buffer, and the DXP (not shown) in the RSP 820 can alternately analyze the datagrams in both input streams. And thus coordinate and execute bi-directional translation tasks. The RSP 820 may also be configured using two DXPs, one of which is assigned to each physical port, and these two share a common SEE storage location and other RSP resources. Good.

  The embodiments described above can be applied to other system architectures that provide access to multiple physical data storage devices as shown in FIGS. In FIG. 11, the storage server 900 connects the RSP 100 to a plurality of physical data storage devices (eg, four devices 120-1, 120-2, 120-3, 120-4 shown). It has. These data storage devices may be accessed as a RAID (Redundant Array of Independent Disks) array in some embodiments. In this case, the RSP operates as a RAID controller, or another RAID controller (not shown) is used as part of the storage interface 110. Alternatively, the four data storage devices may be configured as a JBOD (Just a Bunch Of Disks) array.

  In general, the RSP 100 can execute other forms of virtualized storage servers for clients. In another embodiment, a disk sector address used by a client application is mapped by RSP to a C-H-S (Cylinder-Head-Sector) address of a specific device among many physical devices. In such a form, the storage devices (in some cases more storage devices) from the data storage devices 120-1 to 120-4 need not be in the same spatial location, thereby providing physical resources for the client. In addition, the disk allocation can be controlled with high accuracy. In addition, the RSP can function in a virtual form in which another intermediate device provides all or part of the virtual function to the client.

  FIG. 12 shows a form in which the RSP is used in the storage server system 1000 incorporating the port expander 950. The port expander 950 connects to a single SATA controller port that is connected to the RSP 100 (externally or internal), while multiple physical data storage devices (shown) It can communicate with the devices 120-1 to 120-4). Although such a configuration uses only one port of the RSP to communicate with the data storage device, the overall system processing capacity (information amount / bandwidth) can be increased.

  FIG. 13 illustrates another embodiment 1100 of a semantic processor that can be used with embodiments of the present invention. The semantic processor 1100 communicates with the Port 0 PHY 93, the Port 1 PHY 94, and the PCI-X interface 95. All of these can be incorporated in the processor 1100 or externally connected to the processor 1100 as necessary. The buffer 130 shown in FIG. 3 is replaced with a port input buffer (PIB) 132 and a port output buffer (POB) 134. These buffers need not necessarily be in a common memory section built into the processor 1100 as part of the processor 1100, but are preferably arranged in this manner. PIB 132 is associated with and holds at least one input queue for each of Port 0, Port 1 and PCI-X interfaces, and can hold other queues as well. POB 134 is associated with and holds at least one output queue for each of Port 0, Port 1 and PCI-X interfaces, and can hold other queues as well. Port 0 and Port 1 are typically datagram interfaces such as Gigabit Ethernet, while the PCI-X interface is connected to a normal PXI-X bus. Depending on the design of the storage server, storage resources can connect to any of these ports, and clients can connect to port 1 and / or port 2 as well.

  Unlike FIG. 3, in FIG. 13, the direct execution parser 140 can receive input from each of a plurality of input queues in the PIB 132 via a parser source selector 136. For example, the direct execution parser 140 can maintain a separate parser stack for each input source. The direct execution parser 140 then switches the parser source to switch the input source if the analysis of the packet ends or the packet analysis stalls (for example, while the SEE is performing some computation on the packet field). A signal can be transmitted to the selector 136.

  The SEE cluster 152 includes N semantic code execution engines 150-1 to 150-N. The SEE cluster preferably includes a dispatcher (not shown) and communicates with the DXP 140 via the Sx-bus to deliver tasks to individual SEEs.

  PIB read controller 133 and POB write controller 135 provide SEE cluster 152 with access to PIB 132 and POB 134, respectively. As shown, the parser source 136 and the PIB read controller 133 allow the DXP 140 to operate on data from one input. On the other hand, SEE clusters access data from other inputs. PIB read controller 133 and POB write controller 135 preferably provide unrestricted access to the input and output buffers.

  Machine context port controller 154 provides SEE cluster 152 with access to machine context 160. Similar to the port buffer controller, the machine context port controller 154 provides the SEE cluster 152 with unrestricted access to the machine context 160.

  The machine context 160 preferentially executes memory tasks for the SEE cluster 152 and the management microprocessor 195. The machine context 160 normally includes one or a plurality of special caches, each of which is specialized according to a target data access attribute. The machine context 160 also includes one or more encryption engines and authentication engines that can be used to perform inline encryption and inline authentication. One or more conventional memory bus interfaces connect machine context 160 to physical memory 165. This physical memory may comprise, for example, a DRAM (Dynamic Random Access Memory), a CAM (Content Addressable Memory), or other types of preferred storage devices. The physical memory 165 may be provided on the processor 1100 or externally provided, or may be provided separately in these two arrangements.

  The management processor 195 implements the functions desired for the semantic processor 1100 that can be reasonably achieved with conventional software. For example, the microprocessor 195 can connect to the instruction space and data space used by the microprocessor itself in the physical memory 165 via the machine context 160 and execute conventional software. The processor then runs traditional software to start the processor, load or modify parser tables, generation rules tables and semantic code tables, collect statistics, perform logging, You can manage access and perform error recovery. Also, the microprocessor controller 195 is preferably communicable with a dispatcher in the SEE cluster 152 to request that the SEE perform tasks on behalf of the microprocessor. This management microprocessor is preferably incorporated into the semantic processor 1100.

  In the embodiment described above, the semantic unit can encrypt the block of data when the block of data is written to the disk, or it can decrypt the block of data when the block of data is read from the disk. This provides security for data that is “resting” on one or more disk drives. For example, when the semantic unit receives a data payload for writing to disk, the operation of preparing for the data payload for writing may include packet encryption. The reverse of this process may be performed when reading the encrypted data from the disk.

  Although an execution engine for special purposes has been illustrated and described thus far, in other embodiments the parser may be used as a front-end datagram processor for a general purpose processor.

  As illustrated in the foregoing embodiments, many different semantic processors based on storage servers are within the scope of the present invention. For the lowest function, for example, there is a possibility of being executed on a SAN type server connected to a corporate network by Fiber Channel. NAS type servers have more advanced features as described in the detailed CIFS embodiments described above. A translation-gateway server provides clients with access to a potentially huge and changing array of underlying physical servers. In this case, the physical server is not recognized by the client.

  Both the translation gateway server and the physical server may be constructed as application-type servers. In an application format server, data is stored in an application format. For example, a video-on-demand server can store video used by multiple clients and distribute different portions of the video to different clients, each with independent navigation. The music on demand server can operate in the same way.

  Application-style servers also store storage space for applications (like wired or wireless servers that store photos from digital cameras that allow digital cameras to work with relatively small internal buffers and flash cards). storage space). Such servers may be of a relatively small and battery-powered portable type for outdoor use.

  In addition, an embodiment of a storage server using a semantic processor may use a wireless protocol used in, for example, a home computer data network, an audio network, or a video network. While the detailed embodiments described above have focused on traditional “storage” devices, printers, scanners, multi-function printers and other data conversion devices can also be used in storage servers using semantic processors. Can be attached.

  Those skilled in the art will appreciate that the concepts taught herein can be applied to a particular application in many other effective ways. It will be readily apparent that a storage server using a semantic processor can be configured to handle different types of clients by changing the protocol that the server can analyze. If configured properly, the storage server can even analyze multiple storage server protocols at the same time, allowing access by clients of different tiers (eg, SAN access from trusted clients and NAS access from others). it can.

  FIG. 14 shows a block diagram of a semantic processor 2100 according to an embodiment of the present invention. The semantic processor 2100 includes an input buffer 2300 for buffering a data stream (eg, input stream) received via the input port 2110, and a direct execution parser (DXP) 2400 for controlling packet processing in the input buffer 2300. A semantic processing unit 2140 for processing the segments of the packet and performing other operations, and a memory system 2130 for storing or increasing the segments of the packet.

  The DXP 2400 maintains a parser stack 2430 consisting of non-terminal (and possibly terminal) symbols based on analysis up to the current input symbol for the current input frame or packet. If the single symbol (or symbols) at the top of the parser stack 2430 is a terminal symbol, the DXP 2400 compares the data DI at the beginning of the input stream with the terminal symbol and works Expect them to match to continue. If the symbol at the top of parser stack 2430 is a non-terminal (NT) symbol, DXP 2400 uses the non-terminal symbol NT and the current input data DI to extend the grammar product of stack 2430. While the analysis continues, the DXP 2400 instructs the SPU 2140 to process the segment of input data or perform other operations.

  Semantic processor 2100 uses at least three tables. Code segments for SPU 2140 are stored in semantic code table 2150. The complex grammar generation table is stored in a generation rule table (PRT) 2250. Production rule (PR) codes for retrieving these production rules are stored in a parser table (PT). The code in parser table 2200 also allows DXP 2400 to detect whether code segments from semantic code table 2150 should be loaded and executed by SPU 2140 for a given production rule.

  The production rule (PR) code in the parser table 2200 indicates the production rule in the production rule table 2250. The PR code is stored, for example, in a row-column format or a content addressable format. In the row-column format, the table rows are indexed by the non-terminal symbol NT at the top of the internal parser stack 2430, and the table columns are indexed by the input data value DI at the beginning of the input. The In the content addressable format, the concatenation of a non-terminal symbol NT and a single (or multiple) input data value DI provides an input to the table. Semantic processor 2100 uses a content addressable format (implement) so that DXP 2400 concatenates the non-terminal symbol NT with the 8-byte current input data DI and makes the input to the parser table Is preferred. Alternatively, the parser table 2200 may concatenate the non-terminal symbol NT received from the DXP 2400 with the current input data DI of 8 bytes.

  Some embodiments of the present invention include more elements than those shown in FIG. 14, but these elements are not important for an understanding of the operation of the present invention and are omitted in this disclosure. To do.

  In the following, a general parser operation for some embodiments of the invention will be described based on FIGS. 14, 15A, 15B, 16 and 17. FIG. FIG. 15A illustrates one possible implementation of parser table 2200. FIG. The parser table 2200 includes a generation rule (PR) code memory 2220. The PR code memory 2220 holds a number of PR codes that are used to access corresponding generation rules stored in a generation rule table (PRT) 2250. In practice, codes for many different grammars can exist simultaneously in the production rule code memory 2220. Unless required for a particular lookup implementation, this input value (for example, a non-terminal (NT) symbol concatenated with the current input value DI [n]) is not stored in the PR code memory 2220. It need not be assigned in any particular order. However, n in the example is the matching width in the selected byte.

  In one embodiment, parser table 2200 also includes an addresser 2210 that receives NT symbols and data values DI [n] from DXP 2400. The addresser 2210 concatenates the NT symbol with the data value DI [n] and stores the concatenated data value in the PR code memory 2220. Alternatively, the DXP 2400 may concatenate NT symbols and data values before sending them to the parser table 2200.

  Conceptually, it is often useful to view the structure of the production rule code memory 2220 as a matrix with one PR code for each unique combination of NT code and data value. It is not so limited. Different memory types and memory configurations may be appropriate for different applications.

  For example, in one embodiment, the parser table 2200 is implemented as a content addressable memory (CAM), and the addresser 2210 uses the NT code and key as a key for the CAM to retrieve the PR code corresponding to the production rule in the PRT 2250. Use the input data value DI [n]. The CAM is preferably a ternary CAM (TCAM) belonging to a TCAM entry. Each TCAM entry (entry) is composed of an NT code and a DI [n] match value (DI [n] match value). Each NT code can hold multiple TCAM entries. Each bit of DI [n] match value (DI [n] match value) is set to “0”, “1” or “X”. This “X” represents “Don't Care”. With this feature, the PR code only needs to match the DI [n] of the number of bits or numbers of bytes and the coded pattern in order for the parser table 2200 to find a match. . For example, a row of TCAM has an NT code NT_IP for the destination IP address field, followed by 4 bytes representing the destination IP address corresponding to the device that is to be incorporated into the semantic processor. The remaining 4 bytes of this TCAM line are set to “Don't Care”. Thus, when NT_IP and 8 bytes of DI [8] are presented to the parser table 2200, if the first 4 bytes of DI [8] contain the correct IP address, the remaining DI [8] A match will occur no matter what the 4 bytes contain.

  TCAM employs the “Don't Care” function, and since there may be multiple TCAM entries for one NT, the TCAM has a predetermined NT code and DI [n] match value (DI [n] For match value, multiple matching TCAM entries can be found. The TCAM prioritizes these matches through its hardware and outputs only the highest priority match. Further, when the NT code and DI [n] match value (DI [n] match value) are presented to the TCAM, the TCAM receives the NT code and DI [n] received for each TCAM entry (entry) in parallel processing. Attempts to match with a match value (DI [n] match value). Therefore, the TCAM has the function of determining whether a match is found in the parser table in one clock cycle of the semantic processor 2100.

  Another way of looking at this architecture is to look at it as a “variable look-ahead” parser. TCAM receives a fixed data input segment (eg 8 bits), but TCAM encoding allows subsequent production rules to be generated based on any part of the current 8-byte input . If one bit or one byte within the current 8 bytes of the first part of the input stream is relevant to the current rule, the TCAM entry is coded to ignore the rest during the matching operation May be used. In essence, the current “symbol” can be defined by some combination of 64 bits of the leading portion of the input stream for a given production rule. In general, by intelligently coding, the number of analysis cycles, the number of NT codes, and the number of table entries can generally be reduced for a given analysis task.

  As described above, the TCAM in the parser table 2200 generates a PR code corresponding to the TCAM entry 2230 that matches NT and DI [n]. The PR code may be sent back to the DXP 2400, sent directly back to the PR table 2250, or both. In one embodiment, the PR code is the row index of the TCAM entry that creates a match.

  If there are no TCAM entries matching NT and DI [n], there are several other options. In one embodiment, the PR code is accompanied by a “valid” bit. This bit remains unset if there is no matching TCAM entry in the current input. In another embodiment, parser table 2200 constitutes a default PR code corresponding to the NT supplied by the parser table. The use of legitimate bits and default PR codes is described below in connection with FIG. 15B.

  When the DXP 2400 and the SPU 2140 are integrated into one circuit, the parser table 2200 is arranged in a built-in manner, arranged outside, or both. For example, a built-in static RAM (SRAM) or TCAM can operate as the parser table 2200. Alternatively, external DRAM storage or TCAM storage can store the parser table 2200. The parser table 2200 includes an addresser 2210 that operates as a memory control device for the external memory or communicates with the memory control device for the external memory. In one embodiment, parser table 2200 can be located in external memory that includes a built-in cache that can hold a portion of parser table 2200.

  FIG. 15B shows a possible implementation of the generation rule table 2250. The PR table 2250 includes a generation rule memory 2270, a match all parser entry table memory 2280, and an addresser 2260.

  In one embodiment, addresser 2260 receives a PR code from either DXP 2400 or parser table 2200 and receives an NT symbol from DXP 2400. Preferably, the received NT symbol is the same as the NT symbol sent to parser table 2200 and is used to place the received PR code. The addresser 2260 uses the received PR code and NT symbol to access the corresponding production rule and default production rule, respectively. In the preferred embodiment of the present invention, the received PR code addresses the production rule in the production rule memory 2270. The received NT code then addresses the default production rule in MAPT 2280. Addresser 2260 is not necessary in some embodiments, but if used, it may consist of part of DXP 2400, part of PRT 2250, or as an intermediate functional block You can also. For example, if the parser table 2200 or DXP 2400 directly configures an address, an addresser may not be required.

  The generation rule memory 2270 stores a generation rule 2262 including three data segments. These data segments include a symbol segment, an SPU entry point (SEP) segment, and a skip byte segment. These segments may be fixed length segments or variable length segments, and are preferably null-terminal. The symbol segment has either a terminal symbol or a non-terminal symbol transferred onto the DXP parser stack 2430 (FIG. 17). The SEP segment has an SPU entry point (SEP) that is used by the SPU 2140 during the processing of segment data. The skip byte segment has skip byte data that is used by the input buffer 2300 to increment its buffer pointer and to proceed with the input stream. Further, other information useful in the generation rule processing may be stored as a part of the generation rule 2262.

  MAPT 2280 stores a default production rule 2264. In this embodiment, this generation rule has the same structure as the PR in the generation rule memory 2270, and is accessed when the PR code is not found during the parser table search.

  Although the production rules memory 2270 and MAPT 2280 are illustrated as two separate memory blocks, the present invention is not so limited. In the preferred embodiment of the present invention, production rule memory 2270 and MAPT 2280 are implemented as internal SRAM, with each production rule and each default production rule holding a plurality of null-terminated segments.

  Since production rules and default production rules can have various lengths, it is preferable to take an approach that allows them to be easily indexed into their individual memories 2270 and 2280. In one approach, each PR has a fixed length that can include a fixed maximum number of symbols, SEPs, and auxiliary data such as skip byte fields. If a given PR code does not require the maximum number of symbols or SEP allowed, the sequence is terminated with a NULL symbol or SEP. If a given PR requires more than the maximum number, it can be split into two PRs. These are accessed, for example, by having the first PR have a skip byte value of zero and transferring NT to the stack that allows the second PR to be accessed in the subsequent analysis cycle. In this approach, a one-to-one correspondence between the TCAM entry and the PR table entry can be maintained so that the row address obtained from the TCAM matches the row address of the corresponding generation rule in the PR table 2250.

  The MAPT 2280 section of PRT 2250 is similarly indexed except that it uses PR codes instead of NT codes. For example, if a valid bit on the PR code is not set, the addresser 2260 can select the row corresponding to the current NT as the PR table address. For example, if 2256 NTs are allowed, the MAPT 2280 can include 2256 entries, each indexed to one of the NTs. If the parser table 2200 has no entry corresponding to the current NT and data entry DI [n], the corresponding default generation rule from the MAPT 2280 is accessed.

  Considering the destination IP address as an example, the parser table can be configured to respond to, for example, one of the two destination addresses expected during an appropriate analysis cycle. For all other destination addresses, no parser table entry will be found. Addresser 2260 will then retrieve the default rule for the current NT that instructs DXP 2400 and / or SPU 2140 to delete the current packet as an irrelevant packet.

  The approach to indexing the production rule table described above provides relatively simple and quick rule access, but other indexing schemes may be implemented. For variable length PR table entries, the PR code can be computationally controlled to determine the starting address of the production rule's physical memory (for example, the production rule is stored with an extended length, Then, if the PR code is assigned according to the place where the rule is stored, it is executable). In other approaches, by using an intermediate pointer table, the address of the production rule can be determined from the PR code in the PRT 2250, and the address of the default production rule in the MAPT 2280 can be determined from the NT symbol.

  After describing in more detail one additional functional unit, input buffer 2300, the use of symbols, SEPs, and skip byte values from production rule 2262 or 2264 are further described below.

FIG. 16 shows an example of one possible input buffer 2300 that can be used in embodiments of the present invention. The input buffer 2300 includes the following elements.
A buffer 2300 that receives data via input port 2110.
A control block 2300 for controlling data in the buffer 2310.
Error confirmation (EC) block 2320 to check if the received data has a transfer error.
A FIFO block 2340 that allows the DXP 2400 to have FIFO access to the data in the buffer 2310.
A random access (RA) block 2350 that allows the SPU 2140 to have random access to the data in the buffer 2310.
EC block 2320 preferably checks whether the received data frame or packet contains an error by checking for interpacket gap (IGP) violations and Ethernet header errors and calculating a cyclic redundancy code (CRC). Determine.

  When a packet, frame, or other data segment is received at buffer 2310 via input port 2110, input buffer 2300 forwards the port ID to DXP 2400 and informs DXP 2400 that new data has arrived. . The EC block 2320 checks whether there is an error in the new data and sets a status bit that is sent to the DXP 2400 as a status signal. When DXP 2400 decides to parse the header of the received data segment, it sends a control_DXP signal to input buffer 2300. This control_DXP signal requests a certain amount of data from buffer 2310, or requests that buffer 2310 increment its data head pointer without sending the data to DXP 2400. As soon as the control_DXP signal is received, the control block 2330 forwards the data_DXP signal including data from the buffer 2310 (if requested) to the DXP 2400 via the FIFO block 2340. In one embodiment of the present invention, control block 2330 and FIFO block 2340 add a control character to the data segment as the control character is transmitted to the DXP 2400 with a data_DXP signal. This control character is preferably added to the beginning of each byte of data to be transferred and preferably has a 1-bit status flag indicating whether the next byte of data is a terminal symbol or a non-terminal symbol. . This control character may include special non-terminal symbols such as the beginning of the packet, the end of the packet, and the port_ID.

  When the SPU 2140 receives from the DXP 2400 an SPU entry point (SEP) requesting the SPU 2140 to access data in the input buffer data, the SPU 2140 is in the input buffer 2300 and in place in the buffer 2310 Send control_SPU signal to request data. As soon as the control_SPU signal is received, the control block 2330 sends a sideband signal to the SPU 2140 and sends a data_SPU signal containing data from the buffer 2310 to the SPU 2140 via the RA block 2350. This Sideband signal preferably indicates how many bytes of transmitted data are valid and whether there is an error in the data stream. In one embodiment of the invention, control block 2330 and RA block 2350 add control characters to the data stream so that the data stream is transmitted to SPU 2140. The control character preferably adds the computed CRC value and error flag to the end of the packet or frame in the data stream, if necessary.

  FIG. 17 shows a block diagram of one possible implementation of DXP 2400. A parser controlled finite state machine (FSM) 2410 controls and orders the overall DXP 2400 operations based on inputs from the other logic blocks shown in FIG. Parser stack 2430 stores symbols executed by DXP 2400. The input stream sequence control unit 2420 reads the input data value to be processed by the DXP 2400 from the input buffer 2300. The SPU interface 2440 sends tasks to the SPU 2140 on behalf of the DXP 2400. The specific functions of these blocks are described in further detail below.

  The basic operations of the block diagrams shown in FIGS. 14 to 17 will be described below based on the flowchart relating to the data stream analysis shown in FIG. This flowchart 2500 is used to show the implementation method of the present invention.

  At block 2510, semantic processor 2100 waits for a packet to be received in input buffer 2300 via input port 2110.

  A next decision block 2512 determines whether a packet is received at block 2510. If the packet has not been received, the process returns to block 2510 and waits for the semantic processor 2100 to receive the packet. If a packet has been received at the input buffer, then in the next block 2520, the input buffer 2300 sends a port ID signal to the DXP 2400. This signal is transferred onto the parser stack 2430 as an NT symbol. This port ID signal informs DXP 2400 that the packet has arrived at input buffer 2300. In the preferred embodiment of the present invention, the port ID signal is received by the input stream sequence controller 2420 and forwarded to the FSM 2410. This signal is transferred onto the parser stack 2430. Preferably, the 1-bit status flag is sent before the port ID or in parallel with the port ID, and the port ID is represented by an NT symbol.

  In the next block 2530, the DXP 2400 determines that the symbol at the top of the parser stack 2430 is not the bottom symbol on the stack, and that this DXP is not waiting for further input, and then n from the input buffer 2300 Request byte input stream data and receive it. The DXP 2400 requests data via a data / control signal between the input stream sequence controller 2420 and the input buffer 2300 and receives it.

  A next decision block 2532 determines whether the symbol on the parser stack 2430 is a terminal (T) symbol or an NT symbol. This determination is preferably performed by the FSM 2410 reading a symbol status flag on the parser stack 2430.

  If it is determined that this symbol is a terminal symbol, in the next block 2540, the DXP 2400 checks whether there is a match between the next byte of the received N bytes of data and the T symbol. The FSM 2410 confirms whether there is a match by comparing the next byte of the data received by the input stream sequence control unit 2420 with the T symbol on the parser stack 2430. After verification is complete, the FSM 2410 preferably pops the T symbol from the parser stack by decrementing the stack pointer.

  This next decision block 2542 determines whether there is a match between the next byte of data and the T symbol. If there is a match, the executing program returns to block 2530 and DXP 2400 determines that the symbol at the top of parser stack 2430 is not the bottom symbol on the stack and that this DXP is not waiting for further input. Then, request additional input stream data from the input buffer 2300 and receive it. In the preferred embodiment of the present invention, if there is a T symbol match, the DXP 2400 requests only one byte of input stream data, receives it, and replenishes the DI buffer as one input symbol is consumed. .

  If there is no match, it is assumed that the remaining segment of the current data segment is somewhere in the peripheral and cannot be analyzed. In the next block 2550, the DXP 2400 resets the parser stack 2430 and activates the SEP to remove the remainder of the current packet from the input buffer 2300. In one embodiment of the invention, FSM 2410 either removes the remaining symbols (pop off) or sets the top stack pointer to point to the bottom symbol on the stack (which is more Reset the parser stack 2430 (preferably). The DXP 2400 starts SEP by sending a command to the SPU 2140 via the SPU interface 2440. This command requests SPU 2140 to load microinstructions from SCT 2150. This microinstruction, when executed, allows the SPU 2140 to remove from the input buffer 2300 the remainder of the data segment that cannot be parsed. The executing program then returns to block 2510.

  Note that not all examples of unparseable input in a data stream can result in a break in parsing the current data segment. For example, the parser may be configured to control normal header options by using a direct grammar. Another way to deal with header options that are less common or cumbersome is to use default grammar rules that send header options to the SPU for parsing.

  If it is determined that the symbol in decision block 2532 is an NT symbol, in the next block 2560, the DXP 2400 receives the NT symbol received from the parser stack 2430 and the received N byte DI [N in the input stream sequence controller 2420. ] To the parser table 2200. Therefore, the parser table 2200 confirms whether there is a match, for example, as described above. In the illustrated embodiment, parser table 2200 concatenates the received N bytes and NT symbols. Alternatively, the received N bytes and NT symbols may be concatenated before being sent to the parser table 2200. Preferably, the received N bytes are sent simultaneously to both SPU interface 2440 and parser table 2200, and NT symbols are sent simultaneously to both parser table 2200 and PRT 2250. After the match check is complete, the FSM2 410 removes the NT symbol from the parser stack 2430 (pop). This is preferably done by decrementing the stack pointer.

  The next decision block 2562 determines whether there is a match for the NT symbol concatenated with N bytes of data in the parser table 2200. If there is a match, in the next block 2570, the parser table 2200 sends the PR code corresponding to the match back to the PRT 2250, which addresses the generation rule in the PRT 2250. Otherwise, the PR code is sent from parser table 2200 to PRT 2250 via DXP 2400. The execution program then continues from block 2590.

  If there is no match, in the next block 2580, the DXP 2400 uses the received NT symbol to search for a default production rule in the PRT 2250. In the preferred embodiment, the default production rule is searched in the MAPT 2280 memory located in the PRT 2250. Alternatively, the MAPT 2280 memory may be located in a memory block other than the PRT 2250.

  In the preferred embodiment of the present invention, when the PRT 2250 receives the PR code, the PRT 2250 sends back only the PR corresponding to either the found production rule or the default production rule to the DXP 2400. Another way is to send both the PR and default PR back to the DXP 2400 and the DXP 2400 will decide which one to use.

  In the next block 2590, the DXP 2400 processes the rules received from the PRT 2250. The rules received by DXP 2400 may be either production rules or default production rules. In an embodiment of the present invention, FSM 2410 divides the rule into the following three segments. The three segments referred to here are a symbol segment, a SEP segment, and a skip byte segment. Each segment of the rule preferably has a fixed length or is null terminated so that it can be easily and accurately divided.

  In the illustrated embodiment, FSM 2410 sends a T symbol, an NT symbol, or both to parser stack 2430. These symbols are included in the symbol segment of the production rule. The FSM 2410 sends the SEP included in the SEP segment of the production rule to the SPU interface 2440. Each SEP has an address for a microinstruction located in the SCT 2150. As soon as these SEPs are received, the SPU interface 2440 takes the microinstructions specified by the SEP and assigns the SPU 2140 to execute them. In many cases, SPU interface 2440 also sends the current DI [N] value to SPU 2140 because tasks completed by the SPU do not require any additional input data. Alternatively, the SPU interface 2440 takes microinstructions executed by the SPU 2140 and sends the microinstructions to the SPU 2140 at the same time as the SPUs are allocated. The FSM 2410 sends the skip byte segment of the generation rule to the input buffer 2300 via the input stream sequence control unit 2420. The input buffer 2300 uses the skip byte data to increment its own buffer pointer that points to the placement in the input stream. Each analysis cycle can therefore consume any number of input symbols ranging from 0 to 8.

  After the DXP 2400 processes the rules received from the PRT, the next decision block 2592 determines whether the next symbol on the parser stack 2430 is the bottom symbol on the stack. If the next symbol is the bottom symbol on the stack, the executing program returns to block 2510 where the semantic processor 2100 waits for a new packet to be received at the input buffer 2300 via the input port 2110.

  If the next symbol is not the bottom symbol on the stack, the next decision block 2594 determines whether it is waiting for further input before the DXP 2400 begins processing the next symbol on the parser stack 2430. To do. The illustrated DXP 2400 can wait for the SPU 2140 to start processing a segment of the input stream, wait for the SPU 2140 to send back processing result data, and so forth.

  If the DXP 2400 is not waiting for further input, the executing program returns to block 2530 where the DXP 2400 requests input stream data from the input buffer 2300 and receives it. If the DXP 2400 is waiting for further input, the executing program continues to loop to block 2594 until that input is received.

  FIG. 19 illustrates another semantic processor embodiment. Semantic processor 2600 includes a cluster 2640 of semantic processing units (SPUs) including a number of semantic processing units (SPUs) 2140-1 to 2140-N. The SPUs 2140-1 to 2140-N preferably have the same configuration and function. SPU cluster 2640, memory subsystem 2130, SPU entry point SEE entry point dispatcher (dispatcher) 2650, SCT 2150, port input buffer (PIB) 2700, port output buffer (POB) 2620, machine central processing It is connected to the device (MCPU) 2660.

  If the DXP 2800 determines that the SPU task should be started at a particular point in the analysis, the DXP 2800 loads the SEP dispatcher 2650 with microinstructions from the Semantic Code Table (SCT) 2150 and within the SPU cluster 2640 Allocate SPUs from multiple SPUs 2140-1 to 2140-N and signal them to perform the task. The loaded microinstruction indicates that the task should be executed and is sent to the assigned SPU. The assigned SPU then executes the microinstruction and the data in the input stream is processed accordingly. Alternatively, the SPU may load microinstructions directly from the SCT 2150 when directed by the SEP dispatcher 2650.

  Referring to FIG. 20 for a more detailed understanding, the PIB 2700 includes at least one network interface input buffer 2300 (in this figure, 2300_0 and 2300_1 are illustrated), a recirculation buffer 2710, and a mutual peripheral (PCI -X) input buffer 2300_2. The POB 2620 (not shown) includes at least one network interface output buffer and a PCI-X output buffer. The port block 2610 includes one or more ports, each having a physical interface. Examples of this physical interface include optical, electrical, or wireless drivers for Fiber Channel, 802.11x, Universal Serial Bus (USB), FireWire, SONET, and other physical layer interfaces. For example, a receiver pair. The number of ports in port block 2610 preferably corresponds to the number of network interface input buffers in PIB 2700 and the number of output buffers in POB 2620.

  Referring back slightly to FIG. 19, the PCI-X interface 2630 is connected to the PCI-X input buffer in the PIB 2700, the PCI-X output buffer in the POB 2620, and the external PCI bus 2670. The PCI bus 2670 can be connected to other PCI-capable peripherals such as disk drives and interfaces for additional network ports.

  The MCPU 2660 is connected to the SPU cluster 2640 and the memory subsystem 2130. The MCPU 2660 implements the functions desired for the semantic processor 2600 that can be accomplished with conventional software without difficulty. These functions are usually functions that are not often used and are not important in time, and because of the complexity of the code, they are not guaranteed to be included in the SCT 2150. The MCPU 2660 is also preferably capable of communicating with the SEP dispatcher 2650 to request that the SPU perform tasks on behalf of the MCPU.

  FIG. 20 illustrates one possible implementation of a port input buffer (PIB) 2700 that can be utilized in embodiments of the present invention. The PIB 2700 includes two network interface input buffers 2300_0 and 2300_1, a recirculation buffer 2710, and a PCI-X input buffer 2300_2. The input buffers 2300_0 and 2300_1 and the PCI-X input buffer 2300_2 are functionally equivalent to the input buffer 2300. However, they receive input data from different inputs to the port block 2610 and the PCI-X interface 2630, respectively.

  The recirculation buffer 2710 includes a buffer 2712 that receives recirculation data from the SPU cluster 2640, a control block 2714 for controlling the recirculation data in the buffer 2712, and a DXP 2800 in the buffer 2712 (shown in FIG. 21). FIFO block 2716, which allows FIFO access to the recirculated data, and random access, which allows the SPUs in SPU cluster 2640 to randomly access (RA) the recirculated data in buffer 2712 And a block 2718. When recirculated data from the SPU cluster is received in buffer 2712, recirculating buffer 2710 sends a port ID to DXP 2800 to notify DXP 2800 that new data has arrived. The port ID sent is preferably the first symbol in buffer 2712.

  When the DXP 2800 decides to analyze the recirculated data, the DXP sends a control_DXP signal to the recirculating buffer 2710. This control_DXP signal requests a certain amount of data from the buffer 2712 or requests to increment the data pointer of the buffer 2712. As soon as the control_DXP signal is received, the control block 2714 sends a data_DXP signal including data from the buffer 2712 to the DXP 2800 via the FIFO block 2716. In one embodiment of the present invention, this control block 2714 and FIFO block 2716 add control characters to the recirculated data sent to the DXP 2800 using the data_DXP signal. This control character is preferably a 1-bit status flag that is added to the first portion of each byte of data to be transferred and indicates whether that byte of data is a terminal symbol or a non-terminal symbol.

  When the SPU 2140 in the SPU cluster 2640 receives an SPU entry point (SEP) from the DXP 2800 that requires the SPU to access the data in the recirculation stream, the SPU 2140 buffers the data located at a storage location. The control_DXP signal requested from 2712 is sent to the recirculation buffer 2710. Upon receipt of the control_DXP signal, control block 2714 sends a data_DXP signal containing data from buffer 2712 to SPU 2140 via RA block 2718.

  FIG. 21 shows a block diagram of one possible implementation of DXP 2800. The Parser Controlled Finite State Machine (FSM) 2410 is based on input from the other logic blocks shown in FIG. 21 in a manner similar to that described for the DXP 2400 shown in FIG. Control the operation of the DXP 2800 and order it. However, there are differences due to the presence of multiple inputs under analysis in the input buffer 2700. These differences are mainly in the parser control FSM 2410, the stack handler 2830, and the input stream sequence control unit 2420. In addition, the parser stack 2430 shown in FIG. 17 is replaced with a parser stack block 2860 that can hold a plurality of parser stacks 2430_1 to 2430_M. Finally, a parser data register bank 2810 is added.

  The stack handler 2830 controls a plurality of parser stacks 2430_1 to 2430_M by storing and ordering symbols executed by the DXP 2800. In one embodiment of the invention, parser stacks 2430_1-2430_M are located in a single memory, and each parser stack is located at a fixed location in that memory. Alternatively, the number and size of parser stacks 2430_1-2430_M in parser stack block 2860 is dynamically determined by stack handler 2830, reading the number of active input data ports and the number of grammars, It may be changed.

  The DXP 2800 receives input through multiple interface blocks. The plurality of interface blocks include a parser table 2840, a production rule table (PRT) interface 2850, an input stream sequence control unit 2420, and an SPU interface 2440. In general, these interfaces function as described above, with the exception of the input stream sequence controller 2420.

  The input stream sequence control unit 2420 and the data register bank 2810 retrieve input stream data from the PIB 2700 and hold it. The data register bank 2810 includes a plurality of registers that can store received input stream data. The number of registers is equal to the maximum number of parser stacks 2430_1 to 2430_M that can exist in the parser stack table 2860, and each register is preferably capable of holding N input symbols.

  The parser control FSM 2410 controls the input stream sequence control unit 2420, the data register bank 2810, and the stack handler 2830, and switches the analysis context between different input buffers. For example, the parser control FSM 2410 can now determine which of the input buffer 2300_0, input buffer 2300_1, PCI-X input buffer 2300_2, and recirculation buffer 2710 is operating with the data coming from. Holds the indicated context state. This context state is transmitted to the input stream sequence control unit 2420. Then, the input stream sequence control unit is caused to respond to the data input, or the command in the grammar accompanied by the command for the appropriate input buffer or recirculation buffer is skipped. The context state is transmitted to the data register bank 2810. Then, the register is loaded and read, and the register corresponding to the current context state is accessed. Finally, this context state is sent to the stack handler 2830 so that push and pop commands to the stack handler 2830 access the correct parser stack of the parser stacks 2430_1 to 2430_M.

  The parser control FSM determines when to change the analysis context. For example, if the bottom symbol on the stack reaches a particular parser stack, or if a particular parsing context gets stuck in analyzing the results of an SPU operation, the parser control FSM will state the next parsing context (state of the Examine the next parsing context and continue the brute force method until a ready analysis context arrives.

  The basic operations in the block diagrams 15A, 15B, and 19-21 will be described below based on the data analysis flowchart shown in FIG. Flowchart 2900 is used to describe an implementation method according to an embodiment of the present invention.

  At decision block 2905, the DXP 2800 determines whether new data other than the data corresponding to the parser stack that was stalled in analysis has been received at the PIB 2700. In an embodiment of the invention, the four buffers in PIB 2700 have unique port IDs. These port IDs are each sent to the DXP 2800 when new data is received. Preferably, recirculation buffer 2710 has its own unique port ID as the first byte in each recirculation data segment. Since the four buffers in the PIB 2700 each have a unique input, the DXP 2800 can receive multiple port IDs simultaneously. When the DXP 2800 receives a plurality of port IDs, it is preferable to use a round-robin arbitration to determine a sequence for analyzing new data present at the port.

  In one embodiment of the invention, the parser stack is saved by the DXP 2800 when parsing has to be stopped on a particular stream. When the FSM 2410 sends a control signal to the stack handler 2830 that instructs the stack handler to switch parser stack selection, the parser stack is saved.

  If new data has not yet been received, the process returns to block 2905 where the DXP 2800 waits for new data to be received at the PIB 2700.

  If new data has been received, at the next block 2910, the DXP 2800 forwards the port ID of the selected buffer onto the selected parser stack as an NT symbol. This selected buffer is the buffer in the PIB that DXP has decided to analyze. And the selected parser stack in DXP 2800 is the parser stack that has chosen to store the symbols on which DXP 2800 is executed. The grammar loaded for each port, or a portion thereof, may be different depending on the initial non-terminal symbol loaded for that port. For example, if one input port receives a SONET frame and another input port receives an Ethernet frame, the port IDNT symbol for each port can be used to mechanically select the appropriate grammar for each port. Can do.

  In one embodiment of the present invention, the input stream sequence controller 2420 selects a buffer in the PIB 2700 via brute force arbitration, and the stack handler 2830 selects a parser stack in the parser stack block 2860. To do. In the preferred embodiment of the present invention, the FSM 2410 sends a signal to the input stream sequence controller instructing the selection of a buffer within the PIB 2700, and instructs the data register bank 2810 to select a register. Send a control register signal (Control Reg signal). Similarly, the FSM 2410 sends a control signal instructing the stack handler 2830 to allow selection of a buffer or a control signal instructing the parser stack to be dynamically allocated in the parser stack block 2860.

  For illustration purposes, the input buffer 2300_0 has its own port ID selected by the DXP 2800, and this parser stack 2430_1 is used to store grammar symbols used in parsing data from the input buffer 2300_0. Is selected. In the illustrated embodiment of the present invention, after the stack handler 2830 receives the port ID from the FSM 2410 as a SYM code and receives the transfer command as a control signal, the port ID is received by the stack handler 2830 on the parser stack 2430_1. Sent to. The 1-bit status flag preceding the port ID displays the port ID as an NT symbol.

  In a next block 2920, the DXP 2800 requests and receives N bytes of data (or a portion thereof) from the stream in the selected buffer. In the illustrated embodiment, the DXP 2800 requests and receives data via data / control signals between the input buffer 2300_0 in the PIB 2700 and the input stream sequence controller 2420. When data is received by the input stream controller 2420, the data is stored in a selected register in the data register controller 2810. The selected register in the data register control unit 2810 is controlled by the current analysis context.

  In the next block 2930, DXP 2800 determines that it is not waiting for further input and that the symbol on the selected parser stack is not the bottom symbol on the stack, and then the top of the selected parser stack. Process the symbol above and the received N bytes of data (or part of it). Block 2930 includes determining whether the top symbol is a terminal symbol or a non-terminal symbol. This determination may be performed by the stack handler 2830. This determination is preferably performed by reading the status flag of the top symbol of parser stack 2430_1 and transmitting the status to FSM 2410 as a prefix (P) code signal.

  If it is determined at decision block 2935 that the symbol is a terminal (T) symbol, the DXP 2800 checks to see if there is a match between the next byte of data from the received N bytes and the T symbol.

  In the preferred embodiment of the present invention, the match signal M used by the DXP 2400 to see if there has been a T symbol match is the comparator 2820 that receives the T symbol from the stack handler 2830 as well as the data register. When the next byte of data from the selected register in controller 2810 has been input, it is sent by comparator 2820 to FSM 2410. The stack handler 2830 pops off the symbol from the parser stack 2430_1 to send the T symbol on the parser stack 2430_1 to the input of the comparator 2820.

  If block 2945 determines that the symbol at the top of the current parser stack is a non-terminal (NT) symbol, the DXP 2800 will register the NT symbol from parser stack 2430_1 and the register selected from bank 2810. The received N bytes are sent to the parser table 2200. In the illustrated embodiment, NT symbols and received N bytes are sent to parser table interface 2840. These are concatenated before being sent to the parser table 2200. Alternatively, the NT symbols and received N bytes can be sent directly to the parser table 2200. In some embodiments, the received N bytes in the selected register are sent to the SPU 2140 and the parser table 2200 simultaneously.

  The symbols on parser stack 2430_1 are preferably sent simultaneously to comparator 2820, parser table interface 2450, and PRT interface 2460.

  Assuming that a valid block 2935 T-symbol match was attempted, if the match was successful, the executing program would return to block 2920 where the DXP 2800 received no more than N bytes of data from the PIB 2700. Request and receive it. In one embodiment of the present invention, if there is a T symbol match, the DXP 2800 will only request and receive 1 byte of stream data.

  If a match in block 2935 is attempted and successful, in the next block 2940, the DXP 2800 may clear the selected parser stack if the grammar indicates, and then invoke SEP to invoke the current data segment. Delete the rest of the from the current input buffer.

  The DXP 2800 resets the parser stack 2430_1 by sending a control signal to the stack handler 2830 to take out the remaining symbols and set the stack pointer to the bottom symbol in the stack. The DXP 2800 starts the SEP by sending a command to the SPU dispatcher 2650 via the SPU interface. In accordance with this instruction, the SPU dispatcher 2650 allocates an SPU 2140 that fetches microinstructions from the SCT 2150. When executed, this microinstruction deletes the remainder of the current data segment from the input buffer 2300_0. Thereafter, the execution program returns to block 2905 where the DXP 2800 determines whether new data related to the data input has been received at the PIB 2700 except for the data input having a parsing parser context.

  Assuming that the top symbol on the stack is a non-terminal symbol, a match is attempted at block 2945 instead of block 2935. If there is a match in the parser stack table 2200 for an NT symbol concatenated with N bytes of data, the execution program proceeds to block 2905. Parser table 2200 sends a PR code corresponding to the match back to DXP 2800. The DXP 2800 uses the PR code to search for a generation rule in the PRT 2250. In one embodiment, the production rules are retrieved in PRT memory 2270 located in PRT 2250.

  In the illustrated embodiment, the PR code is sent from parser table 2200 to PRT 2250 via intermediate parser table interface 2450 and intermediate PRT interface 2460. Alternatively, the PR code can be sent directly from the parser table 2200 to the PRT 2250.

  If the match fails at decision block 2945, then at the next block 2960, DXP 2800 uses the NT symbol from the selected parser stack to search for a default generation rule in PRT 2250. In one embodiment, default production rules are searched in MAPT 2280 memory located in PRT 2250. Alternatively, the MAPT 2280 memory can be placed in a memory block other than the PRT 2250.

  In the illustrated embodiment, the stack handler 2830 sends NT symbols to the production rules interface 2850 and the parser table interface 2840 simultaneously. Alternatively, stack handler 2830 can send NT symbols directly to parser table 2200 and PRT 2250. When the PRT 2250 receives the PR code and the NT symbol, the PRT 2250 sends both the production rule and the default production rule to the PRT interface 2850 at the same time. The production rules interface 2480 sends only the appropriate rules back to the FSM 2410. In other embodiments, both production rules and default production rules are sent to the FSM 2410. In other embodiments, depending on whether a PR code has been sent to the PRT 2250, the PRT 2250 returns only one of the PR and the default PR to the PRT interface 2850.

  If either block 2950 or block 2960 is executed, processing proceeds to the next block 2970. At block 2970, DXP 2800 processes the production rules received from PRT 2250. In one embodiment of the present invention, FSM 2410 splits the production rule into three segments. These three segments are a symbol segment, a SEP segment, and a skip byte segment. Each segment of the production rule is preferably fixed in length and null-terminated to allow simple and accurate division as described above.

  The block 2970 shown in FIG. 22 operates in a similar manner to the block 2950 shown in FIG. 18, with the following differences. First, the production symbol segment is transferred onto the appropriate parser stack for the current context. Second, the skip byte section of the production rule is used to control the appropriate registers for the current context in the data register bank and the appropriate input buffer for the current context. Third, when the SEP is sent to the SEP dispatcher, the instruction points to the appropriate input buffer for execution of the semantic code by the SPU.

  In a next decision block 2975, the DXP 2800 determines whether the input data in the selected buffer requires further analysis. In one embodiment of the present invention, if the (for) parser stack pointer in stack 2430_1 points to a symbol other than the bottom symbol in the stack, the input data in input buffer 2300_0 requires further analysis. The FSM 2410 preferably receives an empty stack signal (stack empty sugnal: SE) from the stack handler 2830 if the (for) parser stack pointer of the stack 2430_1 points to the bottom symbol of the stack.

  If the input data in the selected buffer does not need to be further analyzed, the execution program returns to block 2905 where the DXP 2800 has another input buffer other than the dead parser stack buffer. Determine if you have new data waiting to come in PIB 2700.

  If the input data in the selected buffer needs to be further analyzed, in the next decision block 2985, can the DXP 2800 continue to analyze the input data in the selected buffer? Judge whether. In some embodiments of the present invention, analysis may be stopped with input data from a given buffer for several reasons, even though analysis is still required. This may be due to unresolved or ongoing SPU operations, lack of input data, or other input buffers having priority in analysis within the DXP 2800. In one embodiment, another input buffer that has priority over the input data in input buffer 2300_0 has a higher priority as a grammar instruction or an input buffer that previously had a parser stack stored. It may be an input buffer. The DXP 2800 is informed by the SEP dispatcher 2650 about the SPU processing delay via the status signal. Further, the DXP 2800 is notified of the task to be preferentially analyzed based on the status value stored in the FSM 2410.

  If DXP can continue parsing in the current parsing context, the execution program returns to block 2920, where DXP 2800 requests less than N bytes of data from the input data in the selected buffer, Receive it.

  If the DXP 2800 is unable to continue parsing, in the next block 2990, the DXP 2800 stores the selected parser stack, followed by the selected parser stack and the selected register in the data register bank 2810. Deselect the selected input buffer. Upon receiving the switching control signal from the FSM 2410, the stack handler 2830 stores the parser stack 2430_1, and then selects another parser stack in the parser stack block 2860, thereby deselecting the parser stack 2430_1.

  When receiving the switching signal from the FSM 2410, the input stream sequence control unit 2420 deselects the input buffer 2300_0 by selecting another buffer in the PIB 2700 that has already received the input data. When the data register bank 2810 receives the switching signal from the FSM 2410, the data register bank 2810 deselects the selected register by selecting another register. The input buffer 2300_0, the selected register, and the parser stack 2430_1 may remain operational if there are no other buffers waiting for the PIB 2700 to receive new data to be analyzed by the DXP 2800 it can.

  The executing program then returns to block 2905, where the DXP 2800 determines whether an input stream other than an input stream having a parser stack that has been parsed has been received at the PIB 2700.

  FIG. 23 shows a block diagram of a semantic processor 3100 according to an embodiment of the present invention. The semantic processor 3100 has an input buffer 3140 for buffering a packet data stream received via the input port 3120, and a direct execution parser (which controls the processing of packet data received at the input buffer 3140 and the recirculation buffer 3160). DXP) 3180 and a packet processor 3200 for processing the packet. The input buffer 3140 and recirculation buffer 3160 are preferably first-in-first-out (FIFO) buffers. The packet processor 3200 comprises an execution engine 3220 for processing packet segments or performing other operations, and a memory subsystem 3240 for storing and incrementing packet segments.

  The DXP 3180 controls the processing of packets or frames (eg, input “streams”) in the input buffer 3140 and the processing of packets or frames (eg, recirculation “streams”) in the recirculation buffer 3160. Since the DXP 3180 analyzes the input stream from the input buffer 3140 and the recirculation stream from the recirculation buffer 3160 in a similar manner, only the analysis of the input stream will be described below.

  The DXP 3180 maintains an internal parser stack containing terminal and non-terminal symbols based on the analysis of the current frame up to the current symbol. If the symbol at the top of the parser stack is a terminal symbol, the DXP 3180 compares the data at the beginning of the input stream with the terminal symbol and expects a match to continue working. If the symbol at the top of the parser stack is a non-terminal symbol, the DXP 3180 uses this non-terminal symbol and the current input data to expand the grammar product on the stack. As parsing continues, the DXP 3180 sends instructions to the execution engine 3220 to process the segment of input or perform other operations.

  Semantic processor 3180 uses at least two tables. Complex grammar generation rules are stored in a generation rule table (PRT) 3190. Codes for searching (reading out) these generation rules are stored in a parser table (PT) 3170. The code in parser table 3170 allows DXP 3180 to determine what processing packet processor 3200 should perform on the segment of the packet for a given production rule.

  Some embodiments of the present invention include more components than those shown in FIG. Therefore, before describing such a more complex embodiment, the packet flow within the semantic processor shown in FIG. 23 will be described.

  FIG. 24 is a flowchart 3300 regarding processing of a packet received via the semantic processor 3100 shown in FIG. This flowchart 3300 is used to describe the method of the present invention.

  In block 3310, the packet is received at input buffer 3140 via input port 3120. In the next block 3320, the DXP 3180 begins parsing the header of the packet in the input buffer 3140. If the packet does not require additional operations or additional packets to allow processing of the packet payload, the DXP 3180 fully parses the header. If the packet requires additional operations or additional packets to allow processing of the packet payload, the DXP 3180 will stop parsing the header.

  Decision block 3330 asks whether DXP 3180 was able to fully parse the header. If the DXP 3180 was able to fully parse the header, in the next block 3370, the DXP 3180 calls a routine in the packet processor 3200 to process the packet payload. The semantic processor 3100 then waits for the next packet to be received at the input buffer 3140 via the input port 3120.

  If the DXP 3180 has to stop parsing the header, in the next block 3340, the DXP 3180 waits for an additional packet or calls a routine in the packet processor 3200 to control the packet. As soon as control is complete or additional packets arrive, the packet processor 3200 creates a conditioned (resolved) packet.

  In a next block 3350, the packet processor 3200 writes the adjusted (resolved) packet (or a portion thereof) to the recirculation buffer 3160. This can be achieved by allowing the recirculating buffer to have direct memory access to the memory subsystem 3240. Alternatively, this can be accomplished by having the direct execution engine 3220 read the adjusted packet from the memory subsystem 3240 and then write the adjusted packet to the recirculation buffer 3160. Alternatively, a special header may be written to the recirculation buffer 3160 instead of a fully adjusted packet to store processing time within the packet processor 3200. This special header instructs the packet processor 3200 to process the adjusted packet without requiring the complete packet to be transferred from the packet processor memory subsystem 3240.

  In the next block 3360, the DXP 3180 begins parsing the header of the data in the recirculation buffer 3160. The executing program then returns to block 3330 where it is asked if DXP 3180 was able to fully parse the header. If DXP 3180 was able to parse the header completely, then in the next block 3370, DXP 3180 calls a routine in packet processor 3200 to process the packet payload. The semantic processor 3100 then waits for a new packet to be received at the input buffer 3140 via the input port 3120.

  If the DXP 3180 has to stop parsing the header, the executing program returns to block 3340, where the DXP 3180 calls a routine in the packet processor 3200 to control the packet or wait for an additional packet, then Create an adjusted packet. Packet processor 3200 then writes the adjusted packet to recirculation buffer 3160. Then, the DXP 3180 starts analyzing the header of the packet in the recirculation buffer 3160.

FIG. 25 illustrates another embodiment of the semantic processor 3400. The semantic processor 3400 includes the following elements.
Array machine context data memory (AMCD) 3430 for accessing data in dynamic random access memory (DRAM) 3480 via hash function (hashing function) or content addressable memory (CAM) search
Cryptographic processing block 3440 for data encryption, decryption, and authentication
Context control block cache 3450 for caching context control blocks to DRAM 3480 and for caching context control blocks from DRAM 3480
Normal cache 3460 for caching data used in basic operations
Streaming cache 3470 for caching data streams while the data stream is being written to DRAM and while the data stream is being written from DRAM
This context control block cache 3450 is preferably a software controlled cache. That is, the process preferably determines when a cache line is used and when it is not used. Each of the five blocks is connected to a DRAM 3480 and a semantic code execution engine (SEE) (the semantic code execution engine (SEE) is also referred to as a semantic processing unit (SPU) 3410). When SEE 3410 is signaled by DXP 3180, it processes the segment of the packet or performs other operations. If DXP 3180 decides to start the SEE task at a particular point in the analysis, DXP 3180 signals SEE 3410 to load microinstructions from the Semantic Code Table (SCT) 3420. This loaded microinstruction is then executed in SEE 3410 and the segment of the packet is processed accordingly.

  FIG. 26 is a flowchart 3500 for processing a fragmented Internet Protocol (IP) packet received via the semantic processor 3400 shown in FIG. This flowchart 3500 is used to describe an implementation method according to an embodiment of the present invention.

  When a packet is received at the input buffer 3140 via the input port 3120 and the DXP 3180 begins parsing the header of the packet in the input buffer 3140 accordingly, at block 3510, the DXP 3180 receives the IP fragmented from the received packet. Since it is determined to be a packet, the analysis of the header of the received packet is stopped. The DXP 3180 preferably parses the IP header completely and does not parse any headers belonging to subsequent layers (TCP, UDP, iSCSI, etc.).

  In the next block 3520, the DXP 3180 signals the SEE 3410 to load the appropriate microinstruction from the SCT 3420 and to read the received packet from the input buffer 3140. In a next block 3530, the SEE 3410 writes the received packet to the DRAM 3480 via the streaming cache 3470. Although blocks 3520 and 3530 are shown as two separate steps, alternatively, they may be performed as a single step with the SEE 3410 reading and writing packets simultaneously. This SEE 3410 simultaneous read and write operation is known as the SEE pipeline method. In this operation, the SPU 3410 operates as a conduit or pipeline for streaming data that is transferred between two blocks within the semantic processor 3400.

  In a next decision block 3540, the SPU 3410 determines whether a context control block (CCB) has been allocated for correct IP packet fragment collection and ordering. The CCB that collects and orders the fragments corresponding to the fragmented IP packets is preferably stored in DRAM 3480. CCB waits for pointers to IP fragments in DRAM 3480, bit mask for fragmented IP packets that have not yet arrived, and additional fragmented IP packets to semantic processor 3400 after the allotted period has passed And a timer value for releasing the data stored in the CCB in the DRAM 3480.

  The SPU 3410 uses the source IP address of the received fragmented IP packet, which is a combination of the ID (identification) and protocol from the header of the received IP packet fragment, as a key, and the content addressable AMCD 3430 It is preferable to determine whether a CCB is allocated by accessing a memory (CAM) search function. Alternatively, the IP fragment key is stored in a separate CCB table in DRAM 3480. And in this way, this key accesses the CAM by using the source IP address of the received fragmented IP packet, which combines the ID (identification) and protocol from the header of the received IP packet fragment. Be made. This IP fragment key addressing approach avoids key duplication and key size issues.

  If the SPU 3410 determines that a CCB has not yet been assigned due to fragment accumulation and ordering for a particular fragmented packet, the executing program proceeds to block 3550 where the SPU 3410 assigns a CCB. The SPU 3410 inputs the key corresponding to the assigned CCB into the IP fragment CCB table in the AMCD 3430 and starts a timer placed in the CCB. The key here is composed of ID (identification) and protocol from the header of the received fragmented IP packet, and the source IP address of the received IP fragment. When the first fragment for a given fragmented packet is received, the IP header is also stored in the CCB for later recirculation. For subsequent fragments, the IP header need not be stored.

  As soon as the CCB is allocated for collection and ordering of fragmented IP packets, in the next block 3560, the SPU 3410 sends a pointer to the fragmented IP packet (excluding the IP header) in the CCB. Store in DRAM 3480. The pointers to the fragments can be arranged in the CCB, for example as a linked list. Preferably, the SPU 3410 may update the bit mask with the newly assigned CCB by marking a portion of the mask corresponding to the received fragment as received.

  In a next decision block 3570, the SPU 3410 determines whether all of the IP fragments from the packet have been received. This determination is preferably accomplished using a bit mask in the CCB. One skilled in the art will appreciate that there are a number of techniques readily available to implement a bit mask or equivalent tracking mechanism that can be used with the present invention.

  If all of the IP fragments for a fragment packet have not been received, the semantic processor 3400 suspends further processing for this fragmented packet until other fragments are received.

  If all of the IP fragments have been received, then in the next block 3580, the SPU 3410 resets the timer and reads the IP fragments from the DRAM 3480 in the correct order and then those for further analysis and processing. Is written to the recirculation buffer 3160. The SPU 3410 preferably writes only the special header and the first part of the reconstructed IP packet (with the fragmentation bit not set) to the recirculation buffer 3160. A special header directs DXP 3180 to process reassembled fragmented IP packets stored in DRAM 3480 without having to forward all of the fragmented packets to recirculation buffer 3160 Make it possible. Special headers can consist of non-terminal symbols that are specified to load a parser grammar for IP and load a pointer to CCB. Thus, the parser can usually parse the IP header and then proceed to the analysis of higher layer (eg, TCP) headers.

  In an embodiment of the invention, the DXP 3180 decides to analyze the data received in either the recirculation buffer 3160 or the input buffer 3140 via brute force arbitration. An advanced description of brute force arbitration is described below in connection with first and second buffers for receiving a packet data stream. When the DXP 3180 completes the analysis of the packet in the first buffer, the DXP 3180 looks at the second buffer and determines whether the data can be analyzed. If it can be analyzed, the data from the second buffer is analyzed. If not, the DXP 3180 looks again at the first buffer to determine if the data can be analyzed. The DXP 3180 continues this round-robin arbitration until the data can be analyzed in either the first buffer or the second buffer.

  FIG. 27 is a flowchart 3600 for processing a packet received via the semantic processor 3400 shown in FIG. 25 that requires decryption, authentication, or both. This flowchart 3600 is used to describe other implementation schemes according to embodiments of the present invention.

  When a packet is received at input buffer 3140 or recirculation buffer 3160 and DXP 3180 begins parsing the received packet header accordingly, at block 3610, DXP 3180 either decrypts the received packet, authenticates it, or Since it is determined that both are necessary, the analysis of the header of the received packet is stopped. When the DXP 3180 begins parsing the header of a packet from the recirculation buffer 3160, the recirculation buffer 3160 preferably includes only the special header described above and the first part of the reconstructed IP packet.

  In the next block 3620, the DXP 3180 sends a signal to the SPU 3410 to load the appropriate microinstruction from the SCT 3420 and to read packets received from the input buffer 3140 or recirculation buffer 3160. The SPU 3410 preferably reads packet fragments from the DRAM 3480 instead of the recirculation buffer 3160 for data that has not yet been placed in the recirculation buffer.

  In the next block 3630, the SPU 3410 writes the received packet to the cryptographic processing block 3440. The packet is then authenticated, decrypted, or both. In the preferred embodiment, decryption and authentication are performed in parallel within cryptographic processing block 3440. Cryptographic processing block 3440 is Triple Data Encryption Standard (T-DES), Advanced Encryption Standard (AES), Message Digest 5 (MD-5), Secure Hash Algorithm 1 (SHA-1), Rivest Cipher 4 (RC-4) By using an algorithm or the like, packet authentication, encryption, and decryption are possible. Although block 3620 and block 3630 are illustrated as two separate steps, alternatively, the SPU 3410 can read and write packets simultaneously, which can be performed as a single step.

  The decrypted and authenticated packets are thus written to the SPU 3410, and in the next block 3640, the SPU 3410 writes the packet to the recirculation buffer 3160 for further processing. In the preferred embodiment, cryptographic processing block 3440 includes a direct memory access engine that can read data from DRAM 3480 and write data to DRAM 3480. By writing the decrypted packet or authenticated packet back to DRAM 3480, the SPU 3410 can read only the decrypted packet or authenticated packet header from DRAM 3480, They can be written to the recirculation buffer 3160. Since the payload of the packet remains in DRAM 3480, semantic processor 3400 saves processing time. As with IP fragmentation (like with IP fragmentation), special headers are written to the recirculation buffer, directing the parser and sending CCB information back to the SPU 3410.

  If fragmented IP, encrypted IP, or authentication IP is included in a single packet received by the semantic processor 3400, multiple paths are required to go through the recirculation buffer 3160 May be.

  FIG. 28 shows another embodiment of the semantic processor. The semantic processor 3700 includes a semantic execution engine (SEE) cluster 3710 including a plurality of semantic execution engines (SEE) 3410_1 to 3410_N. Each SEE 3410_1 to SEE 3410_N is preferably of the same quality and has the same function. SPU cluster 3710 includes memory subsystem 3240, SEE entry point (SEP) dispatcher 3720, SCT 3420, port input buffer (PIB) 3730, port output buffer (POB) 3750, and machine central processing It is connected with a device (MCPU) 3771.

  When DXP 3180 decides to start an SEE task at a particular point in the analysis, DXP 3180 loads the SEP dispatcher 3720 with microinstructions from the Semantic Code Table (SCT) 3420 and includes multiple SEEs in the SEE cluster 3710. Allocate SEE from 3410_1 to 3410_N and send a signal instructing to execute the task. This loaded microinstruction and the task to be executed are then sent to the assigned SEE. The assigned SEE then executes the microinstruction and the data packet is processed accordingly. The SEE can alternatively load microinstructions directly from the SCT 3420 when commanded to the SEP dispatcher 3720.

  The PIB 3730 includes at least one network interface input buffer, a recirculation buffer, and a peripheral component intercommunication (PCI-X) input buffer. The POB 3750 includes at least one network interface output buffer and a peripheral component intercommunication (PCI-X) output buffer. The port block 3750 includes one or a plurality of ports. Each of these ports has a physical interface. Examples of this physical interface include optical, electrical or electrical for Ethernet, Fiber Channel, 802.11x, Universal Serial Bus (USB), FireWire, and other physical layer interfaces. One example is a wireless driver / receiver pair. The number of ports in port block 3470 preferably matches (corresponds) to the number of network interface input buffers in PIB 3730 and the number of output buffers in POB 3750.

  The PCI-X interface 3760 is connected to the PCI-X input buffer in the PIB 3730, the PCI-X output buffer in the POB 3750, and the external PCI-X bus 3780. The PCI bus 3780 can be connected to other PCI cable components such as disk drives and interfaces to additional network ports.

The MCPU 3771 is connected to the SEE cluster 3710 and the memory subsystem 3240.
The MCPU 3771 executes functions desirable for the semantic processor 3700 that can be performed without difficulty by activating conventional software on normal hardware. These functions are usually less used and not time critical functions, and because of the complexity of their code, they are not guaranteed to be included in SCT 3420. The MCPU 3771 also has the ability to communicate with a dispatcher in the SEE cluster 3710 to request that the SEE perform tasks on behalf of the MCPU.

  In one embodiment of the present invention, the memory subsystem 3240 further includes a DRAM that connects the cryptographic processing block 3440, the context control block cache 3450, the normal cache 3460, and the streaming cache 3470 with the DRAM 3480 and the external DRAM 3791. Consists of interface 3790. In this embodiment, the AMCD 3430 connects directly to an external TCAM, while connected to an external SRAM 3795 (static random access memory).

  FIG. 29 is a flowchart 3800 relating to processing of peripheral interface (iSCSI) data for Internet small computers received via semantic processor 3700 shown in FIG. This flowchart 3800 is used to describe another implementation method according to an embodiment of the present invention.

  At block 3810, an iSCSI connection having at least one Communication Control Protocol (TCP) session is established between the initiator and the target semantic processor 3700 for the transfer of iSCSI data. Semantic processor 3700 includes the appropriate grammar in PT 3160 and PRT 3190 and has microcode in SCT 3420. With this grammar and microcode, a TCP session is established and then the initial login and initial authentication of the iSCSI connection are processed via the MCPU 3771. In one embodiment, one or more SPUs in SPU cluster 3710 organize and maintain the state of TCP sessions. The state of this TCP session is determined by TCPB DRAM 3480 allocation for TCP reordering, window size limits, and additional TCP and iSCSI packets from the initiator within the allocated timeframe. And a timer for terminating the TCP session if it does not arrive. The TCP CCB holds a field for associating this CCB with the iSCSI CCB once the iSCSI connection is established by the MCPU 3771.

  Once the TCP session is established with the initiating program, in the next block 3820, the semantic processor 3700 receives a TCP / iSCSI packet corresponding to the TCP session established in block 3810 in the input buffer 3140 of the PIB 3730. Wait for Semantic processor 3700 includes a plurality of SPUs 3410-1 through 3410-N that can be used to process input data, so that semantic processor 3700 can receive the next TCP / IP corresponding to the TCP session established in block 3810. While waiting for an iSCSI packet, multiple packets can be received in parallel and processed in parallel.

  The TCP / iSCSI packet is received in the input buffer 3140 of the PIB 3730 via the input port 3120 of the port block 3740. The DXP 3180 then analyzes the TCP header of the packet in the input buffer 3140. In the next block 3830, the DXP 3180 signals to the SEP dispatcher 3720 to load the appropriate microinstruction from the SCT 3420 and to allocate an SPU from the SPU cluster 3710 and send the microinstruction to the assigned SPU. Send. When executed, this microinstruction requests the allocated SPU to read the received packet from the input buffer 3140 and then write the received packet to the DRAM 3480 via the streaming cache 3470. It is. This assigned SPU then uses the search function of AMCD 3430 to find the TCP CCB, stores a pointer to the location of the received packet in DRAM 3480 in the TCP CCB, and timers in the TCP CCB Is restarted. The assigned SPU is then deallocated and can be assigned to other processes as determined by DXP 3180.

  In the next block 3840, the received TCP / iSCSI packets are reordered, if necessary, to ensure that the payload data sequence is correct. As is well known in the art, TCP packets are considered in the proper order if all previous packets have arrived.

  If it is determined that the received packets are in the proper order, the associated SPU signals the SEP dispatcher 3720 to load a microinstruction for iSCSI recirculation from the SCT 3420. In a next block 3850, the assigned SPU combines the iSCSI header, the TCP connection ID from the TCP header, and the iSCSI non-terminal symbol to create a special iSCSI header. The assigned SPU then writes a special iSCSI header to the recirculation buffer 3160 in the PIB 3730. Alternatively, a special iSCSI header can be sent to the recirculation buffer 3160 along with the corresponding iSCSI payload.

  In a next block 3860, the special iSCSI header is parsed and then the semantic processor 3700 processes the iSCSI payload.

  In a next decision block 3870, it is asked if there is another iSCSI header in the received TCP / iSCSI packet. If there is another iSCSI header in the received TCP / iSCSI packet, the execution program returns to block 3850 where the second iSCSI header in this received TCP / iSCSI packet processes the second iSCSI payload. Used to do. As is well known in the art, there may be multiple iSCSI headers and iSCSI payloads within a single TCP / iSCSI packet, and therefore any given iSCSI packet will contain a recirculation buffer 3160 and DXP 3180. There may be multiple packet segments sent via.

  If there is no other iSCSI header in the received TCP / iSCSI packet, block 3870 returns the executing program to block 3820, where the semantic processor 3700 returns another TCP session that is established in block 3810. Wait for a TCP / iSCSI packet to arrive. The assigned SPU is then deallocated and can then be assigned to other processes as determined by DXP 3180.

  Those skilled in the art will recognize that multiple combinations of encryption, authentication, IP fragmentation, and iSCSI data processing are included in a single packet received by the semantic processor 3700. It will be understood that segments of a packet may pass through recirculation buffer 3160 at different times.

Memory Subsystem FIG. 30 shows the memory subsystem 3240 in more detail. The cluster of SPU 3710 and the ARM 3814 are connected to the memory subsystem 3240. In other embodiments, the ARM 3814 is connected to the memory subsystem 3240 via the SPU 3710. The memory subsystem 3240 includes a plurality of different cache areas 3460, 3450, 3470, 3430, 3440, and 3771 that are adapted for different types of memory accesses. The plurality of cache areas 3460, 3450, 3470, 3430, 3440, and 3771 are generally referred to as a cache area 3825. SPU cluster 3710 and ARM 3814 connect to one of the caches in cache area 3825, which in turn connects to external dynamic random access memory (DRAM) through main DRAM arbiter 3828. However, in one embodiment, CCB cache 3450 may be connected to another external CCB DRAM 3791B via CCB DRAM controller 3826.

  Different cache areas 3825 improve DRAM data transfer for different data processing operations. The normal cache 3460 operates as a standard cache for normal purpose memory access by the SPU 3710. For example, the normal cache 3460 may be used for normal purpose random memory accesses that are used to direct normal control and data access operations.

  Cache line replacement in the CCB cache 3450 is controlled exclusively by software commands. This is the opposite of conventional cache operations where the hardware controls the contents of the cache based on which hardware last occupied the cache line location. By controlling the CCB cache area 3450 with software, the cache can be prevented from reloading the cache line too early. This reload may require some intermediate processing by one or more SPUs 3710 before the cache line is loaded or updated from external DRAM 3791B.

  The streaming cache 3470 is mainly used to process streaming packet data. The streaming cache 3470 stops streaming packet transfers from replacing almost all entries in the normal cache 3460. Streaming cache 3470 is a first-in first-out (FIFO) memory buffer because one or more SPUs 3710 may need to read data while the data is still in the streaming cache 3710. Instead it runs as a cache. If the FIFO is used, the streaming data can only be read after being loaded into the external DRAM 3791A. The streaming cache 3470 includes a plurality of buffers each capable of holding a different packet stream. This allows different SPUs 3710 to access different packet streams while they are located in the streaming cache 3470.

  The MCPU 3771 is mainly used for instruction access from the ARM 3814. The MCPU 3771 improves the efficiency of burst mode access between the ARM 3814 and the external DRAM 3791A. The ARM 3814 includes an internal cache 3815 that, in one embodiment, is 32 bits wide. The MCPU 3771 is specifically directed to control 32-bit burst transfers. The MCPU 3771 may buffer multiple 32-bit bursts from the ARM 3814 and then burst (send together) to the external DRAM 3791A when the cache line reaches some threshold amount of data.

  In one embodiment, each cache area 3825 may be physically located in a different associated area in external DRAM 3791A and 3791B. By separating the MCPU 3771 from the cache area, instruction transfer between the ARM 3814 and the external DRAM 3791A is prevented from being adversely affected by data transfer instructed to the other cache area. For example, the SPU 3710 can load data through cache areas 3460, 3450, and 3470 without polluting the instruction space used by the ARM 3814. .

S-code FIG. 31 shows in detail how memory access is initiated by each SPU 3410 for different cache areas 3825. For simplicity, only the normal cache 3460, the CCB cache 3450, and the streaming cache 3470 are shown in FIG.

  The microinstruction 3900 is called an SPU code (S-Code) as another way of calling, and is sent directly from the execution parser 3180 (shown in FIG. 23) to the SPU subsystem 3710. An example of microinstruction 3900 is shown in more detail in FIG. 32A. The microinstruction 3900 may include a target field 3914 that indicates to each SPU 3410 which cache area to use for data processing. For example, the cache area field 3914 shown in FIG. 32A instructs the SPU 3410 to use the CCB cache 3450. Target field 3914 allows SPU 3410 to access MCPU 3771 (shown in FIG. 30), recirculation buffer (shown in FIG. 23), and output buffer 3750 (shown in FIG. 28). It can also be used to command.

  With reference to FIG. 31, each cache area 3825 maintains a set of associated queues within the SPU subsystem 3710. Each SPU 3410 sends a data access request to queue 3902, which then provides in-order access to different cache areas 3825. This queue 3902 also allows different SPUs 3410 to direct and direct memory accesses to different cache areas 3825 at the same time.

  FIG. 32B shows an example of a cache request 3904 transmitted between the SPU 3410 and the cache area 3825. This cache request 3904 includes an address and any associated data. In addition, the cache request 3904 includes an SPU tag 3906 that identifies which SPU 3410 is associated with the request 3904. The SPU tag 3906 tells the cache area 3825 which SPU 3410 to transmit the requested data.

Arbitration
With regard to FIG. 30, the DRAM arbiter 3828 is particularly concerned with arbitration. The DRAM arbiter 3828, in one embodiment, uses round robin arbitration to determine when data from different data cache areas 3825 gains access to the external DRAM 3791A. In the brute force arbitration scheme, the main DRAM arbiter 3828 continues to check whether any cache area 3825 has requested access to the external DRAM 3791A in a predetermined order. When a particular cache area 3825 creates a memory access request, the memory access request is considered an access to external DRAM 3791A during the brute force execution associated with that memory access request. Arbiter 3828 then checks the next cache area 3825 in brute force order for memory access requests. If the next cache area 3825 has no memory access request, the arbiter 3828 checks the next cache area 3825 in brute force order. This process continues with each cache area 3825 being provided in brute force order.

  Access between the CCB cache 3450 and the external DRAM 3791A may consume a large amount of information and bandwidth. The CCB DRAM controller 3826 can be used exclusively for CCB transfer between the CCB cache (context control block cache) 3450 and another external CCB DRAM 3791B. Different buses 3834 and 3836 can be used to access two different banks of DRAM 3791A and DRAM 3791B, respectively. Access to external memory by the other cache areas 3460, 3470, 3430, 3440 and 3771 is individually arbitrated via the bus 3834 by the main DRAM arbiter 3828. If the CCB cache 3450 is not connected to external DRAM via another CCB controller 3826, the main DRAM controller (arbiter) 3828 directs all accesses to the external DRAM 3791A to all cache areas 3825. Mediate.

  In other embodiments, access to external DRAM 3791A and access to external CCB DRAM 3791B are interleaved. This means that the CCB cache 3450 and the other cache area 3825 can perform memory access to both the external DRAM 3791A and the external DRAM 3791B. This allows two memory banks 3791A and 3791B to be accessed simultaneously. For example, the CCB cache 3450 can perform a read operation from the external memory 3791A and simultaneously perform a write operation to the external memory 3791B.

Normal Cache FIG. 33 shows an example of the normal cache 3460 in more detail. This normal cache 3460 receives a physical address 3910 from one of the SPUs 3410 (shown in FIG. 31). The cache line 3918 is accessed according to the lower address space (LOA) 3916 from the physical address 3910.

  This cache line 3918 may be relatively small or have a different size than the cache lines used in other cache areas 3825 in some examples. For example, the cache line 3918 may be much smaller than the cache line used in the streaming cache 3470 or the CCB cache 3450. This provides more customized memory access for different types of data processed by different cache areas 3825. For example, the cache line 3918 may be 16 bytes long when used for normal data processing control. On the other hand, the cache line used for the streaming cache 3470 may have a larger cache line (for example, 64 bits long) in order to transfer a large data block.

  Each cache line 3918 may maintain an associated valid flag 3920 that indicates whether the data in the cache line is valid. The cache line 3918 also holds an associated high order address (HOA) field 3922. The normal cache 3460 receives the physical address 3910 and then examines the HOA 3922 and valid flag 3920 for the cache line 3918 associated with LO A 3916. If the valid flag 3920 indicates a valid cache input and the HOA 3922 matches the HOA 3914 for the physical address 3910, the contents of the cache line 3918 are output to the requesting SPU 3410. If flag field 3920 indicates an invalid entry, the contents of cache line 3918 are overwritten by the corresponding address in external DRAM 3791A (shown in FIG. 30).

  Flag field 3920 indicates a valid cache entry, but if HOA 3922 does not match HOA 3914 in physical address 3910, one of the entries in cache line 3918 will automatically be external DRAM. The contents of the external DRAM 3791A associated with the physical address 3910 and loaded into the 3791A are loaded into the cache line 3918 associated with the LOA 3916.

Context Control Block (CCB) Cache FIG. 34 shows the context control block (CCB) cache 3450 in more detail. The CCB 3450 includes a plurality of buffers 3940 and an associative tag 3942. Unlike traditional 4-way associative caches, CCB 3450 behaves essentially like a 32-way associative cache. The plurality of CCB buffers 3940 and associative tags 3942 are controlled by a set of software commands transmitted via the SPU 3410. This software command 3946 includes a set of cache / DRAM instructions 3946 used to control data transfer between external DRAM 3791A or 3791B (shown in FIG. 30) and CCB cache 3450. A set of SPU / cache commands 3948 is used to control data transfer between the SPU 3410 and the CCB cache 3450. Software instructions 3946 include an ALLOCATE operation, a LOAD operation, a COMMIT operation, and a DROP operation. Software instructions 3948 include a READ (read operation) and a WRITE (write) operation.

  FIG. 35 shows some examples of CCB commands 3954 sent between the SPU 3410 and the CCB cache 3450. Any of these software commands 3944 can be issued to the CCB cache 3450 at any time by the SPU 3410.

  As shown in FIGS. 34 and 35, one of the SPUs 3410 sends an ALLOCATE command 3954A, which instructs the CCB cache 3450 to allocate one of the CCB buffers 3940 first. The ALLOCATE command 3954A can include a specific memory address associated with a physical address in DRAM 3791 containing the CCB or a specific CCB tag 3956. The control device 3950 in the CCB cache 3450 performs a process of matching the received CCB address 3956 and the address or tag associated with each buffer 3940 in parallel. The address associated with each buffer 3940 is held in the associated tag field 3942.

  If address / tag 3956 is not held in any tag field 3942, controller 3950 assigns one of the unused buffers 3940 to a particular CCB tag 3956. If the address already exists in one of the tag fields 3942, the controller 3950 uses a buffer 3940 that is already associated with a particular CCB tag 3956.

  The controller 3950 sends back a reply 3954B to the requesting SPU 3410. This response indicates whether the CCB buffer 3940 has been successfully allocated. If buffer 3940 is successfully allocated, controller 3950 maps all CCB commands 3944 from all SPUs 3410 using CCB tag 3956 to newly allocated buffer 3940.

  There are situations where the SPU 3410 may ignore data relating to a particular memory address currently in the external DRAM 3791. For example, this is the case when data in the external DRAM 3791 is scheduled to be overwritten. In a conventional cache architecture, content that has some specific address and is not currently held in the cache is automatically loaded from main memory into the cache. However, the ALLOCATE command 3946 simply allocates one of the buffers 3940 without first having to read data from the DRAM 3791. Thus, the buffer 3940 can be used as a memo pad for intermediate data processing without reading the data in the buffer 3940 from the external DRAM 3791 and writing it into the external DRAM 3791 so far.

  A LOAD or COMMIT software command 3946 is required to complete the data transfer between one of the cache buffers 3940 and the external DRAM 3791. For example, a LOAD command 3954C is sent from the SPU 3410 to the controller 3950 to load the CCB associated with a particular CCB tag 3956 from the external DRAM into the associated buffer 3940 in the CCB cache 3450. The controller 3950 can convert the CCB tag 3956 into a DRAM physical address. The controller 3950 can then retrieve the CCB from the DRAM 3791 associated with the DRAM physical address.

  A COMMIT command 3954C is sent by SPU 3410 to write the contents of buffer 3940 to the physical address in DRAM 3791 associated with CCB tag 3956. This COMMIT command 3956C also causes the controller 3950 to deallocate the buffer 3940 and allow this buffer to be allocated to other CCBs. However, other SPUs 3410 can later request buffer allocation for the same CCB tag 3956. If the CCB is still present in one of the buffers 3940, the controller 3950 can use the CCB that is currently in the buffer 3940 and located therein.

  The DROP command 3944 instructs the controller 3950 to discard the contents of a particular buffer 3940 associated with a particular CCB tag 3956. The controller 3950 discards the CCB by simply deallocating the buffer 3940 in the CCB cache 3450 without loading the buffer contents into the external DRAM 3791.

  READ and WRITE instructions 3948 are used to transfer CCB data between the CCB cache 3450 and the SPU 3410. READ and WRITE instructions 3948 allow data transfer between SPU 3410 and CCB cache 3450 only if buffer 3940 is pre-allocated.

  If all available buffers 3940 are currently in use, one of the SPUs 3410 will become one of the currently used buffers 3940 until the current ALLOCATE command is served by the CCB cache. You will have to do a COMMIT. The control device 3950 maintains a track (history) as to which buffer 3940 is assigned to a different CCB address. The SPU 3410 only needs to keep a count of the number of buffers 3940 currently allocated. If the count reaches the total number of available buffers 3940, one of the SPUs 3410 can issue a COMMIT or DROP command to release (deallocate) one of the buffers 3940. Some embodiments include at least twice as many buffers 3940 as SPUs 3410. This allows all SPUs 3410 to reserve two available buffers 3940 simultaneously.

  Since the operation in the CCB cache 3450 is under software control, the SPU 3410 only controls when the buffer 3940 is released and the buffer transfers data to the external memory 3791. In addition, the SPU 3410 that initially allocates the buffer 3940 to the CCB may be different from the SPU 3410 that issues the LOAD command and the SPU 3410 that eventually releases the buffer 3940 by issuing a COMMIT command or DROP command. .

  Command 3944 allows complete software control of data transfer between CCB cache 3450 and DRAM 3791. This is the case when packet data is processed by one or more SPU 3410 and during packet processing it is determined that a particular CCB does not need to be loaded into DRAM 3791 or it is read from DRAM 3791 It is quite effective when it is determined that it is not necessary to be performed. For example, one of the SPUs 3410 may determine that the packet has an incorrect checksum value while processing the packet. The packet can be dropped (dropped) from CCB buffer 3940 without loading the packet into DRAM 3791.

  In one embodiment, buffer 3940 is implemented as a cache line. Therefore, only one cache line is returned to the external DRAM memory 3791 for writing. In one embodiment, a cache line is 512 bytes and its words are 64 bytes wide. The control device 3950 can recognize which cache line has been changed. Then, the control device 3950 can return the cache line changed in the buffer 3940 to the external DRAM memory 3791 and write it as long as it is under the command of the COMMIT command.

  FIG. 36 shows an example of how CCB is used during the processing of a TCP session. Semantic processor 3100 (shown in FIG. 23) can be used for any kind of data processing, but here TCP packet 3960 is shown for illustration. Packet 3960 in this example has an Ethernet header 3962, an IP header 3964, a source IP address 3966, a destination IP address 3968, a TCP header 3970, a source TCP port address 3972, and a destination TCP port address 3974. And a payload 3976.

  The direct execution parser 3180 instructs one or more SPUs to obtain the source IP address and destination IP address from the IP header 3964, and obtains the source TCP port address and destination TCP port address from the TCP header 3970. To instruct. These addresses may be located in the input buffer 3140 (shown in FIG. 23).

  The SPU 3410 sends the four address values 3966, 3968, 3972, and 3974 to the CCB search table 3978 in the AMCD 3430. The search table 3978 includes an array of a source IP address field 3980, a destination IP address field 3882, a source TCP port address field 3984, and a destination TCP port address 3986. Each unique combination of addresses has an associated CCB tag 3979.

  The AMCD 3430 attempts to match the four address values 3966, 3968, 3972, and 3974 with the four entries in the CCB lookup table 3978. If there is no match, SPU 3410 assigns a new CCB tag 3979 for the TCP session associated with packet 3960. These four address values are written into the table 3978. If there is a match, AMCD 3430 sends back a CCB tag 3979 associated with the matching address combination.

  If CCB tag 3979 is sent back, SPU 3410 uses CCB tag 3979 sent back for the next processing of packet 3960. For example, the SPU 3410 may load specific header information from this packet 3960 into a CCB located in the CCB cache 3450. In addition, SPU 3410 may send payload data 3976 from packet 3960 to streaming cache 3470 (shown in FIG. 30).

  FIG. 37 illustrates several examples of control information that may be held in the CCB 3990. CCB 3990 may hold a CCB tag 3992 along with session ID 3994. Session ID 3994 may include a source and destination address for the TCP session. CCB 3990 may also maintain a linked list pointer that identifies a storage location containing packet payload data in external memory 3791. CCB 3990 may also hold TCP sequence number 3998 and acknowledgment number 4000. CCB 3990 may also hold any other parameters that may be needed to process a TCP session. For example, the CCB 3990 may hold a reception window field 4002, a transmission window field 4004, and a timer field 4006.

  All TCP control fields are placed in the same associated CCB 3990. This allows the SPU 3410 to quickly access all fields from the same CCB buffer 3940 in the CCB cache 3450 that are associated with the same TCP session. Further, since the CCB cache 3450 is controlled by software, the SPU 3410 can keep the CCB 3990 in the CCB cache 3450 until all required processing is completed by all the different SPUs 3410.

  There may be CCB 3990 associated with different OSI layers. For example, some CCB 3990 may be associated with and assigned to a SCSI session and other CCB 3990 may be associated with and assigned to a TCP session within a SCSI session.

  Figure 38 shows which flag 4112 indicates when SPU 3410 has finished processing CCB content in buffer 3940 and when buffer 3940 is available and freed for access by other SPUs. Shows how it is used in the CCB cache 3450.

  The IP packet 4100 is received by the processing system 3100 (shown in FIG. 23). This IP packet 4100 has a header section including an IP header 4102, a TCP header 4104, and an iSCSI header 4106. The IP packet 4100 also has a payload 4108 that includes packet data. Parser 3180 (shown in FIG. 23) directs different SPUs 3410 to process information contained in different IP headers 4102, TCP headers 4104, and iSCSI headers 4106 and data contained in payload 4108. can do. For example, the first SPU # 1 processes the IP header information 4102, the SPU # 2 processes the TCP header information 4104, and the SPU # 3 processes the iSCSI header information 4106. Another SPU # N may be instructed to load the packet payload 4108 into the buffer 4114 in the streaming cache 3470. Of course, any combination of SPUs 3410 can process any header information and payload information in the IP packet 4100.

  All of the header information in the IP packet 4100 may be associated with the same CCB 4110. The SPU1-3 stores and accesses the CCB 4110 via the CCB cache. CCB 4110 also includes a completion bit mask 4112. Here, when these tasks are completed, the SPU 3410 performs a logical OR operation on other bits of the completion mask 4112 (unintentionally) with other unknown bits. For example, SPU # 1 may set the first bit of completion bit mask 4112 when processing of IP header 4102 in CCB 4110 is completed. The SPU # 2 can set the second bit of the completion bit mask 4112 when the processing of the TCP header 4104 is completed. When all bits of the completion bit mask 4112 are set, this indicates that the processing of the IP packet 4100 by the SPU is completed.

  Thus, when processing for the payload 4108 is completed, the SPU # N checks the completion mask 4112. If all bits of mask 4112 are set, SPU # N may send a COMMIT command to CCB cache 3450 (shown in FIG. 31), for example. This COMMIT command instructs the CCB cache 3450 to delegate the contents of the cache line containing the CCB 4110 to the external DRAM memory 3791.

Streaming Cache FIG. 39 shows the streaming cache 3470 in more detail. In one embodiment, the streaming cache 3470 includes a plurality of buffers 4200 that are used to send and receive data from the DRAM 3791. An example buffer 4200 is 256 bytes wide, and each cache line includes a tag field 4202, a VSD field 4204, and a 64-byte portion of the buffer 4200. In this way, four cache lines are associated with each buffer 4200. The streaming cache 3470 includes two buffers 4200 for each SPU 3410 in one implementation.

  The VSD field 4204 contains a valid value that indicates whether the cache line is valid or invalid, and a status value that indicates whether the cache line is still being updated or has been updated (dirty or clean). And a command value (direction value) indicating whether the data is in a read state, a write state, or a non-merged state.

  Of particular relevance to the streaming cache is a pre-fetch operation performed by the cache controller 4206. The physical address 4218 is sent to the control device 4206 from one of the plurality of SPUs 3410 requesting reading from the DRAM 3791. The controller 4206 associates the physical address with one of the cache lines (eg, the cache line 4210). The streaming cache controller 4206 then automatically pre-fetches 4217 for the three other 64-byte cache lines 4212, 4214, 4216 associated with the same FIFO byte order in the buffer 4200.

  One important aspect of pre-fetch 4217 is how the tag field 4202 is associated with a different buffer 4200. The tag field 4202 is used by the controller 4206 to identify a particular buffer 4200. The portion of physical address 4218 associated with tag field 4202 is selected by controller 4206 to avoid buffer 4200 holding a continuous physical address arrangement. For example, the controller 4206 may use a middle order bit 4220 in the middle of the physical address 4218 to associate that bit with the tag field 4202. This prevents the pre-fetch 4217 of three consecutive cache lines 4212, 4214, 4216 from colliding with streaming data operations associated with the cache line 4210.

  For example, one of the SPUs 3410 may send a command with an associated physical address 4218 to the streaming cache 3470. This command requests that packet data be loaded from the DRAM memory 3791 into the first cache line 4210 associated with the particular buffer 4200. This buffer 4200 has a tag value 4202 associated with a part of the physical address 4218. Thereafter, the controller 4206 may attempt to perform a pre-fetch operation to load the cache lines 4212, 4214, 4216 associated with the same buffer 4200 as well. However, because the buffer 4200 is already in use by the SPU 3410, the pre-fetch 4217 will get stuck. In addition, once pre-fetch 4217 is allowed to complete, they can overwrite cache lines already loaded according to other SPU commands in buffer 4200.

  By obtaining the tag value 4202 from the middle order bit 4220 in the middle of the physical address 4218, each physical address limit of 256 consecutive bytes is stored in a different memory buffer 4200. It becomes. This prevents collisions between operations during a pre-fetch operation.

AMCD
FIG. 40 is a functional block diagram of an example of the AMCD 3430 in FIG. SPU cluster 4012 communicates directly with AMCD 3430, while ARM 4014 can communicate with AMCD 3430 via SPU 3710 in SPU cluster 4012. The AMCD 3430 provides a memory lookup facility for the SPU 3410. In one example, SPU 3410 determines where a previously saved entry is stored in memory, such as external DRAM 3791 (see FIG. 28). The search function in the AMCD 3430 can search a location where some data in the network system is stored, and is not limited to the external DRAM 3791.

  When this system is in non-learning mode, SPU 3410 maintains its own memory mapping table and manages it by adding, deleting and modifying entries. When the system is in learning mode, the SPU 3410 maintains the table by executing a command to search TCAM memory while adding entries or a command to search TCAM memory while deleting entries. To do. In either mode, key values (hereinafter “key values”) are used by the SPU 3410 to perform each of these different types of searches.

  The AMCD 3430 in FIG. 40 has a set of lookup interfaces (LUIF) 4062. In one embodiment, AMCD 3430 has 8 LUIFs. Details of an example LUIF are shown and include a set of 64-bit registers 4066. These registers 4066 provide a storage location for data and a command to perform a memory search. Search results are also returned via these registers 4066. One embodiment includes one 64-bit register for search commands and up to seven 64-bit registers for data storage. Not all registers need be used. In some embodiments of the present invention, the communication interface between SPU cluster 4012 and LUIF 4062 is 64 bits wide, which makes it convenient for LUIF 4062 to include multiple 64-bit registers. An example of the structure of this command is shown in FIG. 41, and the contents will be described below.

  The designed system has a finite number of LUIFs 4062, and since these LUIFs cannot be accessed by more than one SPU 3410 at a time, a mechanism is provided to allocate free LUIFs to the SPU 3410. . The free list 4050 manages the usage of LUIF 4062. If the SPU 3410 wants to access the LUIF 4062, the SPU reads the free list 4050 to see which LUIF 4062 is in use. After reading the free list 4050, the address of the next available free LUIF 4062 is returned with a value indicating that the LUIF 4062 can be used. If the returned value for the LUIF 4062 is valid, the SPU 3410 can safely control the LUIF. An entry is then made to the free list 4050 that the particular LUIF 4062 cannot be used by another SPU 3410 until the first SPU 3410 releases the LUIF. After this first SPU 3410 has finished searching and returned search results, the SPU places the identifier of the used LUIF on the free list 4050, and the LUIF is again for use by other SPU 3410s. It becomes available. If there is no free LUIF on the free list 4050, the requested SPU 3410 is informed that there is no free LUIF and the SPU 3410 is forced to try again later to get a free LUIF 4062 . The free list 4050 also provides a pipelining function that allows the SPUs 3410 to start index loading while waiting for other SPU requests to be processed.

  The selected LUIF sends a search command and data to an arbiter 4068 as described below. This arbiter 4068 selects which particular LUIF 4062 has access to a particular TCAM controller. In this embodiment, in addition to the external TCAM control device 1072, there is a built-in (internal) TCAM control device 4076. The external TCAM control device 4072 is connected to another external TCAM 4082 and is also connected to the external SRAM 4096 via the external TCAM 4082. Similarly, the built-in TCAM control device 4076 is connected to the built-in TCAM 4096, and is also connected to the built-in SRAM 4086 via the built-in TCAM 4096.

  Normally, only one TCAM at a time operates in this system, ie either the built-in TCAM 4096 or the external TCAM 4082. In other words, if the system includes an external TCAM and SRAM 4092, the AMCD 3430 communicates with these external memories. Similarly, if the system does not have an external TCAM and SRAM 4092, the AMCD 3430 communicates only with the built-in TCAM 4096 and built-in SRAM 4086. As will be described below, only one controller 4076 or 4072 is used depending on whether there is external memory. The particular controller 4072 or 4076 that is not being used by the AMCD 3430 is said to be “turned off” during the setup process. In one embodiment, during system initialization, a setup command is sent to AMCD 3430 indicating whether there is an external TCAM 4082. When there is an external TCAM 4082, the built-in TCAM control device 4076 is “turned off” and the external TCAM control device 4072 is used. On the other hand, when there is no external TCAM 4082, the external TCAM control device 4072 is “turned off” and the built-in TCAM control device 4076 is used. For simplicity, it is preferred that only one of the TCAM controllers 4076 or 4072 is used, but AMCD 3430 can be run using both TCAM controllers 4076 and 4072. It can be done.

  In one example embodiment, the built-in TCAM 4096 includes 512 entries, as does the SRAM 4086. In another embodiment, the external TCMA 4082 includes 64k-256k entries that match the number of entries in the external SRAM 4092 (one entry is 72 bits, and multiple entries are linked together 72 Produces a wider search range than bits). Normally, SRAM 4086 and 4092 are 20 bits wide, while TCMA 4082 and 4086 are much wider than them. The built-in TCAM 4906 can be 164 bits wide, for example, while the external TCAM 4082 is, for example, in the range of 72-448 bits wide.

  When the SPU 3710 performs a search, a key is created from the packet data as described above. The SPU 3410 reserves one of the LUIFs 4062 and then loads the command (CMD) and data into the register 4066 of the LUIF 4062. When commands and data are loaded, the search begins in either TCAM 4096 or 4082. The command from register 4066 is sent to arbiter 4068 and then the data is sent to the appropriate TCAM 4096,4082. For example, assume there is an external TCAM 4082 and it is in use. In response to a TCAM command, the data sent by the SPU 3410 is presented to the external TCAM controller 4072 and the controller 4072 presents the data to the external TCAM 4082. When the external TCAM 4082 finds a key data match, the corresponding data is retrieved from the external SRAM 4092. In some embodiments, SRAM 4092 stores a pointer to a memory location that contains the desired data indexed by the key value stored in the TCAM. The pointer from this SRAM 4092 is returned to the requesting SPU 3410 via the register 4066 of the original LUIF 40062 used by the original requesting SPU 3410. LUIFs 4062 can thus be used for searching, writing, reading, or standard maintenance operations on DRAM 3791 or memory somewhere in the system.

  By using these methods, TCAM 4082 or 4096 is used for high speed search in CCB DRAM 3791B (FIG. 30). TCAM 4082 or 4096 can also be used for applications where a very large number of sessions need to be searched for CCBs for IPv6 simultaneously. Further, TCAM 4082 or 4096 can also be used to implement a static route table that needs to look up port addresses for different IP sessions.

  A set of configuration register table 4040 is used in conjunction with the key value sent by SPU 3410 in performing a memory search. In one embodiment, there are 16 table entries, and each table can be indexed by 0000-1111 4-bit indicators. For example, the data stored in the configuration table 4040 can include the size of the key in the requested search. Various size keys such as 64, 72, 128, 144, 164, 192, 256, 288, 320, 384 or 448 bits can be used. The configuration table 4040 stores data of a special key size (when the keyed data is searched) and other various data. As shown in FIG. 41, the table identifier number is at the position of bit location 19:16, which indicates which value is used in the configuration table 4040.

  FIG. 42 shows an example of the arbiter 4068. Arbiter 4068 is connected to each LUIF 4062. The arbiter 4068 is also connected to a select MUX 4067 connected to both the built-in TCAM control device 4076 and the external TCAM control device 4072. As described above, in some embodiments of the present invention, only one of the TCAM control devices 4076 and 4072 operates at a time, and the control device is controlled by a signal sent to the selector MUX 4067 at startup. In this embodiment, the arbiter 4068 does not distinguish whether the output signal is sent to the built-in TCAM controller 4076 or the external TCAM controller 4072. Instead, the arbiter 4086 simply sends an output signal to the select MUX 4067 and the select MUX 4067 directs the search request to the appropriate TCAM controller 4076 or 4072 based on the state of the setup value input to the MUX. It is supposed to route and send.

  The function of the arbiter 4068 is to select one of the LUIFs 4062 indicated by the symbols LUIF-1 to LUIF-8 in FIG. 42, and the selected LUIF 4062 is selected by the selected TCAM controller 4076 or 4072. It will be used next. This arbiter 4068, in its simplest form, can be implemented as a round-robin arbiter. In a more intelligent system, the arbiter 4068 uses the past history to give a priority value that indicates which LUIF 4062 should be selected next, as described below.

  That is, in this more intelligent arbiter 4068, the priority system indicates which LUIF 4062 was most recently used and makes this content a factor for determining which LUIF 4062 to select in the next search operation. It is like that. FIG. 43 shows an example of arbitration in an example of an intelligent arbiter. At time A, each priority value is already initialized to “0”, and LUIF-3 and LUIF-7 are put in an operation (work) pending state. Arbiter 4068 selects only one LUIF 4062 at a time, so LUIF-3 is selected via arbitration. This is because other LUIFs (LUIF-7) whose operations are pending have the same priority (in this case, “0”). Once LUIF-3 is chosen. The priority is set to “1”. At time B, LUIF-3 has a new operation pending, while LUIF-7 still has an operation that is not yet used. In this case, the arbiter 4068 selects LUIF-7 because LUIF-7 has a higher priority than LUIF-3. This ensures that each of all LUIFs is used equally and ensures that only one particular LUIF does not monopolize the search time.

  At time C, LUIF-1 and LUIF-3 have pending operations, and arbiter 4068 selects LUIF-1. This is because the operation in LUIF-3 has been pending for a longer time, but LUIF-1 has a higher priority. Finally, at time D, only LUIF-3 has a pending operation, so arbiter 4068 selects LUIF-3 and sets its priority to “2”.

  In this way, the arbiter 4068 performs intelligent round-robin arbitration. In other words, once a particular LUIF is selected, the LUIF moves to “end of the line” and all other LUIFs with pending operations are Used before LUIF is selected again. This method equalizes the time each LUIF 4062 uses its search function and ensures that only one particular LUIF 4062 does not monopolize all of the search bandwidth.

  The system described above can use a dedicated processor system, microcontroller, or programmable logic device that performs all or some of the above operations. Also, some of the operations described above may be performed in software, and other operations may be performed in hardware.

  One skilled in the art will appreciate that other functional partitions are possible within the scope of the present invention. It should also be noted that what functions are performed or not performed on a common integrated circuit depends on the application.

  Finally, in this specification, in several places, “in one embodiment ...”, “in one embodiment ...”, “in other embodiments ...”, “some In the embodiment, it is not necessarily meant to mean the same specific embodiment, but also means that the features described there apply to only one particular embodiment. Note that it is not.

1 shows a block diagram of a typical von Neumann machine storage server. 1 shows a block diagram of a general storage server according to an embodiment of the present invention. FIG. FIG. 2 shows a more detailed block diagram of a storage server according to an embodiment of the present invention. Fig. 2 illustrates a general structure of a client request frame of an Ethernet / IP / TCP / CIFS storage server. 5 shows details of the storage message block portion of the CIFS frame structure shown in FIG. An implementation of a semantic processor that can be used in the above-described embodiment of the present invention is shown in a block diagram. FIG. 3 shows a block diagram of an embodiment of a storage server with multiple physical data storage devices. FIG. 2 shows a block diagram of an embodiment of the present invention that can be implemented on a printed circuit board of a data storage device. FIG. 4 shows a block diagram of an implementation having a semantic processor in direct communication with disk drive electronics. FIG. 3 shows a block diagram of a conversion storage server according to an embodiment of the present invention. 1 illustrates an embodiment of a system characterized in that multiple physical data storage devices are accessed by a semantic processor via an external storage interface. 1 illustrates an embodiment of a system characterized in that a plurality of physical data storage devices are coupled to a semantic processor via a port expander. Fig. 6 illustrates yet another semantic processor embodiment that can be used in embodiments of the present invention. FIG. 2 illustrates in block diagram form a semantic processor that can be used in embodiments of the present invention. Fig. 4 illustrates the configuration of one feasible parser table that can be used in an embodiment of the present invention. 3 shows the configuration of one feasible generation rule table that can be used in an embodiment of the present invention. One specific example of an input buffer that can be used in an embodiment of the present invention is shown in a block diagram. One specific example of a direct execution parser (DXP) that can be used in embodiments of the present invention is shown in block diagram form. It is an example of the flowchart regarding the process of the data input in the semantic processor shown in FIG. Fig. 4 illustrates another semantic processor embodiment that can be used in embodiments of the present invention. An example of a port input buffer (PIB) that can be used in embodiments of the present invention is shown in block diagram form. FIG. 6 illustrates, in block diagram form, another embodiment of a direct execution parser (DXP) that can be used in embodiments of the present invention. It is an example of the flowchart regarding the process of data input in the semantic processor shown in FIG. FIG. 2 illustrates in block diagram form a semantic processor that can be used in embodiments of the present invention. FIG. 24 is a flowchart relating to processing of a received packet in a semantic processor including the recirculation buffer shown in FIG. 23. Fig. 6 illustrates in more detail another semantic processor embodiment that may be used in embodiments of the present invention. FIG. 26 shows a flowchart of a received fragmented IP packet within the semantic processor shown in FIG. FIG. 26 shows a flowchart of a packet received in the semantic processor shown in FIG. 25 that is encrypted, unauthenticated, or both. Fig. 6 illustrates yet another semantic processor embodiment that may be used in embodiments of the present invention. Fig. 6 illustrates yet another semantic processor embodiment that may be used in embodiments of the present invention. FIG. 29 is a flowchart of an iSCSI packet received via a TCP connection in the semantic processor shown in FIG. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail. FIG. 3 is a diagram illustrating the memory subsystem in more detail.

Claims (14)

A datagram interface that receives client requests for data operations;
A storage interface for accessing at least one data storage device;
A storage server comprising: a semantic processor having the ability to parse received client requests based on a stored grammar for transaction via the storage interface in response to the at least one data storage device and data operations .   The said semantic processor is provided with the direct execution parser which analyzes a symbol from the datagram received in the said datagram interface, and several semantic code execution engine which performs a data operation according to the instruction | indication by the said direct execution parser. The listed storage server.   The storage according to claim 1, wherein the semantic processor comprises a direct execution parser that analyzes symbols from datagrams received at the datagram interface, and a microprocessor that performs data operations on the analyzed datagrams. server.   The semantic processor comprises a parser stack, a direct execution parser that parses symbols from datagrams received at the datagram interface according to the stack symbols, and at least one semantic code that performs data operations as instructed by the direct execution parser The storage server of claim 1, further comprising an execution engine, wherein the semantic code execution engine has the ability to change the operation of the direct execution parser by modifying the contents of the parser stack.   The storage server according to claim 1, wherein the at least one data storage device is a disk drive having a housing, and the datagram interface, the storage interface, and the semantic processor are built in the housing of the disk drive. .   The storage interface is a secondary datagram interface, the at least one data storage device is remotely accessed via the secondary datagram interface, and the storage server includes: The storage server of claim 1, wherein the storage server is operable to act as a client of the at least one data storage device to satisfy a client request received by the storage server.   And a second datagram interface that receives a client request for data operation, and a parser source selector that causes the semantic processor to switch between parsed datagram symbols from the two datagrams. Item 4. The storage server according to item 1.   In addition, a reconfigurable memory that holds at least a portion of the stored grammar is provided so that the storage server can be reconfigured to function as a storage server having at least two different sets of storage server protocols. The storage server according to claim 1. A direct execution parser configured to control the processing of digital data by analyzing the data semantically in a buffer;
A semantic processing unit configured to perform data operations when instructed by the direct execution parser;
An apparatus comprising: a memory subsystem configured to process the digital data when instructed by the semantic processing unit.   The apparatus of claim 9, wherein the memory subsystem includes a plurality of memory caches connected between a memory and the semantic processing unit.   The apparatus of claim 9, wherein the memory subsystem includes an encryption circuit that performs an encryption operation on digital data when instructed by the semantic processing unit.   The apparatus of claim 9, wherein the memory subsystem includes a search engine that performs look-up functions when instructed by the semantic processing unit.   The apparatus of claim 9, wherein the buffer is adapted to receive data to be analyzed by the direct execution parser from an external network.   The apparatus of claim 9, wherein the buffer is adapted to receive data to be analyzed by the direct execution parser from the semantic processing unit.

Images