A real-time performance analysis method for network buffer under multi-core scheduling platform

By designing a real-time performance analysis method for network buffers and a buffer allocation algorithm based on the closest size under the multi-core platform, the problems of network buffer performance testing and resource allocation under the multi-core platform are solved, and accurate testing of buffer performance and efficient allocation of resources are achieved.

CN113590283BInactive Publication Date: 2025-03-25XIAN TECH UNIV
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202110816326.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-07-20
Publication Date
2025-03-25
Estimated Expiration
Not applicable · inactive patent

AI Technical Summary

Technical Problem

The prior art is difficult to effectively test and optimize network buffer performance under multi-core platforms, especially in terms of resource allocation and real-time scheduling.

Method used

A real-time performance analysis method for network buffers under the multi-core scheduling platform is designed. By defining tasks with different priorities and corresponding real-time parameters, a buffer allocation algorithm based on the closest size is designed and tested under the multi-core platform.

Benefits of technology

Accurate testing of network buffer performance is realized, and performance indicators such as buffer response time, execution time and number of preempted times are displayed, improving the performance and resource allocation efficiency of buffers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113590283B_ABST
    Figure CN113590283B_ABST
Patent Text Reader

Abstract

The present invention relates to a real-time performance analysis method for a network buffer under a multi-core scheduling platform. The present invention first designs a new network buffer, and then proposes a buffer allocation method based on the buffer size. According to the different priority levels and corresponding real-time parameters of each buffer task, the corresponding criticality is defined, and then the task is scheduled in real time. When the buffer is not enough for the task allocation, the buffers near the demand are assembled and allocated to the task. Finally, a performance test method for the buffer under a multi-core platform is proposed, and the results show that the utilization rate of the buffer and the communication efficiency of the protocol stack are improved. The buffer designed by the present invention and its allocation algorithm have broad application prospects and important value in the design and testing of the network buffer of the national embedded operating system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention belongs to the technical field of computer networks, and in particular to a real-time performance analysis method for a network buffer under a multi-core scheduling platform, for performing network buffer and resource allocation tests. Background Art

[0002] The network buffer is a storage area allocated from the memory. It can be used to store various data required by the protocol stack to send information. The network buffer is a key factor affecting the communication efficiency of a multi-core embedded real-time system protocol stack. However, there are very few technologies and articles related to the performance test of the network buffer. It is necessary to test and analyze the performance of a buffer to prove its superiority. A good network buffer is of great help to improve the communication efficiency of the protocol stack. It requires that the buffer structure should be simple, effective, stable and easy to manage. To improve the performance of the network buffer, the first thing is to simplify the structure of the buffer, and the second is to have a good management mechanism. This requires designers to have certain research in structure and management strategies. The network buffer can be opened in advance in the memory. Since the buffer has been opened in advance, only the buffer pointer needs to be modified to achieve the purpose of allocating the buffer, so the CPU overhead of this method is relatively small. However, it is necessary to allocate enough buffer blocks during initialization to win enough processing time for the frame processing. Before the processing is completed, it is guaranteed that it will not be overwritten by new frames. Therefore, the memory overhead of the pre-allocation method is large. The overwrite method means that when receiving a frame, no buffer is allocated for the receiving descriptor, but the data in the buffer is copied to another memory space for processing, and the buffer pointed to by this descriptor is reused to receive new frames. It is also possible to open a buffer each time data is received (the data header is the data size); then accept the data and fill it into the buffer, give the buffer and IP information to the task, push it into the task queue, and wait for the task thread to process it; its advantage is that the receiving thread can always receive, the task thread always processes, and there is no other interaction except the task lock; but the disadvantage is that space is re-applied each time, and malloc (or new) consumption is large. At the same time, a good buffer management strategy and allocation algorithm are also the key to affecting communication efficiency.

