CN112866139A

CN112866139A - Method, equipment and storage medium for realizing multi-rule flow classification

Info

Publication number: CN112866139A
Application number: CN201911183380.6A
Authority: CN
Inventors: 傅斌; 刘衡祁
Original assignee: Sanechips Technology Co Ltd
Current assignee: Sanechips Technology Co Ltd
Priority date: 2019-11-27
Filing date: 2019-11-27
Publication date: 2021-05-28
Also published as: WO2021104393A1

Abstract

The application provides a method, equipment and storage medium for realizing multi-rule flow classification. The method comprises the following steps: under the condition that the Hash HASH searching instruction is triggered, generating a corresponding original field according to a field to be extracted in original input information based on an original field structure; generating a corresponding intermediate field according to the original field and the table entry content in the system equipment table SDT configured in advance; searching at least one target field matched with the bit width of the field to be extracted and the width of the HASH table from a preset HASH bucket according to the intermediate field; and outputting the target field with the highest priority as an output result according to the priority order of at least one target field.

Description

Method, equipment and storage medium for realizing multi-rule flow classification

Technical Field

The present application relates to communications, and in particular, to a method, an apparatus, and a storage medium for implementing multi-rule flow classification.

Background

Gigabit-capable Passive Optical Networks (GPON) is a network technology with the most complete architecture and the most complete standard content in PON series technologies, and is now widely used in access Networks, and is an optimal scheme for replacing Asymmetric Digital Subscriber Line (ADSL) access technology. A GPON Network terminal equipment (Optical Network Unit, ONU) is one of the core chips of a GPON chipset. The detection and processing of ethernet messages of a chip are very important links, and various messages of different shapes and colors in a network need to be identified, and different processing modes are provided for different messages.

With the continuous enrichment of services, different messages have different processing modes, and the processing modes of the same message are different in different scenes. Therefore, it becomes very important to handle packet traffic using NP technology. Since microcode editors in Network Processor (NP) technology can be combined differently depending on the processing mode.

In the NP technology, the flow classification is currently mainly performed based on a Ternary Content Addressable Memory (TCAM); there is a benefit to using TCAMs: the characteristic fields to be extracted can be solidified for a specific scene.

There are several aspects to consider using TCAMs: one is that in a scenario for a GPON terminal, the number of required entries is very large, while the capacity of a TCAM is generally not large; secondly, the functions of the TCAM are many, the functions used by the ONU terminal are only a small part, which is a waste, and the cost is a sensitive factor from the point of view of not only purchasing IP but also area consumption; thirdly, there is a yield problem when TCAM is used. This also leads to a further increase in costs.

Before the NP structure, when the flow classification process is carried out, the TCAM is not used, at this time, at least 3 types of table lookup are needed for one rule of table lookup, the first type is a rule extraction index table, the second type is an extraction rule table, and the third type is HASH lookup. If the original table look-up flow is directly borrowed into the current NP framework, the table look-up times become very large because of the limitation of bit width returned by table look-up, the table look-up has time delay, the processing time of the thread inside the NP is prolonged due to the increase of the time delay, the performance is reduced in a phase-changing manner, and in order to improve the performance, more threads can be logically added to meet the application. However, this again leads to an increase in area, i.e. increased costs.

As can be seen from the above description, directly using TCAM under NP architecture is not a very ideal choice for GPON terminal application, and at the same time, using flow classification rules under non-NP architecture does not fit perfectly with NP architecture.

Disclosure of Invention

In view of this, embodiments of the present application provide a method, a device, and a storage medium for implementing multi-rule flow classification, so as to reduce the delay of table lookup for flow classification rules performed by an NP from the architecture and reduce the cost of a GPON terminal chip on the premise of ensuring flexible processing of service packets.

The embodiment of the application provides a method for realizing multi-rule flow classification, which comprises the following steps:

under the condition that the Hash HASH searching instruction is triggered, generating a corresponding original field according to a field to be extracted in original input information based on an original field structure;

generating a corresponding intermediate field according to the original field and the table entry content in the preset system equipment table SDT;

searching at least one target field matched with the bit width of the field to be extracted and the width of the HASH table from a preset HASH bucket according to the intermediate field;

and outputting the target field with the highest priority as an output result according to the priority order of the at least one target field.

An embodiment of the present application provides an apparatus, including: a memory, and one or more processors; device for cleaning the skin

A memory arranged to store one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method of any of the embodiments described above.

The embodiment of the application provides a storage medium, wherein a computer program is stored in the storage medium, and when being executed by a processor, the computer program realizes the method of any one of the above embodiments.

Drawings

Fig. 1 is a flowchart of an implementation method for multi-rule flow classification according to an embodiment of the present application;

FIG. 2 is a flow chart of flow classification provided by an embodiment of the present application;

FIG. 3 is a process flow diagram between pre-processing from HASH KEY to comparison of multiple HASH results in one of the streaming classifications provided by the embodiments herein;

fig. 4 is a schematic structural diagram of a HASH entry provided in an embodiment of the present application;

fig. 5 is a flowchart of an expansion port acquiring entry according to an embodiment of the present application;

fig. 6 is a schematic diagram of a HASH entry reconfigurable structure provided in an embodiment of the present application;

