Message processing device and method, equipment and medium

Abstract

The invention discloses a message processing device and method, equipment and a medium. An exemplary message processing method may include: receiving a plurality of messages; matching the plurality of messages with a first classification table according to a first matching rule to determine logic interfaces corresponding to the plurality of messages; and matching the plurality of messages with a second classification table according to a second matching rule to determine service flows corresponding to the plurality of messages, the second matching rule being associated with the configuration information of the logic interface.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to an apparatus, method, device, and storage medium for message processing. Background Art

[0002] In the process of a communication device transmitting data messages, an access device often needs to forward the received messages, which can be completed by hardware (e.g., an ASIC chip) or software (e.g., a virtual switch). Regardless of which method is used, almost all forwarding processing is implemented based on a table lookup method. Therefore, the design and matching of the lookup table affect the resource occupancy of the forwarding processing. On the other hand, an access device may receive millions of messages per second. Therefore, whether it is a software or hardware implementation solution, the throughput performance of messages has always been one of the main challenges, and improving the system processing performance is also an urgent problem in the industry. Summary of the Invention

[0003] Various exemplary embodiments of this application aim to solve at least a part of the above problems or issues.

[0004] According to a first aspect of this application, there is provided a message processing method, including: receiving a plurality of messages; matching the plurality of messages with a first classification table according to a first matching rule to determine a logical interface corresponding to the plurality of messages; and matching the plurality of messages with a second classification table according to a second matching rule to determine a service flow corresponding to the plurality of messages, where the second matching rule is associated with configuration information of the logical interface.

[0005] In some exemplary embodiments, matching the plurality of messages with a first classification table according to a first matching rule includes: performing multi-level matching on the plurality of messages using a plurality of first classification tables to determine a logical interface corresponding to the plurality of messages.

[0006] In some exemplary embodiments, matching the plurality of messages with a first classification table according to a first matching rule to determine a logical interface corresponding to the plurality of messages includes: obtaining feature information of the plurality of messages according to the first matching rule, constructing a first keyword according to the feature information, and querying in the first classification table based on the first keyword, so as to determine a logical interface corresponding to the first keyword.

[0007] In some exemplary embodiments, the feature information includes at least one of the following: an identifier of a physical port for receiving the message, a virtual local area network (VLAN) identifier of the message, or a protocol type of the message.

[0008] In some example embodiments, the configuration information of the logical interface includes at least one of the following: an access control list (ACL) rule, or the priority of a message.

[0009] In some example embodiments, matching the plurality of messages with a second classification table according to a second matching rule to determine the service flows corresponding to the plurality of messages includes: extracting corresponding field contents from the plurality of messages according to the second matching rule to construct a second keyword; and querying the second classification table based on the second keyword to determine the service flows corresponding to the plurality of messages.

[0010] In some example embodiments, the fields include a MAC address, a virtual local area network identifier, an IP address, a port number, and a priority indicator.

[0011] In some example embodiments, the method further includes: moving one or more messages corresponding to the same service flow among the plurality of messages into a corresponding FIFO instance.

[0012] In some example embodiments, the method further includes: performing batch forwarding processing on the messages included in the FIFO instance in terms of all the messages included in the FIFO instance.

[0013] In some example embodiments, the batch forwarding processing includes: performing single supervision processing, counting processing, and enqueueing processing on the messages included in the FIFO instance.

[0014] In a second aspect, a message processing apparatus is provided. The message processing apparatus may include at least one processor and at least one memory. The at least one memory may store instructions that, when executed by the at least one processor, may cause the message processing apparatus to at least perform: receiving a plurality of messages; matching the plurality of messages with a first classification table according to a first matching rule to determine the logical interface corresponding to the plurality of messages; and matching the plurality of messages with a second classification table according to a second matching rule to determine the service flows corresponding to the plurality of messages, where the second matching rule is associated with the configuration information of the logical interface.

[0015] In a third aspect, a message processing device is provided. The message processing device may include: a receiving module, configured to receive a plurality of messages; a first matching module, configured to match the plurality of messages with a first classification table according to a first matching rule to determine the logical interface corresponding to the plurality of messages; and a second matching module, configured to match the plurality of messages with a second classification table according to a second matching rule to determine the service flows corresponding to the plurality of messages, where the second matching rule is associated with the configuration information of the logical interface.

[0016] In a fourth aspect, a computer-readable medium is provided, in which instructions are stored, and when the instructions are run by at least one processor in the message processing device, the message processing device is caused to execute the method described in the first aspect above. Description of the Drawings

[0017] Figure 1 The schematic diagram showing the basic process of using OVS for message processing in the prior art is shown.

[0018] Figure 2 The exemplary architecture of the message processing device according to an exemplary embodiment of the present application is shown.

[0019] Figure 3 The exemplary flow of the message processing method according to an exemplary embodiment of the present application is shown.

[0020] Figure 4 The schematic block diagram of the message processing device according to an exemplary embodiment of the present application is shown.

[0021] Figure 5 The schematic block diagram of the message processing device according to an exemplary embodiment of the present application is shown.

[0022] The same or substantially the same elements, operations, and steps shown in the respective drawings may be represented by the same reference numerals. For the sake of clarity, not every element, operation, and step is shown in each drawing. Detailed Description of the Embodiments

