CN117880208A - Speed limiting method for realizing lock-free speed limiting by multi-core dynamic speed adjustment - Google Patents

Abstract

The invention belongs to the technical field of data communication, and discloses a speed limiting method for realizing lock-free speed regulation by dynamically adjusting speed of a plurality of cores, which comprises the following steps: s01, designing a speed limit example data structure; generating a hash table item by using i p as a key to make a hash; s02, designing a business core speed limit processing flow; distributing a global speed limit token to each service core so that each service core is independent speed limit configuration; s03, designing a speed regulation nuclear speed regulation flow; and (3) independently taking one core for speed regulation, traversing all service instances, and calculating to obtain the independent token bucket rate of each core. The invention distributes the global token bucket rate of the service instance to the unique token bucket rate of each core through the single speed regulating core and the flow percentage of each core, thereby realizing the effect that the multi-core service speed limit is not locked and the service core and the performance are both increased linearly.

Description

Speed limiting method for realizing lock-free speed limiting by multi-core dynamic speed adjustment

Technical Field

The invention belongs to the technical field of data communication, and particularly relates to a speed limiting method for realizing lock-free speed regulation by multi-core dynamic speed regulation.

Background

With the growth of cloud service, the traffic of the service on the resource pool is larger and larger, and the service pressure of the virtual network element is larger and larger; the capacity of the network element needs to be expanded or the performance specification of the network element needs to be increased, and additional service cores need to be added; however, as the number of service cores increases, the performance of the service cannot increase linearly and may even decrease. The reason is that traffic is concurrent to multiple cores, resulting in reduced speed-limiting locking performance.

The common speed limiting method in the virtual network element is a token bucket, and the service is multi-core, the token bucket needs to be global, locking is needed under the condition of multi-core, the locking affects the performance under the condition of multi-core, and the performance is worse or even lower when the number of cores is larger, so that the service is affected, and therefore, the improvement is needed.

Disclosure of Invention

The invention aims to provide a multi-core speed limiting method for realizing lock-free speed limiting by dynamically adjusting speed, which is used for solving the technical problems in the prior art.

In order to achieve the above purpose, the present invention adopts the following technical scheme: a multi-core speed limiting method for realizing lock-free speed limiting by dynamically adjusting speed comprises the following steps: s01, designing a speed limit example data structure; carrying out hash by taking the IP address as a key to generate a hash table item, traversing the linked list to find a service instance entry corresponding to the IP address;

s02, designing a business core speed limit processing flow; distributing a global speed limit token to each service core so that each service core is independent speed limit configuration; s03, designing a speed regulation nuclear speed regulation flow; and (3) independently taking one core for speed regulation, traversing all service instances, and calculating to obtain the independent token bucket rate of each core.

Preferably, the method for generating the hash table entry is as follows: selecting a proper hash function for converting the IP address into an integer hash value; calculating a hash value of the IP address, dividing the IP address into four parts, converting each part into an integer, and combining the integers into an integer hash value according to a certain rule; storing the calculated hash value as a key and the service instance entry related to the IP address as a value in a hash table; when a service instance entry corresponding to a given IP address needs to be searched, firstly calculating a hash value of the IP address, and then searching an entry corresponding to the hash value in a hash table; if a matching entry is found, returning the value of the entry; otherwise, returning the result which is not found.

Preferably, the hash table entry stores independent token buckets and traffic statistics of all service cores.

Preferably, the processing flow of the service core speed limit comprises the following steps: the service core receives the message; obtaining a destination IP address dip in a message as a key value of a hash table, converting the dip into a unique integer hash value by using a hash function, traversing a hash chain table, using the dip to match an instance service IP, losing a packet if the message fails, and hitting an instance entry if the message succeeds; acquiring the id of a current service core, wherein the id of the current service core is the index of a corresponding service core array in an instance entry array, and each core is independently configured; according to the message length and index, updating the flow statistics of the current core in the curt_stat of the entry; and obtaining a token bucket of the current core according to the index, judging whether to limit the packet loss or not through a token bucket algorithm, if the packet loss is limited, the packet loss is caused, and if the packet loss is not limited, the packet is normally sent.

Preferably, the method of converting dip into a unique integer hash value using a hash function is as follows: the dip is divided into four parts, each of which is then converted into an integer, and combined into an integer hash value according to a set rule.