FIG. 7 is a block diagram of an apparatus for implementing multiple rule flow classification according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an apparatus provided in an embodiment of the present application.

Detailed Description

Hereinafter, embodiments of the present application will be described with reference to the drawings. In the present application, the embodiments and features of the embodiments may be arbitrarily combined with each other without conflict.

In the embodiment of the application, through deep analysis of the existing NP microcode characteristics and the flow classification flows, on one hand, TCAM is not used, and on the other hand, the current application needs to be satisfied, so that the problem of time delay of table lookup when GPON terminal application meets is solved.

In the existing flow classification process, the method comprises the following steps:

s1, the input information includes 128-byte header data, port number and other preprocessing information input by the former module.

S2, checking the extraction rule index table based on the port number to obtain the corresponding address of the extraction rule and the effective indication of each extraction rule.

S3, searching the extraction rule table based on each valid extraction rule index.

S4, extracting corresponding fields from the 128-byte packet header data based on the content obtained by the extraction rule table, and forming keys by some preprocessing information to perform HASH searching and matching operation. HASH matching is an exact match.

And S5, if all the rules are not matched, processing the message according to the 'all unmatched default actions' of the extraction rule index table, if one rule is matched and only one rule is matched, outputting the result according to the rule, and if a plurality of rules are effective, outputting the result with the highest priority according to the priority of the rule result.

If the rule lookup is performed once according to the existing flow classification process, the table lookup is as follows: one rule extraction index table, one rule extraction table, and one HASH lookup. While NP lookup once returns limited results, i.e. one rule lookup needs at least 3 times and the probability is more than 3 times.

According to the current application of the GPON terminal, the service message rule is more than 3 times common. Therefore, the rule lookup table is equivalent to at least 10 times, and the basic service processing of the two-layer message (i.e., L2) at least includes the learning and lookup of MAC addresses, packet modification, and other branch functions, so that the number of table lookup becomes very large.

Under the NP architecture, the linear speed is achieved by 64 bytes under the ideal condition, and the table look-up times are required to be as few as possible. Therefore, if the operation is performed according to the original flow under the NP architecture, the GPON terminal application is difficult to meet. The number of table lookups is excessive, each table lookup is analyzed in turn to consider whether it is optimizable or not and how it is, as mentioned above, the table lookup includes 3 types: and (4) extracting an index table, extracting a rule table and searching by HASH.

According to the function of the microcode in the existing NP framework, the data can be extracted by the microcode, and the purpose of searching the rule extraction index table and the rule extraction rule table is to extract the data. Therefore, the two types of tables can be optimized under the NP framework. The HASH lookup is then analyzed. As can be seen from the foregoing description, the solution for solving the flow classification function under the NP architecture is to use the TCAM, and then the usage of the TCAM in the GPON terminal product can be analyzed. TCAM applies two of its characteristics at GPON terminals:

firstly, each entry has an independent MASK bit inside the TCAM, the TCAM inputs KEY & & MASK to obtain the KEY really concerned by the entry, and the step completes the functions of the original rule extraction index and the rule extraction table. Entries and corresponding MASK bits of the TCAM can be dynamically added and deleted, i.e., the software can dynamically add rules and corresponding entries.

Secondly, the data after MASK is accurately matched with the entries, at this time, a plurality of entries are matched, the TCAM selects the matched entry with the highest priority as a final result according to different priorities of the entries, and corresponding information is output and fed back to the microcode. This step is analogous to an exact match lookup with HASH.

There is a MASK bit for each entry inside the TCAM. The TCAM can support a small number of entries, and can compare each entry. Pure logic, if it does, is equivalent to a TCAM. Therefore, this location needs to be analyzed according to the application scenario of the current ONU project, so as to satisfy the GPON terminal application as a passing criterion. And the output of the priority comparison result of the matching of the plurality of entries also belongs to the characteristics of the TCAM.

In an implementation manner, fig. 1 is a flowchart of an implementation method for multi-rule flow classification provided in an embodiment of the present application. The embodiment is applied to the condition of reducing the table look-up delay of the flow classification rule performed by the NP. The embodiment may be performed by a device, which may be an optical network terminal, for example.

As shown in fig. 1, the method in this embodiment includes S110-S140.

S110, under the condition that Hash (HASH) searching instruction triggering is detected, generating a corresponding original field according to a field to be extracted in original input information based on an original field structure.

In an embodiment, a HASH lookup instruction refers to an instruction for microcode to discover the flow of flow classes into a field lookup stage. In an embodiment, when microcode detects that the flow enters a field lookup stage, field splicing assembly is started to generate a corresponding original field.

In an embodiment, generating a corresponding original field according to a field to be extracted in original input information based on an original field structure includes: according to the original field structure, the address of the System Device Table (SDT) to be searched, the thread number of the current microcode and the field to be extracted in the original input information are combined to generate the corresponding original field. In an embodiment, the original field structure refers to the field structure used for lookup SDT table requests. That is, after the microcode composes the corresponding original field, a lookup SDT table request is initiated. Illustratively, the original field structure may include: a field to be extracted, an address of the SDT table to be searched and a thread number of the current microcode. In the embodiment, when entering the field search stage, the microcode assembles the field to be extracted, the address of the SDT table to be searched, and the thread number of the current microcode according to the original field structure to generate a corresponding original field. In an embodiment, the field to be fetched refers to the field that microcode is to fetch as needed.