[0023] The exemplary embodiments of the present application will be described in more detail below with reference to the drawings. It should be understood that the present application should not be construed as being limited to the exemplary embodiments described herein, but may also be implemented in various other forms. These exemplary embodiments are provided only to more thoroughly and completely understand the present application. It should also be understood that the drawings of the present application are given only as examples and are not used to limit the precise form of the embodiments or to define the protection scope of the present application.

[0024] The forwarding process of packets is mainly based on table lookup. Taking the layer 2 switching process as an example, its typical processing process is as follows: when receiving a packet, the processor determines the processing behavior at the ingress, such as whether access control list (ACL) matching, policing, learning in the forwarding database (FDB), packet editing, etc. are required. Each of these processes may need to extract fields from the packet or previous query results to construct a key, and then look up the corresponding rule table according to this key. After successfully matching a rule, the corresponding action indication is returned. For the processing behavior at the egress, it also includes multiple processes of constructing keys and looking up tables. Multiple table lookups for flow tables are time-consuming, and the processing efficiency of packets is relatively low.

[0025] Currently, virtual switch products in the industry for virtual machine network data forwarding scenarios have achieved certain optimizations for the table lookup process. Taking the open virtual switch (OVS) as an example, it is a virtual switch based on the openflow model. Figure 1 The figure shows a schematic diagram of the basic process of packet processing using OVS. As shown in the figure, OVS 100 includes a virtual switching component 115 (such as ovs-vswitchd) running in the user space 110 and a data path module 125 running in the kernel space 120. The switching component 115 can obtain the open flow flow table from the controller 130 and is responsible for the flow table function. The data path module 125 is used to perform specific operations on the packet according to the flow table. The data path module 125 receives the packet from the network interface card (NIC). When the packet 140 of the data stream arrives for the first time, the data path module 125 sends the packet to the switching component 115, which parses the packet information and determines the processing behavior based on the traditional multiple table lookup method. At the same time, it generates an entry for the flow table for the processing process, and its key contains all necessary fields. When the subsequent packet 150 of the data stream flows in from the network interface card, the data path module 125 can match the corresponding flow table entry in the data path cache according to the information of this packet, so as to directly execute the behavior indicated in the flow table entry by skipping multiple table lookups to complete the processing of the packet.

[0026] However, there is an implementation problem in the Open vSwitch (OVS) design based on the OpenFlow model: the definition rules of OpenFlow for service flows are too flexible, and it can use any field as a rule to define a service flow, which results in the inability to well match the actual granularity of the service flow with the granularity of flow table entries. That is to say, the keywords searched in the flow table of OVS cannot be treated differently according to the service flow because it is not known which service flow the current packet belongs to before the search. Therefore, it generally needs to define keywords with a fine granularity, which will lead to an increase in the number of query items and may require frequent access to the table lookup process multiple times to determine the forwarding behavior of the service flow, thus posing challenges to the operator in terms of resources and performance.

[0027] In view of this, some aspects of the embodiments of the present application provide an optimized packet processing method, which differentiates different service flows by defining a logical interface above the physical port. Moreover, during the process of forwarding and processing packets, the necessary granularity of the service flow can be determined based on the service configuration on the logical interface before looking up the table. In this way, the embodiments of the present application can add flow table entries with accurate granularity, thereby avoiding resource waste and effectively improving the packet processing performance of the system.

[0028] Figure 2 An example architecture of a packet processing device according to an exemplary embodiment of the present application is shown. The packet processing device 200 may be, for example, a physical host or server managed by software and configured with a network interface card (NIC), and the hardware may include a central processing unit (CPU), a memory, a network interface card, etc. (not shown). As Figure 2 shown, the packet processing device 200 includes an ingress port 210, a logical interface determination module 220, a service flow classification module 230, an action execution module 240, and an egress port 250.

[0029] The ingress port 210 can be connected to a physical network interface card (NIC) so as to receive network packets from an external network device, that is, the ingress port 210 can be a physical port. Although only one ingress port is shown, it can be understood that the packet processing device 200 may include multiple ingress ports, and each ingress port is configured with a physical port identity (ID), such as a port number.

[0030] In one embodiment, when a packet is received from a network card, the packet processing device 200 can dynamically allocate memory for it to store the data of the packet and related context information, such as the header information of the packet and information such as the port for receiving the packet. The packet can be stored in the cache in the form of data blocks. The storage addresses of all data blocks of a packet in the cache form a linked list, and each address is called a pointer (also called a packet pointer). In one embodiment, multiple received packets can be stored in a FIFO (First Input First Output) queue in the order of reception to form a physical port FIFO 260. The physical port FIFO 260 can be implemented as a singly linked list that stores the pointers of each packet's data. When a packet moves between different FIFOs, only the corresponding packet pointer needs to be moved.

[0031] The logical interface determination module 220 can be used to analyze each packet in the physical port FIFO 260 to determine its corresponding logical interface. In the embodiments of the present application, a "logical interface" is an interface logically divided on top of a physical port and is used to distinguish different services. The logical interface corresponding to a packet is the logical interface to which the packet belongs. Through the logical interface of the packet, its belonging service attribute can be identified. Thus, based on the configuration of the logical interface, the granularity of different packet flows that need to be further distinguished within the scope of this service can be determined, that is Figure 2 the granularity of the service flow shown, that is to say, the actual granularity of the service flow that needs to be matched can be flexibly defined by analyzing the configuration of the logical interface, thereby saving system resources, which will be specifically described later.