[0003] There are many studies on buffer management strategies. PacketShade statically pre-allocates two larger buffers - socket buffers, one for control information and the other for packet data. By continuously storing the SKB control information and packet data of each received packet, it avoids buffer application and release, effectively reducing I / O overhead and memory access overhead. However, the problem is that the size of the buffer is fixed when it is allocated. When the buffer is not enough, how to allocate it reasonably is a very big problem. Summary of the invention

[0004] The purpose of the present invention is to provide a real-time performance analysis method for a network buffer under a multi-core scheduling platform, which solves the performance test problem of the operating system real-time scheduling of the network buffer under an embedded multi-core platform and the allocation problem of the network buffer.

[0005] In order to achieve the above technical objectives, the present invention adopts the following technical solutions:

[0006] A real-time performance analysis method for network buffers under a multi-core scheduling platform is proposed. The buffer sbuf is designed, and the corresponding criticality is defined for each buffer task with different priority levels and corresponding real-time parameters. Then, the tasks are scheduled in real time, and the corresponding buffer allocation algorithm is designed. Finally, it is tested under a multi-core platform.

[0007] Further, the method specifically includes the following steps:

[0008] Step 1, set a buffer Sbuf, the buffer Sbuf includes HEAD type, PKT type and cluster; the difference between HEAD type and PKT is that the size of HEAD data is fixed because HEAD type is used to store header data such as tcp, ip, udp, and the area where PKT type stores data is called cluster, and its size is variable in many ways because it is used to store various data;

[0009] Step 2: Calculate the priority of the high priority allocated to the processor according to the partition scheduling algorithm;

[0010] Step 3: If the buffer size required by the task is not available, call the designed closest buffer allocation algorithm to allocate it;

[0011] Step 4: Calculate the buffer closest to the required task size according to the size of the task and allocate it. If it still does not meet the requirements, continue to calculate the next closest buffer size and allocate it.

[0012] Step 5: Test the buffer Sbuf on a multi-core platform.

[0013] The method for real-time performance analysis of network buffer under the core scheduling platform according to claim 2 is characterized in that:

[0014] In step 2, the priority of each task is calculated, which specifically includes the following steps:

[0015] Step 201: Each task has its own priority α(Ni) in advance, and then the time priority β(Ni) of each task running on the processor is calculated;

[0016] Step 202: According to pr(Ni )=α(N i )+β(N i ) formula to calculate the final priority.

[0017] Furthermore, in step 3, the buffer allocation method specifically includes the following steps:

[0018] Step 301: Calculate the first closest buffer size φ (N i ) and allocate the corresponding buffer;

[0019] Step 302: If the allocated buffer still does not meet the demand, continue to calculate the next closest buffer γ (N i ) and assigns it to the task, and the two together constitute the buffer required by the task: λ(Ni)=φ(Ni)+γ(Ni).

[0020] Furthermore, in step 5, the test steps are as follows:

[0021] Step 501, setting different multi-core scheduling algorithms GSN-EDF, PSN-EDF, PFAIR;

[0022] Step 502: Two commonly used buffers, 64 KB and 1024 KB, are used for testing using different multi-core scheduling algorithms.

[0023] Compared with the prior art, the advantages of the present invention are:

[0024] The present invention proposes a testing method for performance testing of a network buffer under a multi-core platform, and also improves mbuf and designs a buffer allocation algorithm based on the closest size; the method tests the performance of the buffer under multiple scheduling algorithms, and can accurately and clearly display performance indicators such as the response time, execution time, number of preemptions, etc. of a certain buffer. The method of the present invention solves the performance testing problem of the network buffer and has broad application prospects and important value in the design and testing of the network buffer of the embedded operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is the overall flow chart of the present invention;

[0026] Figure 2 The network buffer Sbuf designed for the present invention;

[0027] Figure 3 The pseudo code of the closest allocation algorithm based on buffer size of the present invention;

[0028] FIG4 is a test result of a 64kb buffer of the present invention;

[0029] FIG. 5 is a test result of a 1024kb buffer of the present invention. DETAILED DESCRIPTION