S120, generating a corresponding intermediate field according to the original field and the table entry content in the pre-configured SDT table.

In an embodiment, the entry content of the SDT table may include: the system comprises a multiple HASH access flag bit, a HASH table id number flag bit, a HASH field size flag bit and a HASH table width flag bit. In the embodiment, after the microcode generates the original field according to the original field structure, a request for searching the SDT table is initiated, firstly, the SDT table is searched based on the address of the SDT table to be searched, the table entry content in the SDT table is read, and then the table entry content in the SDT table and the content in the original field are combined according to the pre-configured intermediate field structure to generate the corresponding intermediate field. Wherein, the intermediate field structure may include: the method comprises the steps of thread number of current microcode, multiple HASH access flag bits, HASH table id flag bits, HASH field size flag bits, HASH table width flag bits and fields to be extracted. After the microcode reads the corresponding table entry content from the SDT table, the table entry content, the thread number of the current microcode in the original field and the field to be extracted are assembled according to the intermediate field structure to generate the corresponding intermediate field.

S130, at least one target field matched with the bit width of the field to be extracted and the width of the HASH table is searched from the preset HASH bucket according to the intermediate field.

In an embodiment, the preset HASH bucket refers to a pre-configured space storing various fields. The preset HASH bucket may be used to store various fields corresponding to various field widths, different types, and different HASH table widths, which is not limited herein. In an embodiment, the field to be extracted has its own attributes, such as its own bit width and the width of the HASH table to which it belongs. After the intermediate field is obtained, the preset HASH bucket can be searched according to the bit width of the field to be extracted in the intermediate field and the HASH table width, so as to obtain at least one target field matched with the bit width of the field to be extracted and the HASH table width. In the embodiment, the preset HASH bucket is configured in advance, that is, the search of the rule extraction index and the related operation of the extraction rule are not required to be executed according to the field to be extracted, so that the table search delay of the flow classification rule is greatly reduced.

And S140, outputting the target field with the highest priority as an output result according to the priority order of at least one target field.

In the embodiment, the target field with the highest priority is output as an output result according to the priority ranking of at least one target field, which means that the result with the highest priority is selected according to the agreed priority ranking to be output under the condition that a plurality of rules take effect simultaneously and need to be matched. On the premise of ensuring flexible processing of service messages, the time delay of the NP for performing table look-up of the flow classification rules is reduced from the framework, and meanwhile, the cost of a GPON terminal chip is reduced.

In an embodiment, generating a corresponding intermediate field according to the original field and the entry content in the preconfigured system device table SDT includes: reading a pre-configured SDT table according to the address of the SDT table to be searched in the original field to obtain corresponding table item content; and combining the table entry content, the thread number of the current microcode in the original field and the field to be extracted based on the intermediate field structure to generate a corresponding intermediate field.

In the embodiment, the microcode searches the SDT table based on the address of the SDT table to be searched in the original field, and reads the content of each table item in the SDT table after the corresponding SDT table is searched; and then combining the content of each table entry in the SDT table, the thread number of the current microcode in the original field and the field to be extracted according to the intermediate field structure to generate a corresponding intermediate field.

In an embodiment, before searching at least one target field matching the bit width of the field to be extracted and the HASH table width from the preset HASH bucket according to the intermediate field, the method further includes: determining a corresponding HASH search strategy according to a multiple HASH flag bit in the intermediate field, wherein the multiple HASH flag bit is used for indicating the number of HASH rules of the current multiple HASH search request.

In an embodiment, the corresponding HASH lookup policy may be determined from the multiple HASH flag bits in the intermediate field. That is, the HASH lookup strategy is associated with multiple HASH flags. In an embodiment, the HASH lookup policy may include: single HASH lookup strategies and multiple HASH lookup strategies. The single HASH searching strategy is used for representing the flow classification process to be processed through a single HASH path; the multiple HASH lookup strategy is used for characterizing the flow classification process to process through the multiple HASH pathway.

In one embodiment, in the case that the multiple HASH flag bit is the first value, finding at least one target field matching the bit width of the field to be extracted and the HASH table width from the preset HASH bucket according to the intermediate field includes: based on the multiple HASH search strategy, searching a corresponding multiple HASH rule index table according to the HASH table id number in the intermediate field; determining field bit width and HASH table width corresponding to the target field according to HASH table id numbers in the multiple HASH rule index table; and generating at least one corresponding target field according to the field bit width and the width of the HASH table.

In an embodiment, the multiple HASH flag bit may be represented by a first value and a second value. Illustratively, the first value is 1 and the second value is 0. In the embodiment, under the condition that the multiple HASH flag bit is 1, it is indicated that the flow classification process performs multiple HASH lookups, that is, a corresponding target field is determined by using a multiple HASH lookup policy, that is, a first HASH lookup is performed by using the multiple HASH lookup policy, a corresponding multiple HASH rule index table is looked up based on a HASH table id number in the middle field, and then a field bit width and a HASH table width corresponding to the target field are looked up from a preset mapping table according to the HASH table id number in the multiple HASH rule index table; and then replacing the field bit width and the HASH table width of the field to be extracted with the field bit width and the HASH table width corresponding to the target field to obtain at least one corresponding target field. After the first HASH search is completed, the rule index number is reduced by one, and then the single HASH search strategy is executed again until the rule index number is reduced to 0.