[0032] The classification of logical interfaces can be based on fixed matching rules or can be flexibly determined according to actual service requirements or service configurations. In one embodiment, the characteristic information of a packet can be obtained according to a preset matching rule and the logical interface to which the packet belongs can be determined based on this characteristic information. The characteristic information of the packet can be, for example, the physical port identifier (ID) for receiving the packet, the virtual local area network (VLAN) identifier of the packet, or the protocol type of the packet. The embodiments of the present application are not limited to this, and other information and / or fields that can determine the logical interface of the packet can be selected according to the service configuration of the device as the characteristic information of the packet.

[0033] In one embodiment, the logical interface of a packet can be determined by looking up a table. For example, one or more classification tables (also referred to as "logical interface classification tables") can be stored in the logical port determination module 220. Each received packet is matched at one or multiple levels using the one or more classification tables to find the logical interface corresponding to different packets. The purpose of classifying packets by logical interface is to find the best service flow granularity that conforms to the service configuration. If the granularity is large, the subsequent processing actions of the packet may not conform to the expected behavior of the service configuration. If the granularity is small, it will cause waste of storage resources. Therefore, the entry content of the logical interface classification table and the number of matching levels can be determined according to the actual service configuration. For example, when different physical ports of the device correspond to different service types, only one classification table is needed for one-level matching to classify the service flow of the packet. On the other hand, when the service configuration model of the device classifies the service flow at two or more levels, multiple classification tables are correspondingly needed for multi-level matching to determine the logical interface. When the storage space permits, multiple classification tables can also be integrated into an integrated classification table, thereby improving the processing efficiency.

[0034] After determining the logical interface of a packet in the physical port FIFO 260, the service flow classification module 230 can then query the packet to determine the service flow corresponding to the packet, so as to determine what forwarding processing it will go through. The service flow corresponding to the packet is the service flow to which the packet belongs. Dividing the packets by service flow is conducive to unified batch processing with the packets included in the service flow as the granularity, which will be described in detail later.

[0035] In one embodiment, the service flow corresponding to a packet can be determined by looking up a table. For example, the service flow classification module 230 first extracts the content of specific fields from the packet to construct a service flow keyword, and then uses the service flow keyword to look up and match in a classification table (also referred to as "service flow classification table" in this article) to determine the service flow identifier corresponding to different packets.

[0036] In one embodiment, the service flow classification module 230 can obtain the configuration information or template (profile) for constructing the service flow keyword according to the logical interface of the packet. The configuration information or template contains the matching rules on how to extract fields or which fields to extract from the packet to construct the keyword for determining the service flow corresponding to the packet. Then, according to the matching rules, the corresponding field content is extracted from the packet to construct the service flow keyword of the packet.

[0037] The matching rule for constructing the service flow keyword of a message can be associated with the configuration information of the logical interface to which the message belongs. In other words, this matching rule comes from the specific configuration information on the corresponding logical interface. Since the service configuration on the logical interface determines the necessary granularity of the service flow (i.e., the constituent fields for looking up keywords), the flow table entries with precise granularity can be set accordingly in this way. For example, when the service flow only cares about the three-layer information, the field information such as the IP address can be extracted from the message accordingly, instead of extracting the four-layer information as the constituent fields for constructing the keyword. Compared with the fixed-granularity five-tuple or seven-tuple information adopted in the prior art, the embodiments of the present application are beneficial to saving storage resources and improving the message processing performance.

[0038] For the specific implementation of constructing the keyword, when the configuration information of the logical interface is issued, it can trigger the analysis of this configuration information one by one, so as to deduce the final keyword construction rule. Alternatively, when the first message of a logical interface flows into the message processing device, it can be looked up one by one according to the traditional process (for example, the multiple table lookup processes of OVS for the first message). There are definite keyword construction rules in these tables. Record the specific construction of the keyword used in each table lookup process of this message, and then merge all the keyword construction methods together to obtain the final keyword construction rule.

[0039] In one embodiment, the service flow classification table can be specifically implemented as a hash table. Use a preset hash function to perform a hash calculation on the constructed service flow keyword (key value) to obtain a hash value. The value read with this calculated hash value as the address can identify the service flow to which the message belongs. As discussed above, this key value corresponds to the granularity of the service flow, thereby avoiding waste of storage resources and improving the performance of matching and lookup.

[0040] In one embodiment, the service flow classification table can be stored in a dynamically created cache, which is a set of current active traffic and can be accelerated for access by using the physical cache mechanism of the central processing unit (CPU). When a service flow appears, a flow table entry can be dynamically generated for it and added to the cache table. At the same time, a FIFO instance corresponding to this flow table entry (also referred to as the "service flow FIFO instance" in this article) can be dynamically generated. After the subsequent messages of this service flow hit the corresponding flow table entry, the address of the service flow FIFO instance can be returned, and the pointer of the message can be moved to this service flow FIFO instance. In addition, when the traffic ends, the corresponding flow table entry and FIFO instance can be aged and deleted, so as to improve the utilization efficiency of the storage space.

[0041] Refer to Figure 2, assume that there are n traffic flows in the physical port FIFO 260 (n is a positive integer). The traffic flow classification module 230 processes each packet in the physical port FIFO 260 one by one, finds the traffic flow FIFO corresponding to each packet, and moves the packet into the corresponding traffic flow FIFO 270 by moving the packet pointer. By repeating the above steps, one or more packets corresponding to the same traffic flow in the physical port FIFO 260 can be moved into the corresponding traffic flow FIFO instance. The packets in each traffic flow FIFO instance correspond to the same traffic flow (i.e., have the same key value). For example, the packets in the traffic flow FIFO 271 correspond to traffic flow 1, the packets in the traffic flow FIFO 272 correspond to traffic flow 2, …… the packets in the traffic flow FIFO 27n correspond to traffic flow n.