Preferably, according to the message length and index, updating the flow statistics of the current core in the curt_stat of the entry, and specifically comprising the following steps: acquiring the length and index value of the current message; searching flow statistics of a current core in the entry according to index, and obtaining a curt_stat value; updating relevant fields in the curt_stat according to the current message length; and writing the updated curt_stat value back to the entry array of the core corresponding to the entry.

Preferably, the method for judging whether packet loss is limited by the token bucket algorithm is as follows: setting the capacity of a token bucket and the number of tokens generated per second; when a sender needs to send data, acquiring a token from a token bucket, and if no token exists in the token bucket, waiting until the token is available; after obtaining the token, the sender sends data; after the sender sends the data, the token is put back into the token bucket, and if the token bucket is full, redundant tokens are discarded; if the number of tokens in the token bucket does not reach the set threshold value within the set time, judging that the speed-limiting packet loss phenomenon occurs.

Preferably, the step of the speed regulation flow process is as follows: traversing the instance linked list to obtain each service instance entry; accumulating flow statistics of all cores of the cut_stat in the entry to obtain the tot_stat; calculating the flow percentage according to the flow statistics of each core of the curt_stat on the entry divided by the tot_stat; and according to the top_token on the entry and the calculated per-core flow percentage per core, the per-core calculation top_token is updated to the work_token to obtain the independent token bucket rate per core.

Preferably, the pacing flow calculates the curt_stat and the tol_token by a calculation formula, and assigns the per-core flow rate to the work_token.

Preferably, the calculation formula is specifically as follows:

wherein Ptn is the calculated n number core token bucket rate this time, btot is the accumulated sum of B1 to Bn, bn is n number core statistical traffic, where n is 1, 2, 3.

In summary, due to the adoption of the technical scheme, the beneficial effects of the invention are as follows:

1. the invention distributes the global token bucket rate of the service instance to the unique token bucket rate of each core through the single speed regulating core and the flow percentage of each core, thereby realizing the effect that the multi-core service speed limit is not locked and the service core and the performance are both increased linearly.

2. The invention removes the flow of locking the service flow, improves the performance of a single core, mainly removes the possibility of deadlock caused by locking, realizes non-locking speed limit, greatly improves the performance and leads the service core to be linearly increased.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following description will briefly explain the drawings used in the embodiments or the description of the prior art, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 shows a flow chart of the method of the present invention;

FIG. 2 illustrates a hash table entry structure of the present invention;

FIG. 3 shows a flow chart of the business core speed limit processing of the present invention;

FIG. 4 shows a timing core timing flow chart of the present invention;

FIG. 5 shows a schematic diagram of a governing calculation formula of the present invention;

FIG. 6 is a schematic diagram showing the results of a single core performance test of the present invention;

fig. 7 shows a schematic diagram of the 3-core performance test results of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Example 1

Referring to fig. 1, a method for realizing lock-free speed limiting by dynamically adjusting speed of a plurality of cores comprises the following steps:

s01, designing a speed limit example data structure;

the hash is carried out by taking the IP address as a key to generate a hash table item, and then the linked list is traversed to find a service instance entry corresponding to the IP address, which comprises the following specific steps:

(1) Selecting a proper hash function for converting the IP address into an integer hash value, wherein the common hash functions include MurmurHash, cityHash and the like;

(2) Calculating the hash value of the IP address, dividing the IP address into four parts (such as 192.168.1.1), converting each part into an integer, and combining the integers into an integer hash value according to a certain rule; for example, the first part may be shifted left 24 bits, the second part shifted left 16 bits, the third part shifted left 8 bits, the fourth part left unchanged, and then the four integers added to obtain the hash value;

(3) Storing the calculated hash value as a key and the service instance entry related to the IP address as a value in a hash table; this may be accomplished using a dictionary or hash table;

(4) When a service instance entry corresponding to a given IP address needs to be searched, firstly calculating a hash value of the IP address, and then searching an entry corresponding to the hash value in a hash table; if a matching entry is found, returning the value of the entry; otherwise, returning a result which is not found;

the hash table item stores independent token buckets and flow statistical information of all service cores;

the hash table entry structure design is shown in fig. 2, and specific parameters of the table entry structure are described as follows:

structlist_header: the service instance adopts a linked list structure;

uint 32_tinstace_ip: the key unique identifier of the service instance is also used for hash of the linked list, so that quick search is solved;