In one embodiment, outputting the target field with the highest priority as an output result according to the priority order of at least one target field includes: determining the priority order of each target field; and outputting the target field with the highest priority as an output result.

In an embodiment, after finding a plurality of target fields from the HASH bucket, the priority of each target field is sorted, and the target field with the highest priority is output as an output result. In an embodiment, the priority of the target field is sorted, which may refer to a case where there are multiple rules that are active at the same time and need to be matched, and each rule is sorted by priority.

In an embodiment, the method for implementing multi-rule flow classification further includes: the original input information and at least one output result are stored in a manner of an idle pointer queue and a Random Access Memory (RAM).

In an embodiment, when the output result obtained by executing the multiple HASH lookup policy is stored, the output result can be stored in a manner of combining the free pointer queue and the RAM. In one embodiment, the RAM depth is related to the total number of threads. In an embodiment, the RAM depth may be set to N, which depends on the total number of threads. In the embodiment, in the storing process, the original input information may be stored, or the N output results may also be stored, which is not limited.

In an embodiment, fig. 2 is a schematic flow chart of flow classification provided in an embodiment of the present application. As shown in fig. 2, the flow classification process includes the following steps:

s210, extracting HASH KEY.

S220, preprocessing HASH KEY.

S230, searching the HASH bucket.

And S240, comparing multiple HASH results.

And S250, outputting the result.

In an embodiment, HASH KEY refers to the fields in the above embodiments. In an embodiment, the process of extracting HASH KEY comprises: and under the condition of initializing the flow classification processing flow, using a microcode command to perform KEY combination according to application requirements.

The HASH KEY pretreatment process comprises the following steps: an SDT table is customized, various HASH input conditions can be flexibly dealt with, and HASH KEY can be flexibly reprocessed according to different input conditions. In the embodiment, different HASH table widths, different HASH KEY widths and different result bit widths are defined according to application requirements, so that the condition of multi-rule arbitration of flow classification is met.

The process of finding the HASH bucket includes: the HASH KEY preprocessing part is corresponding to the HASH KEY in the HASH KEY preprocessing part, can flexibly match different HASH KEY bit widths, flexibly match according to different HASH table widths, and output the matched corresponding result.

The process of multiple HASH result comparison includes: and under the condition that a plurality of rules are effective at the same time and need to be matched, selecting the result with the highest priority according to a preset priority order and outputting the result.

In one embodiment, fig. 3 is a flow chart of the process between preprocessing from HASH KEY to comparison of multiple HASH results in a sort of fraction provided in the embodiments of the present application. As shown in fig. 3, the process flow includes the following steps:

s310, the microcode detects that the flow classification flow enters a HASH KEY extraction stage to extract the KEY.

S320, the microcode carries out KEY assembly to generate an original field.

S330, after the microcode forms the original field, the table lookup request is initiated, and the SDT table is searched.

S340, after the SDT table is read, combining the table entry content and the original field in the SDT table to generate an intermediate field.

And S350, under the condition that the multiple HASH zone bit in the middle field is 1, performing multiple HASH searching.

S360, performing a first HASH search, searching a table inside the ALG based on the HASH table id number in the KEY, and replacing the HASH KEY in the original field with the search result.

And S370, executing the HASH search for the second time until the last time, and using the HASH table id number plus 1 in the HASH KEY as an index lookup table, and replacing the HASH KEY in the original field with the search result.

And S380, storing the search result in a mode of combining the idle pointer queue and the RAM.

And S390, after the HASH KEY is assembled, sending the HASH KEY into the original ALG functional module for processing.

In an embodiment, the microcode detects that the flow classification flow enters the HASH KEY extraction stage and starts to splice. First, microcode performs HASH KEY assembly according to the original field structure to generate the corresponding original field. Table 1 is a schematic table of an original field structure provided in an embodiment of the present application. As shown in table 1, the original field structure includes: a field to be extracted, an address of the SDT table to be searched and a thread number of the current microcode.

TABLE 1A schematic diagram of the original field structure

Address of SDT table to be searched

Thread number of current microcode

Field to be extracted

In an embodiment, HASH KEY may be used to represent a field that microcode needs to extract, i.e., a field to be extracted; SDT _ num represents the address of the SDT table to be looked up; np _ no represents the thread number of the current microcode.

In microcode generation raw field vomit prevention, a table lookup request is initiated, first to lookup the SDT table based on SDT _ num. Table 2 is a structural schematic table of an SDT table provided in the embodiment of the present application.

TABLE 2 structural schematic table of SDT table

In an embodiment, the multiple HASH flag bits may be represented using a multi _ HASH; multi _ table _ id represents a HASH table number; HASH _ KEY _ size represents HASH KEY size flag bit; multi _ tbl _ width indicates the HASH table width flag bit.