[0042] In one embodiment, in addition to including the pointers of the packets, the traffic flow FIFO 270 may also include some information to facilitate the subsequent forwarding processing of the packets. For example, each of the traffic flow FIFOs 271-27n may include a set of actions for packet processing, such as whether to perform policing, specific actions for editing the packet (such as deleting or modifying the packet header information), counting processing, enqueueing processing, etc.

[0043] The action execution module 240 receives the packets in each of the traffic flow FIFOs 271-27n, and performs corresponding forwarding processing such as policing, packet editing, counting, enqueueing, etc. on the packets according to the action instructions included in each of the FIFOs 271-27n, and then the processed packets can be output through the outport 250.

[0044] Since the traffic flow classification module 230 divides the packets in the physical port FIFO 260 with the finest granularity, this means that the forwarding behaviors of the packets in the same traffic flow FIFO are completely consistent, and there is no need to further distinguish the differences for different processing. Therefore, in one embodiment, the packets included in each traffic flow FIFO instance can be used as the granularity for batch forwarding processing of the packets included in the FIFO instance. For example, batch policing, batch counting, batch editing, batch enqueueing, etc. Batch processing means that as long as the information is obtained once, multiple packets can be processed simultaneously, which simplifies the CPU's computational workload and memory access volume, thereby improving the system performance.

[0045] The above has schematically described the structure and functions of the message processing apparatus 200. It should be noted that one or more of the logical interface determination module 220, the service flow classification module 230, and the action execution module 240 therein may be software modules or programs. When executed by a central processing unit (CPU), the module or program implements corresponding functions or actions. The forwarding process can be simplified through software, and the function expansion of the service model can also be easily realized. It can be understood that one or more of the above modules may also be implemented in the form of hardware, such as being implemented as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices. The present application does not make any limitations in this regard.

[0046] Figure 3 FIG. 300 shows an example process of a message processing method according to an exemplary embodiment of the present application, which may be executed, for example, by Figure 2 the message processing apparatus 200 shown. In one embodiment, the process 300 may be repeatedly executed to continuously process received messages.

[0047] As Figure 3 shown, the process 300 starts at step 302, where the message processing apparatus 200 receives a plurality of messages. For example, the message processing apparatus may receive messages from other communication devices through a network interface card (NIC). The received messages may be messages in various formats transmitted on the network, such as Ethernet frames, IP, TCP, UDP, etc. messages. In some embodiments, the message processing apparatus 200 may store the received messages in a queue or buffer. For example, the plurality of messages are stored in a FIFO queue in the order of reception. That is to say, the message processing apparatus 200 will perform subsequent processing in the order of message reception.

[0048] The message processing apparatus 200 may determine the logical interface corresponding to each received message. The logical interface may be used to identify or distinguish the service flow to which each message belongs. For example, in step 304, the message processing apparatus 200 first determines the characteristic information of each message, and then in step 306, the message processing apparatus 200 queries in the logical interface classification table based on the characteristic information to determine the logical interface corresponding to each message.

[0049] The characteristic information of the packet may be the physical port identifier (ID) for receiving the packet, and may also include packet-carrying fields such as the virtual local area network (VLAN) identifier of the packet, the protocol type of the packet (for example, Point-to-Point Protocol over Ethernet PPPoE, or Internet Protocol over Ethernet IPoE). Embodiments of the present application are not limited thereto. According to specific service configurations, other information that can identify or distinguish the service flow to which the packet belongs can also be used as the characteristic information of the packet, so as to facilitate finding the optimal service flow granularity that conforms to the service configuration. In one embodiment, for a packet in the FIFO queue, according to the physical port identifier for receiving the packet, the packet processing device 200 can obtain the corresponding configuration information or profile from a physical port instance table, and then based on the matching rules for extracting specific fields from the packet included in the configuration information or profile, extract the corresponding fields (VLAN ID, packet protocol type, etc.) of the packet, and combine the physical port identifier to determine the characteristic information of the packet.

[0050] In one embodiment, based on a specific service configuration, one or more classification tables can be used to perform one-level or multi-level matching on each received packet to find the corresponding logical interface of the packet. For example, when the service configuration model is relatively simple, the logical interface corresponding to the packet can be directly determined by performing one-level matching using the physical port identifier. When the service configuration model classifies the service flow at two or more levels, that is, the characteristic information includes one or more packet fields in addition to the physical port identifier, the logical interface corresponding to the packet can be determined by performing multi-level matching according to the characteristic information of the packet.

[0051] In one embodiment, the packet processing device 200 can determine the logical interface corresponding to the packet by means of hash indexing. For example, after obtaining the characteristic information of the packet, the packet processing device can construct the logical interface key of the packet according to the characteristic information, and then query in the logical interface classification table based on the key to determine the corresponding logical interface. For example, the characteristic information of the packet may include the physical port identifier (ID), the outer VLAN ID, and the inner VLAN ID. Based on this characteristic information, a key is constructed, the hash value of the characteristic information is calculated using a preset hash function, and a matching search is performed in a preset logical interface classification table to determine the logical interface corresponding to the characteristic information.

[0052] If the logical interface corresponding to the packet can be matched in the logical interface classification table based on the characteristic information of the packet, the packet processing device 200 can perform the next processing on the packet. On the other hand, if no logical interface is matched based on the characteristic information of the packet, it may be an illegal packet. In step 308, the packet processing device 200 can discard the packet.