[0030] The present invention is further described in detail below in conjunction with the accompanying drawings by specific embodiments. Wherein similar elements in different embodiments have adopted associated similar element numbers. In the following embodiments, many details are described in order to make the application better understood. However, those skilled in the art can recognize without difficulty that some features can be omitted in different situations, or can be replaced by other elements, materials, methods.

[0031] With the widespread use of multi-core platforms, more and more functions can be realized, but the performance test of network buffers has not been documented.

[0032] The buffer Mbuf in the Vxworks system is a relatively complex buffer designed based on a buffer pool. Its advantage is that data is shared by reference, thereby achieving "zero copy" and improving efficiency. It is widely used in military, aviation, and aerospace industries with good performance and real-time performance. The present invention proposes a test method under a multi-core platform for the performance test of a network buffer, and also improves mbuf and designs a buffer allocation algorithm based on the closest size. The method tests the performance of the buffer under a variety of scheduling algorithms, and can accurately and clearly display the response time, execution time, number of times preempted, and other performance indicators of a buffer.

[0033] The specific steps of the present invention are as follows:

[0034] S1. Design buffer sbuf:

[0035] like Figure 2 As shown, the improved sbuf is divided into two structure types:

[0036] The data area of ​​the first structure is used to store the protocol header data. The next pointer points to the next data packet, the Data pointer points to the area where the header is stored, len is the size of the header, type and flags are structures for obtaining the type information of the data packet. Type is divided into Head and Pkt, which respectively determine whether the data packet stores the header or data. Cunt is a structure used for release.

[0037] The second structure is used to store data. The difference between it and the first structure is that the data area of ​​the first structure is contained in the structure itself, while the data area of ​​the second structure is an external structure called Cluster. Since the size of the protocol layer header is at most 108 bytes, there is no need to apply for an additional space for storage. The size of the Cluster varies from 64, 128, 256...65536. Clusters of different sizes are applied for different data packets, and finally the structure of the buffer Sbuf is formed.

[0038] S2. Design allocation algorithm:

[0039] After the memory pool is initialized successfully, tasks can use clusters of corresponding sizes in the corresponding memory pool to store data according to their needs. However, if there are many tasks accessing the memory pool at the same time, it is important to allocate them correctly. Suppose there are only 10 1024kb clusters in the memory pool, but there are 11 tasks that want to get a 1024kb cluster. At this time, there must be one cluster that cannot get the 1024kb cluster. Therefore, we designed an allocation algorithm that reorganizes the memory according to the priority of the task and when the memory pool allocation is completed.

[0040] When calculating the task priority, we only need to add the task's own priority α(Ni) and each task's final execution deadline and deadline β(Ni) to determine the priority. The calculation method is shown in formula (1). Because if two tasks have the same priority, we need to use the deadline to determine which one has a higher priority.

[0041] pr(N i )=α(N i )+β(N i ) (1)

[0042] The calculation formula for calculating the priority of the built-in task α(Ni) is shown in formula (2):

[0043] α(N i )=Max(pr1, pr2, pr3, ...., pr N ) (2)

[0044] If two or more tasks have the same priority, it is necessary to calculate the deadline of each task to determine the priority of the task. The calculation formula is shown in formula (3):

[0045] β(N i )=Min(T1,T2,T3,...,T N ) (3)

[0046] After calculating the priority, each task is inserted into the queue and a cluster is allocated in the memory pool according to its needs. When a type of cluster has been allocated and there are still tasks to be allocated, the φ(N i ) and the remaining closest to γ(N i ) to meet the needs of the task. The calculation method is shown in formula 4:

[0047] λ(Ni)=φ(Ni)+γ(Ni) (4)

[0048] Calculate the nearest demand φ(N i ) is shown in formula (5); where Need represents the demand and Kind represents the size of different clusters.

[0049] φ(N i )=Min(Need-Kind1,Need-Kind2,...,Need-Kind N ) (5)

[0050] Calculate the remaining nearest demand γ(N i ) is shown in formula (6);

[0051] γ(N i )=Min((Kind1-φ(N i )),(Kind2-φ(N i )),...,(Kind N -φ(N i ))) (6)