Illustratively, where the multi _ HASH is 0, this indicates the key length of the access HASH module, and the HASH key value is 384 bits in total. For example, the HASH _ key is a minimum granularity supported by 128 bits and is 1byte, the value range of key is 1-14, and the HASH key value length (in 8 bits) is respectively: 000001-1 × 8bit, 000010-2 × 8bit, 001110-14 × 8bit, and the rest conditions are reserved; the HASH _ key is 256 bits supported minimum granularity of 2 bytes, the value range of key is 1-15, and the HASH key value length (taking 16 bits as a unit) is respectively as follows: 000001-1 × 16bit, 000010-2 × 16bit, 001111-15 × 16bit, and others; the HASH _ key is 384 bits supported with the minimum granularity of 4 bytes, the key size has a value range of 1-12, and the HASH key value length (in 32 bits) is respectively: 000001-1 × 32bit, 000010-2 × 32bit, 001100-12 × 32bit, and others; the HASH _ key is 512 bits supported minimum granularity of 4 bytes, the value range of key is 1-12, and the HASH key value length (in 32 bits) is respectively: 000001-1 x 32bit, 000010-2 x 32bit, 001100-12 x 32bit, others are retained. In an embodiment, multi _ tbl _ width represents a HASH table width flag bit for storing bit width. The key type is 2bit, which represents the length type of the HASH table entry corresponding to the lookup: 01-128 bits, 10-256 bits, 11-512 bits, 00-384 bits.

After reading the SDT table, assembling the content of each entry in the SDT table and the HASH KEY to generate a corresponding intermediate field. Table 3 is a schematic table of an intermediate field structure provided in an embodiment of the present application. As shown in table 3, the intermediate field structure includes: the thread number, multiple HASH flag bits, HASH table number, HASH KEY size flag bit, HASH table width flag bit and field to be extracted of the current microcode.

TABLE 3 schematic diagram of a middle field structure

np_no
	multi_hash
multi_table_id
	hash_key_size
multi_tbl_width
	HASH KEY

In the HASH processing process, the preprocessing module is used for shunting in advance, and under the condition that the multi _ HASH in the middle field is 0, a basic HASH path (namely a single HASH searching strategy) is executed, but 8bit information is newly added at a high bit, namely 1bit multi HASH +7bit multi HASH index; in the case that the multi HASH in the middle field is 1, it indicates that multiple hashes are required to be performed, and multiple HASH paths are executed (i.e., multiple HASH lookup strategy).

If the multiple HASH paths are used for the first HASH search, a table inside the ALG is searched based on the HASH _ table _ id in the middle field. Table 4 is an index table of multiple HASH rules provided in the embodiment of the present application.

Table 4 a multi-HASH rule index table

Table 5 is a hash _ table _ id configuration table provided in this embodiment of the present application. As shown in table 5, includes: HASH table width, HASH KEY size, and HASH KEY position.

Table 5 a hash _ table _ id configuration table

And sequentially replacing the hash _ key _ size and the hash _ key _ type in the original key with the hash _ table _ id, the hash _ key _ size and the hash _ table _ width obtained by searching the SDT table. The HASH KEY is generated again according to the HASH _ KEY _ size, HASH _ KEY _ location and HASH _ KEY _ mask obtained by table lookup, and the specific meaning of the parameters is as shown in the above table, for example, when the HASH _ KEY _ size is set to 64 bits and the HASH _ KEY _ location is set to 5, the HASH _ KEY (504 bits) is {320 'b 0, (HASH _ KEY [383:320] & HASH _ KEY _ mask [63:0], 120' b0 }.

In the case of performing HASH lookup for the second time until the last time, look up table 4 as an index based on HASH _ mul _ next _ addr of table 4, and the other procedures are the same as S350. After each HASH check, the multi _ num read in table 4 is decremented by one, and when the increment of 0 indicates that the currently processed multi-HASH _ key has been applied, the next multi-HASH _ key application is started.

On the other hand, for the key with the multi _ hash being pulled up, the preprocessing module needs to store the key because the key does not return the result immediately, the storage adopts a mode of a free pointer queue + RAM, and the RAM depth is set to be N (N depends on the total number of the threads). The storage is not only the original input signal but also the N output results (bit width is determined by the application, where the most significant bit is hit). In an embodiment, the next highest 5 bits of the output result are used as priority arbitration. (in HASH table entry is the highest 5bit next to key, after all results have been read, the result corresponding to the highest priority is taken) also needs a pending pointer FIFO (i.e. stored is multi _ index). First-in first-out principle is adopted among the N KEY, and one KEY is copied to the next KEY after being copied.

The number of copies is based on the corresponding multi _ num parameter in table 4, which is decremented by one each time a copy is made, until it is decremented to 0, indicating the end of the copy, and the next copy is started. After the keys are assembled, the keys are sent to the basic HASH function modules, the dispatching between the keys of the multiple HASH and the keys of the original path exists, an RR polling mode is adopted at present, the keys and the keys have the same priority, and after the basic HASH function modules are searched, the related parameters corresponding to the output result are returned. By adopting the technical scheme, the method can be matched with the solidification part of the microcode to fix the extraction field, more importantly, the time delay of the flow classification function table look-up of the ONU when the service type is complicated is greatly reduced, and the HASH look-up scheme which can be flexibly matched with the microcode, particularly a reconfigurable HASH item structure is designed, so that the utilization rate of the RAM is improved, the thread number of the NP is reduced, and the chip cost is reduced.