[0053] After determining the logical interface of a message, the message processing device 200 can classify the message into a service flow FIFO queue for forwarding processing. For example, in step 310, the message processing device first constructs a service flow keyword key, and then in step 312, the message processing device 200 queries in the service flow classification table based on the service flow keyword to determine the service flow corresponding to each message.

[0054] For step 310, in an embodiment, based on the logical interface to which the message belongs, the message processing device 200 can obtain corresponding configuration information or a template (profile) from a logical interface instance table, and then based on the matching rules for extracting specific fields from the message included in the configuration information or template, extract the corresponding field content of the message, and construct the service flow keyword of the message based on these fields.

[0055] The matching rules for constructing the service flow keyword of the message can be associated with the configuration information of the logical interface to which the message belongs, or rather, the matching rules come from the specific configuration information on the corresponding logical interface. Since the service configuration on the logical interface determines the necessary granularity of the service flow (i.e., the constituent fields of the service flow keyword), in this way, flow table entries (entries) with precise granularity can be set for the service flow classification table.

[0056] In an embodiment, the configuration information of the logical interface may include information such as access control list ACL rules and the priority of the message. For example, when there is an L3 ACL rule in the configuration information of the logical interface, the L3 fields involved in the ACL rule need to be used as constituent elements of the service flow matching rules. If there is also a color mapping processing based on Pbit in the configuration information, then the Pbit field in the VLAN tag also needs to be part of the service flow matching rules.

[0057] In one embodiment, the constituent fields of the traffic key of a packet may include one or more of a Media Access Control (MAC) address, a Virtual Local Area Network identifier, an IP address, an L4 socket port number, and a priority indicator. Corresponding to the configuration of the logical interface to which the packet belongs, these fields are from the ingress port information of the packet, the L2-L4 fields of the packet that the ACL rules care about (such as the MAC address of L2, the VLAN identifier, the IP address of L3, the socket port number of L4, etc.), and the packet fields that other configurations on the logical interface care about, such as packet priority indicators like Differentiated Services Code Point (DSCP), Pbit, etc. Combining these fields forms the traffic key. If the values of the fields are different, the packets are classified into different traffic flows and have different forwarding processes. Compared with the fixed-granularity five-tuple or seven-tuple information used in the prior art, on the one hand, the embodiments of the present application save system resources by flexibly configuring the constituent fields of the key, and on the other hand, improve the packet processing performance by covering fields such as MAC address, VLAN ID, Pbit, etc. that meet the requirements of various functional services.

[0058] For step 312, the packet processing device 200 may sequentially query the packets in the physical port FIFO in the traffic classification table to determine the traffic flow corresponding to each packet. The traffic classification table may include at least one flow entry, and each flow entry includes a matching entry and a traffic flow identification entry. The traffic flow identification entry is used to indicate the traffic flow to which the packet belongs, and the matching entry integrates the packet information and / or fields used to uniquely identify the traffic flow. In one embodiment, the traffic classification table may be implemented as a hash table. A hash value is obtained by performing a hash calculation on the constructed traffic key using a preset hash function, and then the hash value is used to perform a single matching search in the traffic classification table to determine the corresponding traffic flow identification (for example, the address of the traffic flow FIFO instance), which improves the packet processing efficiency.

[0059] In one embodiment, based on the result found in the service flow classification table, the packet processing device 200 can perform different processing on the packets. If a flow table entry can be matched and hit in the service flow classification table based on the constructed service flow keyword, that is, the service flow to which the packet belongs can be determined, the process 300 can proceed to step 316, and the packet processing device 200 moves the packet into the corresponding service flow FIFO instance, for example, by moving the packet pointer to implement the packet moving operation. On the other hand, if no flow table entry is matched in the service flow classification table based on the constructed service flow keyword, then in step 314, the packet processing device 200 can perform traditional forwarding processing on the packet. For example, the packet processing device 200 performs one or more operations on the packet based on the open flow model to complete the forwarding. After processing the packet through the traditional process, if the packet meets the preset conditions for creating a service flow (i.e., it is not an illegal packet), the packet processing device 200 can create a flow table entry according to the information and related fields of the packet and add it to the service flow classification table, and at the same time, can also dynamically generate a service flow FIFO instance corresponding to the flow table entry. In this way, subsequent packets belonging to the same service flow as this packet can hit the created flow table entry and be moved into the corresponding service flow FIFO instance.

[0060] After step 316, the packet processing device 200 can move one or more packets corresponding to the same service flow among the received multiple packets into the corresponding service flow FIFO instance. Then, in step 318, the packet processing device 200 can perform forwarding processing on the packets in the service flow FIFO instance.

[0061] In one embodiment, in addition to including the pointer of the packet, each service flow FIFO instance can also include some information to facilitate the forwarding processing of the packet. For example, each service flow FIFO can include a set of packet processing actions, such as whether to perform policing processing, edit the packet, count processing, enqueue processing, etc. According to this information, the packet processing device 200 can perform corresponding processing on the packets in the service flow FIFO instance.