token_ttol_token: the total speed-limiting token bucket configuration of the service instance;

token_tten [256]: the service core speed-limiting token bucket array is provided with an independent token bucket for speed-limiting use; the id of the service core is the index of the index set, and the maximum support is 256 cores;

work_flow_stat_tcurt_stat [256]: and each service core has independent flow statistics, and is used for summarizing the flow statistics of all the service cores by the speed regulation core, and then reassigning the total token bucket rate to each service core token according to the percentage, wherein the id of the service core is the index of the array, and 256 cores are supported maximally.

S02, designing a business core speed limit processing flow;

the service cores are multi-core processing, each core has a full configuration, and can independently process all service instances, but the speed limiting configuration of one instance needs to be global, so that a normal scheme needs to be locked;

furthermore, in order to solve global locking, the global speed limit token is designed to be distributed to each service core, so that the locking is not needed when each service core is in independent speed limit configuration, and the independent speed limit configuration of all service cores is added up to be equal to the total speed limit configuration;

specifically, referring to fig. 3, the processing flow of the service core speed limit includes the following steps:

(1) The service core receives the message;

(2) Obtaining a destination IP address dip in the message as a key value of a hash table, converting the dip into a unique integer hash value by using a hash function, traversing a hash chain table, searching an item matched with the calculated hash value, and if the matched item is found, continuing to execute the next step; otherwise, the case that the matched instance service IP is not found is indicated, and packet loss processing is needed; after finding a matching entry, it is necessary to determine whether the entry is an instance entry; the judgment can be carried out by comparing the service IP address in the entry with the dip in the message; if the two are equal, a hit example entry is described, and subsequent processing can be performed; otherwise, the missing of the packet is required to be processed without hitting the instance entry; if hit the instance entry, can process the message, for example analyze the message content, update database, etc.; if the example entry is not hit, packet loss processing is performed, such as logging, sending error reports, and the like;

specifically, the method for converting dip into a unique integer hash value using a hash function is as follows:

the dip is divided into four parts (e.g., 192.168.1.1), each part is then converted to an integer and combined into an integer hash value according to a certain rule, e.g., the first part can be shifted left 24 bits, the second part can be shifted left 16 bits, the third part can be shifted left 8 bits, the fourth part can be left unchanged, and then the four integers can be added to obtain the hash value.

(3) Acquiring the id of the current service core, wherein the id is the index of the corresponding service core array in the instance entry array, and each core is independently configured;

(4) According to the message length and index, updating the flow statistics of the current core in the curt_stat of the entry, wherein the flow statistics comprises the following specific steps:

acquiring the length and index value of a current message, searching the flow statistics of a current core in an entry according to the index, and acquiring a curt_stat value; updating relevant fields in the curt_stat according to the current message length, such as the number of accumulated entry data packets, the number of accumulated entry bytes, the number of accumulated exit data packets and the like; writing the updated curt_stat value back to the entry array of the core corresponding to the entry, wherein the curt_stats corresponding to different cores are required to be stored according to a specific sequence;

(5) Acquiring a token bucket of a current core according to index, judging whether packet loss occurs at a speed limit through a token bucket algorithm, if so, packet loss occurs, and if not, packet sending is performed normally;

specifically, the method for judging whether to limit the speed and lose the packet by the token bucket algorithm is as follows:

setting the capacity of a token bucket and the number of tokens generated per second;

when a sender needs to send data, acquiring a token from a token bucket, and if no token exists in the token bucket, waiting until the token is available;

after obtaining the token, the sender can send a certain amount of data, and the size of the data amount can be set according to actual requirements;

after the sender sends the data, the token is put back into the token bucket, and if the token bucket is full, redundant tokens are discarded;

if the number of tokens in the token bucket does not reach a set threshold (the threshold is set according to the actual situation) within a certain time (such as 1 second and 2 seconds), the speed-limiting packet loss phenomenon is considered to occur;

specifically, assuming that the capacity of a token bucket is set to 10 tokens, 2 tokens are generated every second, and when a sender needs to send data, one token is firstly obtained from the token bucket; if the token bucket has tokens at the moment, data transmission is allowed; if no token exists in the token bucket, waiting until a token is available;