Fig. 4 is a schematic structural diagram of a HASH entry provided in an embodiment of the present application. As shown in fig. 4, the HASH entry structure includes: an entry valid flag bit (i.e., valid), a key type flag bit (key _ type), a HASH table id (i.e., table _ id), a service key value (i.e., key), and an output result (i.e., result).

In an embodiment, it may be defined that when valid is 0, the current entry is an invalid HASH entry; when vaild is 1, the current entry is valid. key _ type is defined as follows: when 00, it is invalid; 01, 128 bit; at 10, 256 bits; at 11, 512 bits. table _ id is defined as follows: 0-31, 32 HASH tables are shown. key represents the user-defined service key value, the length must be n × 8bit (n is 1,2,3 … … 48), the maximum service key value length is 384bit, and n is between [0:48 ]. result is user-defined result data, and no _ result bit with the highest 1bit is reserved for the chip hardware to indicate whether microcode has hit (for example, 0 indicates hit, and 1 indicates miss). The length of the result actually returned to the microcode is determined by rsp _ mode in the SDT attribute, when the length of the result actually stored in the entry is larger than rsp _ mode, the data is intercepted when the result is returned to the microcode, otherwise, the low bit of the result is filled to the rsp _ mode bit width by adopting 0.

In an embodiment, the flow of multi-rule flow classification is described by taking the case of performing two HASH lookups. Fig. 5 is a flowchart of an expansion port acquiring entry according to an embodiment of the present application. As shown in fig. 5, the process includes the following steps:

and S410, HASH request input.

S420, the HASH request intercepts a valid KEY based on the HASH table width or HASH KEY size, and performs HASH calculation with the HASH table id number.

S430, HASH request based on HASH table width or HASH KEY size to intercept the valid KEY, and HASH table id number and HASH calculation.

S440, after the HASH address is calculated, reading Nbit data from the HASH bucket.

S450, under the condition that the matched entry exists, obtaining the position of the result in the entry according to the bit width of the entry.

Fig. 6 is a schematic structural diagram of a HASH entry reconfigurable structure provided in an embodiment of the present application. In an embodiment, when the HASH request is input, the method may include: np _ no, multi _ hash _ index, multi _ hash, multi _ table _ id, hash _ key _ size, and multi _ tbl _ width. Then, the HASH request intercepts a valid key based on multi _ tbl _ width or HASH _ key _ size, then adds multi _ table _ id to perform a HASH calculation, and performs the step of the HASH calculation twice. And then, after the hash address is obtained through hash calculation, Nbit data are read from the hash bucket. Illustratively, taking 512 as an example, the hash matching entry takes 128bit as an example, and determines whether [510:509] bit is a 128bit value, if so, matches [511:384] with the requested 128bit, and determines whether [382:381] is a 128bit value. If yes, the requested 128bit is matched with [383:256], and the like, the requested 128bit is matched with [255:128], [127:0], and the reconfigurable structure is shown in FIG. 6.

In an embodiment, taking the ACL rule of the configured layer 3 message (i.e., L3) as an example, the implementation process of the multiple rule flow classification is described.

For the L3 message, it may include: 7-tuple, 6-tuple, 5-tuple, etc. In the embodiment, the implementation process of the multi-rule flow classification is described by taking a 7-tuple as an example. When the KEY is extracted, all the parameters of the 7 tuples are extracted and spliced into the KEY (namely the original field), and the KEY bit width is between 64 and 128. The software is pre-configured with sdt _ num corresponding to the multiple hash rules; then, a sdt table corresponding to sdt _ num is configured, and the parameters are sequentially described as follows: multi _ hash: set to 1, indicating that multiple hash lookup is enabled; hash table width: it is not meaningful herein; multi _ hash _ addr: (i.e., original Hash key size + Hash table id) here represents the first address of the multi-Hash lookup. In one implementation, the reservation is performed according to the current usage, for example, the first address is configured as 0 and the first address of the next multi-hash is set as 8 after 8 multi-hash lookups are performed first, which may be wasteful. If the software is convenient to implement, the value is configured as the used value of the multiple hash rule index table according to how many times the multiple hash rule index table is used currently, for example, the value is configured as 0 when the multiple hash rule index table is not used at first, and the parameter is set to be 1 when the multiple hash rule index table is configured for the second time, namely, the position of the next free pointer is set.

Then, a multi-HASH rule index table is configured, and the first address is multi _ HASH _ addr. In the multiple HASH rule index table, multi _ num: as shown in table 4, the parameter is configured to be 1 only if the first address is valid, for example, only one 7-tuple search is currently performed, and the parameter needs to be modified to be 2 if a new triplet search is subsequently added.