[0062] It should be noted that, except for the supervision process, most of the actions in the action set are final results and do not require further calculation. For example, since the fields related to the access control list (ACL) rules are already part of the business flow keyword key constructed in step 310. For instance, the ACL rule based on the destination MAC address at layer 2 implements discarding certain layer 2 protocol packets, or the ACL rule based on the destination IP address at layer 3 implements blocking certain IP network segments, or the ACL rule based on the port number at layer 4 implements blocking protocol port numbers such as the File Transfer Protocol (FTP) and the Dynamic Host Configuration Protocol (DHCP). Therefore, there is no need to perform relevant rule matching calculations anymore. For the supervision process, since its result depends on the dynamic traffic, that is, there may be different results according to the actual traffic situation. For this reason, the packets can be first subjected to the supervision process, and then divided into corresponding multiple sets according to the results. For example, divided into two sets based on whether the result of the supervision process is pass or drop, and then select the corresponding action set for further processing according to the result. As mentioned above, most of the actions in the action set at this time are final results and do not require further calculation.

[0063] In one embodiment, the packet processing device 200 can perform batch forwarding processing on the packets contained in each service flow FIFO instance in terms of all the packets. Since the received packets have been divided according to the granularity of matching the service configuration before, this means that the forwarding behaviors of the packets in the same service flow FIFO are consistent. Therefore, all the packets in a service flow FIFO queue can be processed as a whole in batch, and there is no need to further distinguish the differences for different processing. "Batch processing" means that as long as the information is obtained once, multiple packets can be processed simultaneously, which simplifies the CPU's calculation amount and memory access amount, thus improving the system performance.

[0064] In one embodiment, the packet processing device 200 can perform single supervision processing, counting processing, and enqueueing processing on all the packets contained in each service flow FIFO instance. For the supervision process, there can be various processing modes. For example, according to the dynamic traffic and the priority of the packets, the packet processing device 200 can perform pass / drop processing on the packets in the service flow FIFO instance, or perform coloring processing on the packets. For the counting processing, the number and length of all the packets in a service flow FIFO can be accumulated and counted. For the enqueueing processing, for example, Weighted Random Early Detection (WRED) or tail drop threshold processing can be performed.

[0065] Based on the foregoing description, the processing of packets is performed at the granularity of individual packets before entering the service flow FIFO, while the processing flow after entering the service flow FIFO can be a single batch processing at the granularity of all the packets contained in the FIFO queue. For example, a processing thread processes the packets in the physical port FIFO one by one, determines the service flow FIFO corresponding to each packet, and moves the packet into it. After all the packets in the physical port FIFO are processed, the thread starts to process the packets in each service flow FIFO. However, this time, it performs a batch processing with all the packets in a service flow FIFO queue as the unit granularity. For example, the packet processing device 200 takes all the packets in a service flow FIFO as a whole and performs a single supervision processing and counting processing. Since the resources for supervision and counting processing need to be protected for consistency among parallel threads, therefore, the embodiment of the present application can significantly reduce the overhead of consistency protection by using the batch processing method to forward packets.

[0066] For example, assume that two TCP sessions (TCP session) A and B are received on a certain logical port of the packet processing device 200, and their difference lies in the different destination IP addresses. The packets are sent into the port in an interleaved manner, that is, the packet processing device 200 receives these two TCP sessions in the order of A1, B1, A2, B2…, An, Bn, where session A includes packets A1, A2,…, An, and session B includes packets B1, B2,…, Bn. Based on the embodiment of the present application, the configuration of the logical interface may include, for example, an ACL rule for the destination IP address of L3. Then, the packet processing device classifies the packets into two FIFO queues based on this rule. For example, FIFO 1 contains packets A1, A2,…An, and FIFO 2 contains packets B1, B2,…, Bn. Furthermore, the packet processing device performs batch forwarding processing on all the packets in each FIFO queue as the granularity, thereby improving the packet processing performance.

[0067] Figure 4 Fig. shows a schematic functional block diagram of a packet processing device according to an exemplary embodiment of the present application. It will be understood that Figure 4 the functional blocks shown can be implemented by hardware, software, or a combination of hardware and software to perform the related operations described herein, and Figure 4 the functional blocks shown can be combined and integrated into one functional block, or divided into sub-blocks to implement the principles of the present application described above. Therefore, the description herein also supports feasible combinations, divisions, or further definitions of the respective functional blocks.

[0068] Refer to Figure 4, the message processing device 400 may include a receiving module 410, a first matching module 420, a second matching module 430, and a batch processing module 440. The receiving module 410 is configured to receive a plurality of messages, such as various types of network messages received from a network card.

[0069] The first matching module 420 may be configured to match the plurality of messages with a first classification table according to a first matching rule to determine a logical interface corresponding to the plurality of messages.

[0070] In some embodiments, matching the plurality of messages with a first classification table according to a first matching rule includes: performing multi-level matching on the plurality of messages using a plurality of first classification tables to determine a logical interface corresponding to the plurality of messages.

[0071] In some embodiments, matching the plurality of messages with a first classification table according to a first matching rule to determine a logical interface corresponding to the plurality of messages includes: obtaining feature information of the plurality of messages according to the first matching rule, constructing a first keyword according to the feature information, and querying in the first classification table based on the first keyword, so as to determine a logical interface corresponding to the first keyword.

[0072] In some embodiments, the feature information includes at least one of the following: an identifier of a physical port for receiving the message, a virtual local area network (VLAN) identifier of the message, or a protocol type of the message.

[0073] The second matching module 430 may be configured to match the plurality of messages with a second classification table according to a second matching rule to determine a service flow corresponding to the plurality of messages, wherein the second matching rule is associated with configuration information of the logical interface.