assuming that the sender successfully acquired 2 tokens in 1 second and sent a corresponding amount of data, the number of tokens remaining in the token bucket is 8. In the next 1 second, the number of tokens in the token bucket does not increase since only 2 tokens are generated per second. Thus, during the next 1 second, if the sender tries to acquire the token again, it will wait because there is no token in the token bucket;

if the number of tokens in the token bucket does not reach the set threshold (2 times) within 3 continuous seconds (3 time intervals in total), the speed-limiting packet loss phenomenon is considered to occur; in this case, the rate limiting strategy may be optimized by adjusting the capacity of the token bucket or the number of tokens generated per second to avoid the occurrence of the packet loss phenomenon.

S03, designing a speed regulation nuclear speed regulation flow;

specifically, speed regulation is carried out by taking one core alone, all service examples are traversed, then the percentage of each core is calculated through flow statistics of the service cores, and the independent token bucket rate of each core is obtained through the percentage and the total token bucket rate;

further, referring to fig. 4, the steps of the speed regulation core speed regulation flow process are as follows:

(1) Traversing the instance linked list to obtain each service instance entry;

(2) Accumulating the flow statistics of all cores of the curt_stat in the entry into tot_stat;

(3) Calculating the flow percentage according to the flow statistics of each core of the curt_stat on the entry divided by the tot_stat;

(4) According to the upper top token of the entry and the calculated per-core flow percentage per-core, the per-core calculation top token is updated to the work token to obtain the independent token bucket rate of each core;

specifically, for the above steps, the following is specifically exemplified:

referring to FIG. 5, the pacing thread assigns a per-core flow rate to the work_token by calculating the curt_stat and the tol_token, taking the 32 service cores as an example to calculate the formula;

b1 is the core number 1 statistical flow;

btot is the sum of B1 to B32, namely the sum of the flows of all service cores under the entry;

the tol_token is the total token bucket configuration currently on this entry;

pt1 is the current calculation number 1 core token bucket rate;

wherein Ptn is the calculated n-number core token bucket rate, bn is n-number core statistical traffic, where n is 1, 2, 3.

In summary, the invention makes flow statistics on each core in the service instance, then independently takes out calculation of one core period, can convert the flow statistics on each core according to each service instance into the flow percentage of each core of the service instance, and then distributes the total token bucket rate of the service instance to each core according to the flow percentage, so that the global token bucket becomes a unique token bucket of each core to solve the problem of locking, the service cores are linearly increased, and the performance is also linearly increased.

Example 2

In the space wing cloud 4.0 cloud network base, the speed limiting network elements all adopt the method in the embodiment 1 to realize lock-free speed limiting, and are used for speed limiting of the businesses such as eip, natgw, metering, lb, vpn and the like.

Forwarding performance: the 10G network card has the CPU single-core forwarding performance reaching 450w+pps, the 3-core forwarding performance reaching 1044w+pps (full bandwidth 10G), the service cores are linearly increased, the performance is linearly increased, and for a 10G physical network card interface, the full bandwidth line speed forwarding only needs 3 CPU cores;

the single-core performance test result is shown in figure 6;

the 3-core performance test results are shown in figure 7.

In summary, the invention distributes the speed-limiting token bucket to each service core according to the flow ratio by a speed-regulating core, thereby realizing the lock-free speed limitation of the service core, and the invention is also a method for distributing the global service by a service rule in an independent way for each core, thereby realizing the effect of not locking, so that the service core is linearly increased, and the performance is also linearly increased.

The foregoing is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art, who is within the scope of the present invention, should make equivalent substitutions or modifications according to the technical scheme of the present invention and the inventive concept thereof, and should be covered by the scope of the present invention.

The preferred embodiments of the invention disclosed above are intended only to assist in the explanation of the invention. The preferred embodiments are not intended to be exhaustive or to limit the invention to the precise form disclosed. Obviously, many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and the practical application, to thereby enable others skilled in the art to best understand and utilize the invention. The invention is limited only by the claims and the full scope and equivalents thereof.

Claims (10)

1. A method for realizing lock-free speed limiting by multi-core dynamic speed regulation is characterized by comprising the following steps:

s01, designing a speed limit example data structure;

carrying out hash by taking the IP address as a key to generate a hash table item, traversing the linked list to find a service instance entry corresponding to the IP address;

s02, designing a business core speed limit processing flow;

distributing a global speed limit token to each service core so that each service core is independent speed limit configuration;