[0052] The pseudo code of the allocation algorithm is as follows Figure 3 As shown:

[0053] The test examples of the present invention are described below:

[0054] Set different multi-core scheduling algorithms GSN-EDF, PSN-EDF, PFAIR. Transplant the improved sbuf and the original buffer to the computer with litmus-rt multi-core experimental platform installed. Use 64Kb and 1024kb, two commonly used buffers, and use different multi-core scheduling algorithms for testing. Design 5 threads, 5 tasks are all the same size mbuf application, the cycle is 2ms, and the deadline is the time given in the table. Among many experimental data, three main data are selected, namely the actual execution time of the task, the response time of the task, and the number of times the task is preempted. The actual execution time of the task (ACET) is the actual execution time of the task in the system after excluding the time of preemption and other time. The response time is the time from the start of the task to the end of the execution. The number of preemptions is the number of times the task is preempted by other tasks and programs.

[0055] The test results are shown in Figures 4 and 5: Figures a, b, and c in Figure 4 are the comparisons of the response time, preemption times, and actual execution time of the 64kb cluster sbuf and before the improvement. It can be seen that the improvement has been significantly improved. Figures a, b, and c in Figure 5 are the comparisons of the response time, preemption times, and actual execution time of the 1024kb cluster sbuf and before the improvement. It can be seen that the improvement has been significantly improved.

[0056] Safety-critical task scheduling example:

[0057] The execution time of different tasks is different. The priority is determined by the different execution time and the priority state of the task itself. The execution time of different tasks is shown in Figure 1.

[0058] Table 1 Execution time of different tasks

[0059]

[0060] For the overall process Figure 1 As shown, a new buffer sbuf is designed first, then ported to the litmus-rt environment, a buffer allocation algorithm is designed and then tested.

[0061] For those skilled in the art, several improvements and modifications may be made without departing from the principles of the present invention, and these improvements and modifications should also be considered as within the scope of protection of the present invention.

Claims

1. A method for real-time performance analysis of network buffer under a multi-core scheduling platform, characterized in that: Design the buffer sbuf, define the corresponding criticality for each buffer task's different priority levels and corresponding real-time parameters, then schedule the tasks in real time, design the corresponding buffer allocation algorithm, and finally test it on a multi-core platform; The specific steps include: Step 1, set a buffer Sbuf, the buffer Sbuf includes HEAD type and PKT type; the difference between HEAD type and PKT is that the size of the data stored in HEAD is fixed because HEAD type is used to store header data such as tcp, ip, and udp, and the area for storing data in PKT type is called cluster, and its size is variable in many ways because it is used to store various data; Step 2: Calculate the priority of the high priority allocated to the processor according to the partition scheduling algorithm; In step 2, the priority of each task is calculated, which specifically includes the following steps: Step 201: Each task has its own priority α(Ni) in advance, and then the time priority β(Ni) of each task running on the processor is calculated; Step 202: Calculate the final priority according to the formula pr(Ni)=α(Ni)+β(Ni); Step 3: If the buffer size required by the task is not available, call the designed closest buffer allocation algorithm to allocate it; In step 3, the buffer allocation method specifically includes the following steps: Step 301: Calculate the first closest buffer size according to the buffer size required by each task And allocate the corresponding buffer; Step 302: If the allocated buffer still does not meet the demand, continue to calculate the next closest buffer γ (N i ), and assign it to the task, which together constitutes the buffer required by the task: Step 4: Calculate the buffer closest to the required task size according to the size of the task and allocate it. If it still does not meet the requirements, continue to calculate the next closest buffer size and allocate it. Step 5: Test the buffer Sbuf on a multi-core platform.

2. The method for real-time performance analysis of network buffer under the core scheduling platform according to claim 1, characterized in that: In step 5, the test steps are as follows: Step 501, setting different multi-core scheduling algorithms GSN-EDF, PSN-EDF, PFAIR; Step 502: Two commonly used buffers, 64 KB and 1024 KB, are used for testing using different multi-core scheduling algorithms.