[0074] In some embodiments, the configuration information of the logical interface includes at least one of the following: an access control list (ACL) rule, or a priority of the message.

[0075] In some embodiments, matching the plurality of messages with a second classification table according to a second matching rule to determine a service flow corresponding to the plurality of messages includes: extracting corresponding field contents from the plurality of messages according to the second matching rule to construct a second keyword; and querying in the second classification table based on the second keyword to determine a service flow corresponding to the plurality of messages.

[0076] In some embodiments, the fields include a MAC address, a virtual local area network identifier, an IP address, an L4 socket port number, and a priority indicator.

[0077] In some embodiments, the second matching module 430 may also be configured to move one or more packets corresponding to the same traffic flow among the multiple packets into the corresponding FIFO instance.

[0078] The batch processing module 440 may be configured to perform batch forwarding processing on the packets included in the FIFO instance in terms of all the packets included in the FIFO instance.

[0079] In some embodiments, the batch forwarding processing includes: performing single supervision processing, counting processing, and enqueueing processing on the packets included in the FIFO instance.

[0080] Although not shown, the packet processing device 400 may further include other functional components or modules such as a cache scheduling module, a sending module, etc., to be used for implementing appropriate forwarding processing on the received packets.

[0081] Figure 5 The structural block diagram of a network device 500 according to an exemplary embodiment of the present application is shown. The network device 500 may be implemented as the packet processing device 200 described above. As Figure 5 shown, the network device 500 may include one or more processors 510, one or more memories 520, and one or more network interfaces 530, which may be communicatively connected to each other through a bus system 540.

[0082] The processor 510 may be, for example, a central processing unit (CPU), a general-purpose processor, a controller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The processor 510 may run the instructions in the memory 520 and / or exchange data therewith, so as to control other components coupled through the bus 540 to cooperate and perform the methods, steps, or functions described above.

[0083] The memory 520 may include various forms of storage media or be implemented using any suitable data storage technology, such as volatile and / or non-volatile memories. The volatile memory may include, but is not limited to, for example, random access memory (RAM), cache memory, etc. The non-volatile memory may include, but is not limited to, read-only memory (ROM), hard disk, flash memory, etc. The term "non-volatile" herein is relative to the definition of data storage persistency (e.g., RAM versus ROM) and is a definition of the medium itself (i.e., tangible rather than a signal). Additionally, at least one memory 520 may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, components, or any combination of the former.

[0084] The memory 520 may include computer instructions 522, which can be run by the processor 510 so that the processor 510 can control other components coupled through the bus 540 to operate cooperatively and execute the methods, steps or functions related to the message processing device 200 described above.

[0085] The network interface 530 may be a device with functions of receiving and sending network data, such as a receiving circuit, a receiver, an I / O interface, etc., for example, a port of a network card.

[0086] An embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. The computer program includes instructions that, when run by a processor, cause the message processing device to execute the processing methods, steps or functions described above.

[0087] An embodiment of the present application also provides a computer program product stored on the computer-readable storage medium described above. The computer program product can be written in any combination of one or more programming languages to write program code for performing the operations of the embodiments of the present application. The programming languages include object-oriented programming languages, such as Java, C++, etc., and also include conventional procedural programming languages, such as the "C" language or similar programming languages. The program code can be executed entirely on a local computing device, partially on a local computing device, executed as an independent software package, partially on a local computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0088] The computer-readable storage medium can adopt any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium. The readable storage medium can, for example, include but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0089] The basic principles of the present application have been described above in conjunction with the embodiments. However, it should be noted that the advantages, advantages, effects, etc. mentioned in the present application are only examples and not limitations. It cannot be considered that these advantages, advantages, effects, etc. are essential for each embodiment of the present application. In addition, the above-disclosed specific details are only for the purpose of illustration and easy understanding, and are not limitations. The above details do not limit the present application to necessarily adopt the above specific details to implement.

[0090] As used in this application, terms such as "component", "module", "system", etc. are used to denote computer-related hardware, software, firmware, dedicated circuits or logic, general hardware or controllers, or other computing devices, or some combination thereof.

[0091] "At least one of the following: <two or more listed elements>" and "at least one of <two or more listed elements>" and similar phrases in this application, where the two or more listed elements are joined by "and" or "or", mean at least any one of these elements, or at least any two or more of these elements, or at least all of these elements.

[0092] The block diagrams of devices, apparatuses, equipment, and systems involved in this application are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any way. Words such as "including", "comprising", "having", etc. are open-ended terms meaning "including but not limited to" and can be used interchangeably with each other. The word "or" and "and" used herein refer to the word "and / or" and can be used interchangeably with each other, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to" and can be used interchangeably with each other.

[0093] In the devices, equipment, and methods of this application, each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations shall be regarded as equivalent solutions of this application.

[0094] In addition, modifiers such as "first", "second", etc. throughout the specification and claims generally aim to distinguish different elements, operations, etc., rather than emphasizing any importance, specific order, specific priority, specific elements, etc.

[0095] Although some embodiments have been described, these embodiments have been presented by way of example and are not intended to limit the scope of the present application. In fact, the devices, methods, and systems described herein may be embodied in many other forms. Moreover, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the present application. For example, although the blocks are presented in a given arrangement, alternative embodiments may perform similar functions with different components and / or circuit topologies, and some blocks may be deleted, moved, added, subdivided, combined, and / or modified. At least one of these blocks may be implemented in a variety of different ways. The order of these blocks may also be changed. Any suitable combination of elements and actions of the above-described exemplary embodiments may be combined to provide other embodiments. The appended claims and their equivalents are intended to cover forms or modifications that will fall within the scope and spirit of the present application.