hash _ id: the hash _ id and the hash _ table _ id are configured together and correspond to a real service table number, for example, a current 7-tuple service, and if the 7-tuple service is set by other ports and the current extraction condition is completely the same, the currently set hash _ id and hash _ table _ id are matched with the previous hash _ id and hash _ table _ id, so that the service table number is saved; hash _ table _ id: the same as above; hash _ mul _ next _ addr: if the value of the number of remaining copies needed is greater than 1, then the hash _ mul _ next _ addr has significance, and this parameter is similar to the concept of the configuration of the multi _ hash _ addr in the sdt table, and can be implemented in the following two configurations. One implementation is as follows: a reservation and increment method, which is used in this implementation manner to indicate that N positions (N is less than or equal to 8) are directly reserved after multi _ hash _ addr is used each time, where the hash _ mul _ next _ addr is multi _ hash _ addr + current copy number-1, for example, if a triple rule is added, the current copy number is 2 (originally, only a 7-tuple rule is used), and the hash _ mul _ next _ addr is multi _ hash _ addr + 2-1; one implementation is as follows: and in the idle pointer method, when the implementation mode is adopted, software records the address of the minimum number of the currently unused multi-hash rule index table. For example, if all are unused initially, then the free pointer is 0, if used once, the free pointer is 1 for the second use, and so on.

Then, a hash _ table _ id configuration table is configured. In the embodiment, the hash _ table _ width corresponds to an expected bit width of the table entry, for example, the current key length is 64 to 128, and the result is obtained by cascade connection, where the parameter is configured to be 01, that is, 128 bits;

hash _ key _ size: representing that the current key length is 64-128, the value is 0 when the key length is 128bit wide, and if the key length is 64bit, the value is 8;

hash _ key _ location: if the current total bit width only uses less than 128 bits and the key bit width is also 128 bits, 0 is selected, and other more values are shown in table 5;

hash _ key _ mask: if the current overall bit width is less than 128 bits and the key bit width is also 128 bits, then the mask bit is valid as 127:0, and the actual truncation is performed according to the bit width of the current actual 7-tuple, for example, the 7-tuple uses 90 bits lower, then the mask 89:0 is configured as 1, and the 127:90 is configured as 0.

In one embodiment, in the case of current ONU operation, a 128-bit entry has been configured in the bit width of the 512-bit RAM, occupying 511:384 bits, and when the new entry has been set to the same address, a second 128-bit entry is configured, occupying 383:256 bits. When there is another entry HASH to the same address and 256 bits are needed, this may be configured at [255:0 ].

Fig. 7 is a block diagram of an apparatus for implementing multi-rule flow classification according to an embodiment of the present application. The embodiment is applied to the condition of reducing the table look-up delay of the flow classification rule performed by the NP. As shown in fig. 7, the apparatus in the present embodiment includes: a first generation module 510, a second generation module 520, a lookup module 530, and an output module 540.

The first generating module 510 is configured to, when the HASH search instruction is detected to trigger, generate a corresponding original field according to a field to be extracted in original input information based on an original field structure;

a second generating module 520, configured to generate a corresponding intermediate field according to the original field and the table entry content in the system device table SDT configured in advance;

the searching module 530 is configured to search at least one target field matched with the bit width of the field to be extracted and the width of the HASH table from the preset HASH bucket according to the intermediate field;

and the output module 540 is configured to output the target field with the highest priority as an output result according to the priority order of at least one target field.

The apparatus for implementing multiple rule flow classification provided in this embodiment is configured to implement the method for implementing multiple rule flow classification in the embodiment shown in fig. 1, and the implementation principle and technical effect of the apparatus for implementing multiple rule flow classification provided in this embodiment are similar, and are not described herein again.

In an embodiment, the first generating module is configured to combine, according to an original field structure, an address of the SDT table to be searched, a thread number of the current microcode, and a field to be extracted in the original input information, and generate a corresponding original field.

In one embodiment, the second generating module includes:

the reading unit is set to read a pre-configured SDT table according to the address of the SDT table to be searched in the original field to obtain the corresponding table item content;

and the first generating unit is set to combine the table entry content, the thread number of the current microcode in the original field and the field to be extracted based on the intermediate field structure to generate a corresponding intermediate field.

In an embodiment, the apparatus for implementing multi-rule flow classification further includes:

the determining module is configured to, before searching for at least one target field matching the bit width of the field to be extracted and the HASH table width from the preset HASH bucket according to the intermediate field, further include: determining a corresponding HASH search strategy according to a multiple HASH flag bit in the intermediate field, wherein the multiple HASH flag bit is used for indicating the number of HASH rules of the current multiple HASH search request.

In one embodiment, in the case that the multiple HASH flag bit is the first value, the lookup module includes:

the searching unit is set to search the strategy based on the multiple HASH and search the corresponding multiple HASH rule index table according to the HASH table id number in the middle field;

the first determining unit is set to determine the field bit width and the HASH table width corresponding to the target field according to the HASH table id number in the multiple HASH rule index table;

and the second generating unit is set to generate at least one corresponding target field according to the field bit width and the HASH table width.

In one embodiment, an output module includes:

a second determining unit arranged to determine a priority order of each target field;

and the output unit is set to output the target field with the highest priority as an output result.

and the storage module is set to store the original input information and at least one output result in a mode of adopting an idle pointer queue and an RAM (random access memory).