s03, designing a speed regulation nuclear speed regulation flow;

and (3) independently taking one core for speed regulation, traversing all service instances, and calculating to obtain the independent token bucket rate of each core.

2. The method for realizing lock-free speed limit by multi-core dynamic speed regulation according to claim 1, wherein the method for generating the hash table entry is as follows:

selecting a proper hash function for converting the IP address into an integer hash value;

calculating a hash value of the IP address, dividing the IP address into four parts, converting each part into an integer, and combining the integers into an integer hash value according to a certain rule;

storing the calculated hash value as a key and the service instance entry related to the IP address as a value in a hash table;

when a service instance entry corresponding to a given IP address needs to be searched, firstly calculating a hash value of the IP address, and then searching an entry corresponding to the hash value in a hash table; if a matching entry is found, returning the value of the entry; otherwise, returning the result which is not found.

3. The method for realizing lock-free speed limit by multi-core dynamic speed regulation according to claim 2, wherein independent token buckets and flow statistics of all service cores are stored in the hash table entry.

4. The method for realizing lock-free speed limit by multi-core dynamic speed adjustment according to claim 3, wherein the processing flow of service core speed limit comprises the following steps:

the service core receives the message;

obtaining a destination IP address dip in a message as a key value of a hash table, converting the dip into a unique integer hash value by using a hash function, traversing a hash chain table, using the dip to match an instance service IP, losing a packet if the message fails, and hitting an instance entry if the message succeeds;

acquiring the id of a current service core, wherein the id of the current service core is the index of a corresponding service core array in an instance entry array, and each core is independently configured;

according to the message length and index, updating the flow statistics of the current core in the curt_stat of the entry;

and obtaining a token bucket of the current core according to the index, judging whether to limit the packet loss or not through a token bucket algorithm, if the packet loss is limited, the packet loss is caused, and if the packet loss is not limited, the packet is normally sent.

5. The method for realizing lock-free speed limit by multi-core dynamic speed regulation according to claim 4, wherein the method for converting dip into a unique integer hash value by using a hash function is as follows:

the dip is divided into four parts, each of which is then converted into an integer, and combined into an integer hash value according to a set rule.

6. The method for realizing lock-free speed limit by multi-core dynamic speed regulation according to claim 5, wherein the flow statistics of the current core in the curt_stat of the entry are updated according to the message length and index, and the specific steps are as follows:

acquiring the length and index value of the current message;

searching flow statistics of a current core in the entry according to index, and obtaining a curt_stat value;

updating relevant fields in the curt_stat according to the current message length;

and writing the updated curt_stat value back to the entry array of the core corresponding to the entry.

7. The method for realizing lock-free speed limit by multi-core dynamic speed regulation according to claim 6, wherein the method for judging whether the speed limit is lost or not by the token bucket algorithm is as follows:

setting the capacity of a token bucket and the number of tokens generated per second;

when a sender needs to send data, acquiring a token from a token bucket, and if no token exists in the token bucket, waiting until the token is available;

after obtaining the token, the sender sends data;

after the sender sends the data, the token is put back into the token bucket, and if the token bucket is full, redundant tokens are discarded;

if the number of tokens in the token bucket does not reach the set threshold value within the set time, judging that the speed-limiting packet loss phenomenon occurs.

8. The method for realizing lock-free speed limit by multi-core dynamic speed regulation according to claim 7, wherein the speed regulation flow process comprises the following steps:

traversing the instance linked list to obtain each service instance entry;

accumulating flow statistics of all cores of the cut_stat in the entry to obtain the tot_stat;

calculating the flow percentage according to the flow statistics of each core of the curt_stat on the entry divided by the tot_stat;

and according to the top_token on the entry and the calculated per-core flow percentage per core, the per-core calculation top_token is updated to the work_token to obtain the independent token bucket rate per core.

9. The method for realizing lock-free speed limit by multi-core dynamic speed adjustment according to claim 8, wherein the speed adjustment flow calculates a curt_stat and a tol_token through a calculation formula and distributes the flow rate of each core to a work_token.

10. The method for realizing lock-free speed limit by multi-core dynamic speed regulation according to claim 9, wherein the calculation formula is as follows:

wherein Ptn is the calculated n number core token bucket rate this time, btot is the accumulated sum of B1 to Bn, bn is n number core statistical traffic, where n is 1, 2, 3.