Claims

1. A method for processing packets, comprising: Receiving a plurality of packets; Matching the plurality of packets with a first classification table according to a first matching rule to determine a logical interface corresponding to the plurality of packets; And Matching the plurality of packets with a second classification table according to a second matching rule to determine a service flow corresponding to the plurality of packets, wherein the second matching rule is associated with configuration information of the logical interface.

2. The method according to claim 1, wherein Matching the plurality of packets with a first classification table according to a first matching rule includes: Using a plurality of first classification tables to perform multi-level matching on the plurality of packets to determine a logical interface corresponding to the plurality of packets.

3. The method according to claim 1 or 2, wherein Matching the plurality of packets with a first classification table according to a first matching rule to determine a logical interface corresponding to the plurality of packets includes: Obtaining feature information of the plurality of packets according to the first matching rule, constructing a first keyword according to the feature information, and querying in the first classification table based on the first keyword, so as to determine a logical interface corresponding to the first keyword.

4. The method according to claim 3, wherein, The feature information includes at least one of the following: an identifier of a physical port for receiving the packet, a virtual local area network (VLAN) identifier of the packet, or a protocol type of the packet.

5. The method according to any one of claims 1-4, wherein The configuration information of the logical interface includes at least one of the following: an access control list (ACL) rule, or a priority of the packet.

6. The method according to any one of claims 1-5, wherein, Matching the plurality of packets with a second classification table according to a second matching rule to determine a service flow corresponding to the plurality of packets includes: Extracting corresponding field contents from the plurality of packets according to the second matching rule to construct a second keyword; and Querying in the second classification table based on the second keyword to determine a service flow corresponding to the plurality of packets.

7. The method according to claim 6, wherein, The fields include a MAC address, a virtual local area network identifier, an IP address, a port number, and a priority indicator.

8. The method according to claim 6, further comprising: Moving one or more packets corresponding to the same service flow among the plurality of packets into a corresponding FIFO instance.

9. The method according to claim 8, further comprising: Performing batch forwarding processing on the packets included in the FIFO instance with all the packets included in the FIFO instance as a granularity.

10. The method according to claim 9, wherein The batch forwarding processing includes: Performing single supervision processing, counting processing, and enqueueing processing on the packets included in the FIFO instance.

11. A packet processing apparatus, comprising: At least one processor; And At least one memory storing instructions, which when executed by the at least one processor, cause the packet processing apparatus to at least perform: Receiving a plurality of packets; Matching the plurality of packets with a first classification table according to a first matching rule to determine a logical interface corresponding to the plurality of packets; And Matching the plurality of packets with a second classification table according to a second matching rule to determine a service flow corresponding to the plurality of packets, wherein the second matching rule is associated with configuration information of the logical interface.

12. The device according to claim 11, wherein, Matching the plurality of packets with a first classification table according to a first matching rule includes: Use multiple first classification tables to perform multi-level matching on the multiple packets to determine the logical interfaces corresponding to the multiple packets.

13. The device according to claim 11 or 12, wherein Matching the multiple packets with the first classification table according to the first matching rule to determine the logical interfaces corresponding to the multiple packets includes: Obtaining the feature information of the multiple packets according to the first matching rule, constructing a first keyword according to the feature information, and querying in the first classification table based on the first keyword, so as to determine the logical interface corresponding to the first keyword.

14. The apparatus according to claim 13, wherein The feature information includes at least one of the following: the identifier of the physical port for receiving the packet, the virtual local area network (VLAN) identifier of the packet, or the protocol type of the packet.

15. The apparatus according to any one of claims 11-14, wherein, The configuration information of the logical interface includes at least one of the following: access control list (ACL) rules, or the priority of the packet.

16. The device according to any one of claims 11-15, wherein, Matching the multiple packets with the second classification table according to the second matching rule to determine the service flows corresponding to the multiple packets includes: Extracting the corresponding field content from the multiple packets according to the second matching rule to construct a second keyword; and Querying in the second classification table based on the second keyword to determine the service flows corresponding to the multiple packets.

17. The apparatus according to claim 16, wherein, The fields include MAC address, virtual local area network identifier, IP address, port number, and priority indicator.

18. The apparatus according to claim 16, wherein, When the instruction is executed by the at least one processor, the packet processing device is further caused to perform: Moving one or more packets corresponding to the same service flow among the multiple packets into the corresponding FIFO instance.

19. The device according to claim 18, wherein, When the instruction is executed by the at least one processor, the packet processing device is further caused to perform: Taking all the packets included in the FIFO instance as a granularity, and performing batch forwarding processing on the packets included in the FIFO instance.

20. The device according to claim 19, wherein, The batch forwarding processing includes: Performing single supervision processing, counting processing, and enqueueing processing on the packets included in the FIFO instance.

21. A packet processing device, comprising: A receiving module, configured to receive multiple packets; A first matching module, configured to match the multiple packets with the first classification table according to the first matching rule to determine the logical interfaces corresponding to the multiple packets; And A second matching module, configured to match the multiple packets with the second classification table according to the second matching rule to determine the service flows corresponding to the multiple packets, wherein the second matching rule is associated with the configuration information of the logical interface.

22. A computer-readable medium, storing an instruction, which when run by at least one processor in a packet processing device, causes the packet processing device to execute the method according to any one of claims 1 to 10.

Images