In one embodiment, the RAM depth is related to the total number of threads.

Fig. 8 is a schematic structural diagram of an apparatus provided in an embodiment of the present application. As shown in fig. 8, the present application provides an apparatus comprising: a processor 610 and a memory 620. The number of the processors 610 in the device may be one or more, and one processor 610 is taken as an example in fig. 8. The number of the memories 620 in the device may be one or more, and one memory 620 is taken as an example in fig. 8. The processor 610 and the memory 620 of the device are connected by a bus or other means, as exemplified by the bus connection in fig. 8. In this embodiment, the device is an optical network terminal.

The memory 620, as a computer-readable storage medium, may be configured to store software programs, computer-executable programs, and modules, such as program instructions/modules corresponding to the apparatuses of any embodiment of the present application (e.g., the first generation module, the second generation module, the search module, and the output module in the implementation apparatus of multiple rule flow classification). The memory 620 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to use of the device, and the like. Further, the memory 620 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some examples, the memory 620 can further include memory located remotely from the processor 610, which can be connected to the device over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The device provided above may be configured to execute the implementation method for multi-rule flow classification provided in any of the above embodiments, and has corresponding functions and effects.

Embodiments of the present application also provide a storage medium containing computer-executable instructions, which when executed by a computer processor, are configured to perform a method for implementing multiple rule flow classification, the method including: under the condition that the Hash HASH searching instruction is triggered, generating a corresponding original field according to a field to be extracted in original input information based on an original field structure; generating a corresponding intermediate field according to the original field and the table entry content in the system equipment table SDT configured in advance; searching at least one target field matched with the bit width of the field to be extracted and the width of the HASH table from a preset HASH bucket according to the intermediate field; and outputting the target field with the highest priority as an output result according to the priority order of at least one target field.

It will be clear to a person skilled in the art that the term user equipment covers any suitable type of wireless user equipment, such as mobile phones, portable data processing devices, portable web browsers or vehicle-mounted mobile stations.

In general, the various embodiments of the application may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the application is not limited thereto.

Embodiments of the application may be implemented by a data processor of a mobile device executing computer program instructions, for example in a processor entity, or by hardware, or by a combination of software and hardware. The computer program instructions may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages.

Any logic flow block diagrams in the figures of this application may represent program steps, or may represent interconnected logic circuits, modules, and functions, or may represent a combination of program steps and logic circuits, modules, and functions. The computer program may be stored on a memory. The Memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as, but not limited to, Read-Only Memory (ROM), Random Access Memory (RAM), optical storage devices and systems (Digital Video Disc (DVD) or Compact Disc (CD)), etc. The computer readable medium may include a non-transitory storage medium. The data processor may be of any type suitable to the local technical environment, such as but not limited to general purpose computers, special purpose computers, microprocessors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Programmable logic devices (FGPAs), and processors based on a multi-core processor architecture.

Claims

1. A method for implementing multi-rule flow classification is characterized by comprising the following steps:

2. The method according to claim 1, wherein the generating a corresponding original field according to a field to be extracted in original input information based on an original field structure comprises:

and combining the address of the SDT table to be searched, the thread number of the current microcode and the field to be extracted in the original input information according to the original field structure to generate a corresponding original field.

3. The method of claim 1, wherein generating corresponding intermediate fields according to the original fields and table entry contents in a preconfigured System Device Table (SDT) comprises:

reading a pre-configured SDT table according to the address of the SDT table to be searched in the original field to obtain corresponding table item content;

and combining the table entry content, the thread number of the current microcode in the original field and the field to be extracted based on an intermediate field structure to generate a corresponding intermediate field.

4. The method of claim 1, further comprising, before said finding at least one target field matching a bit width of the field to be extracted and a HASH table width from a preset HASH bucket according to the intermediate field:

and determining a corresponding HASH searching strategy according to the multiple HASH flag bits in the intermediate field, wherein the multiple HASH flag bits are used for indicating the number of HASH rules of the current multiple HASH searching request.

5. The method of claim 4, wherein in case the multiple HASH flag bit is a first value, said finding at least one target field from a preset HASH bucket according to the intermediate field that matches a bit width and a HASH table width of the field to be extracted comprises:

based on a multi-HASH searching strategy, searching a corresponding multi-HASH rule index table according to the HASH table id number in the intermediate field;

determining field bit width and HASH table width corresponding to a target field according to HASH table id numbers in the multiple HASH rule index table;

and generating at least one corresponding target field according to the field bit width and the width of the HASH table.

6. The method of claim 1, wherein outputting the target field with the highest priority as an output result according to the priority order of the at least one target field comprises:

determining the priority order of each target field;

and outputting the target field with the highest priority as an output result.

7. The method according to any one of claims 1-6, further comprising:

and storing the original input information and at least one output result by adopting a mode of an idle pointer queue and a Random Access Memory (RAM).

8. The method of claim 7, wherein the RAM depth is related to a total number of threads.

9. An apparatus, comprising: a memory, and one or more processors;

a memory arranged to store one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-8.

10. A storage medium, characterized in that the storage medium stores a computer program which, when executed by a processor, implements the method of any one of claims 1-8.