CN114489822A - Device for realizing hot start method - Google Patents

Abstract

The invention discloses a hot start implementation method and a device, wherein the method comprises the following steps: applying for a memory area in the fixed memory; the memory area is used as a soft table for storing routing information; storing the routing information generated by the upper layer in the soft table in real time; and setting an identification position for identifying whether the hard table is configured or not in the generated routing information structure body, and updating the identification position after the hard table is configured. By the device and the method, the problem that software and hardware tables are inconsistent due to hot start in the prior art can be solved.

Description

Device for realizing hot start method

Technical Field

The present invention relates to network communication technologies, and in particular, to a method and an apparatus for implementing hot start.

Background

Direct memory read-write hot start (warrmboot, WB) is to restart device driver software in the case of hardware running without interrupting data forwarding, and can be applied to cases such as application software upgrade, driver upgrade, and software hang-up recovery. During the warm-boot process, the software can reestablish the internal control state without affecting the forwarding plane through a special initialization sequence. Generally, the establishment of the internal state of the software can be accomplished by the following ways:

the software state is reconstructed by directly reading registers and tables from the hardware. Before the chip mating software SDK is started in a hot mode, data can be stored in a local disk file through an API (application programming interface), and the data can also be stored in an external storage designated by an upper layer user. The software state is reconstructed by reading data from an externally stored data source through the API upon warm boot.

The current common hot start modes include:

(1) before the system upgrading process, the operation state related soft table is synchronized to a preset database, namely a database mode. However, since it takes a long time (perhaps as long as 10 minutes) to trigger the warmsoot Sync once into the database, and in the process, the upper layer user cannot issue a new service, the database storage does not support the software table to be updated in time or in real time, and only supports the functions of software upgrade planned by the user. In addition, because the database occupies a large storage memory, but the memory of the general embedded equipment is limited, the database mode is difficult to support under many conditions, and the application of the database mode is limited;

(2) for the problem of the database mode, in the current practical application, another mode exists, that is, a user independently opens up a fixed memory, and the run-time data soft table is still applied from the system memory. The data in the system is triggered at regular time and synchronized in the fixed memory. According to the scheme, the soft table is directly stored in the memory, so that the user only needs dozens of milliseconds to store the soft table of the relevant module. The upper layer user or the SDK can regularly and actively trigger the soft table and store the soft table in the fixed memory.

The mode (2) solves the problems that some embedded devices do not support databases and can support timely synchronous scenes. Because the data is directly stored in the memory, the reading and the recovery are both faster, and the performance is better than that of the database storage. There may still be a problem in that the upper layer or SDK timing is required to synchronize the soft table to the fixed memory when storing data. If the soft table is just changed but is not synchronized to the fixed memory, once problems such as CPU hang-up occur, the soft table data will be lost. After the hot start, the problem of inconsistent software and hardware tables may be caused.

Disclosure of Invention

The technical problem to be solved by the embodiment of the invention is how to solve the problem that the hot start may cause inconsistency of the soft and hard tables in the prior art.

In order to solve the above technical problem, the present invention provides a method for implementing hot start, including: applying for a memory area in the fixed memory; the memory area is used as a soft table for storing routing information; storing the routing information generated by the upper layer in the soft table in real time; and setting an identification position for identifying whether the hard table is configured or not in the generated routing information structure body, and updating the identification position after the hard table is configured.

The hot start implementation method further includes: when the hot start is carried out, the storage address of the routing information in the memory area is analyzed; judging whether the hard table configuration is finished or not according to the identification bit in the routing information structure body; and if the soft table is judged to be not complete, deleting the soft table.

In the above implementation method of warm boot, the fixed memory includes a physical medium memory, or a virtual address space formed by mapping a file in a file system to a user state through a memory.

In the above implementation method of warm boot, the SDK executes an operation on the fixed memory, and the size of the fixed memory is greater than or equal to a memory required by the SDK.

In the above implementation method of warm boot, the storing the routing information generated by the upper layer in the soft table in real time includes: when the routing information is updated, synchronously updating the routing information in the memory area; and releasing the memory area when the routing information is deleted.

In order to solve the above technical problem, the present invention provides a hot start implementation apparatus, including: the device comprises a setting unit, a memory area and a memory management unit, wherein the setting unit is used for applying for a memory area in a fixed memory; the memory area is used as a soft table for storing routing information; the processing unit is used for storing the routing information generated by the upper layer in the soft table in real time; and setting an identification position for identifying whether the hard table is configured or not in the generated routing information structure body, and updating the identification position after the hard table is configured.

In the above apparatus for implementing hot start, the processing unit is further configured to, when the hot start is performed, analyze a storage address of the routing information in the memory area; judging whether the hard table configuration is finished or not according to the identification bit in the routing information structure body; and if the soft table is judged not to be completed, deleting the soft table.

In the above apparatus for implementing hot boot, the fixed memory includes a physical medium memory, or a virtual address space formed by mapping a file in a file system to a user state through a memory.

In the above hot start implementation apparatus, the SDK executes an operation on the fixed memory, and the size of the fixed memory is greater than or equal to a memory required by the SDK to operate.

In the above implementation apparatus for warm boot, the storing, by the processing unit, the routing information generated by the upper layer in the soft table in real time includes: when the routing information is updated, synchronously updating the routing information in the memory area; and releasing the memory area when the routing information is deleted.

Aiming at the problems in the prior art, the invention achieves the purpose of real-time synchronization by applying an area in the fixed memory as an SDK soft table for storing the routing information. Therefore, a series of processing operations in the prior art that the soft table needs to be stored into the fixed memory from the real-time memory, the data structure conversion exists in the middle of the process of storing the finally stored data into the database or the fixed memory, the data conversion needs to be realized within a certain time, and the data is stored into the database or the fixed memory again can be avoided. The invention can realize real-time synchronization of data, and support the CPU running process to completely recover to the state before the CPU is hung even if the CPU is suddenly hung up after the CPU is started. In addition, because the identification bit for finishing the configuration of the hard table is set, whether the configuration of the hard table is finished can be judged, and the condition that the hard table and the soft table are inconsistent can be avoided.

Drawings

FIG. 1 is a schematic flow chart of example 1 of the present invention;

FIG. 2 is a flowchart illustrating step S104 in embodiment 1 of the present invention; (ii) a

Fig. 3 is a schematic structural diagram of a routing header node in a fixed memory according to embodiment 1 of the present invention.

Detailed Description

The existing hot start mode can independently open up a fixed memory for a user aiming at the problem of a database mode, and a data soft table is still applied from a system memory during operation. The data in the system is triggered at regular time and is synchronized in the fixed memory. According to the scheme, the soft table is directly stored in the memory, so that the user only needs dozens of milliseconds to store the soft table of the relevant module. The upper layer user or the SDK can regularly and actively trigger the soft table and store the soft table in the fixed memory. Although the method solves the problems that some embedded devices do not support databases and need to support timely synchronous scenes, a problem that an upper layer or an SDK (software development kit) is needed to synchronize the soft table into a fixed memory at regular time when data is stored still exists. If the soft table is just changed but is not synchronized to the fixed memory, once problems such as CPU hang-up occur, the soft table data will be lost. After the hot start, the problem of inconsistent software and hardware tables may be caused.

Aiming at the problems in the prior art, the embodiment of the invention aims at the problems in the prior art, and achieves the purpose of real-time synchronization by applying an area in a fixed memory as an SDK soft table for storing routing information. Therefore, a series of processing operations in the prior art that the soft table needs to be stored into the fixed memory from the real-time memory, the data structure conversion exists in the middle of the process of storing the finally stored data into the database or the fixed memory, the data conversion needs to be realized within a certain time, and the data is stored into the database or the fixed memory again can be avoided. The invention can realize real-time synchronization of data, and support the CPU running process to completely recover to the state before the CPU is hung even if the CPU is suddenly hung up after the CPU is started. In addition, because the identification bit for finishing the configuration of the hard table is set, whether the configuration of the hard table is finished can be judged, and the condition that the hard table and the soft table are inconsistent can be avoided.

In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in detail below.

Example 1

The hot start implementation method of the embodiment of the invention can be widely applied to all embedded devices and is not limited to switching network devices. For convenience of description, this embodiment takes a network routing device as an example for description, and specifically, the warm-boot implementation method includes:

step S101, applying for a memory area in a fixed memory;

after the upper layer of the user creates a three-layer route, step S101 is executed. The soft table in this embodiment refers to a maintenance table on software, such as a soft second-layer forwarding table, a soft third-layer routing table, a soft access control table, and the like; in contrast, the hard table refers to a maintenance table on the hardware, such as a chip two-layer forwarding table, a chip three-layer routing forwarding table, a chip access control table, and the like. The difference between this embodiment and the prior art is that the memory area is used as a soft table for storing the routing information, that is, the soft table required in the SDK operation process is directly applied from the fixed memory, and the soft table does not need to be stored in the fixed memory from the real-time memory, so as to implement real-time synchronization of data.

The fixed memory is different from the system memory, exists independently of the system memory, and is managed independently. After the CPU is restarted, the contents of the fixed memory may remain unchanged. For example, if the software is upgraded or the CPU is abnormal, the data stored in the fixed memory will not be lost, and after the software is restarted, the data can be obtained from the fixed memory to restore the soft table. In specific implementation, the fixed memory includes various types of physical media memories, or a virtual address space formed by mapping files in a file system to user states through a Memory Map (MMAP). And the SDK executes the operation on the fixed memory, wherein the size of the fixed memory is more than or equal to the memory required by the operation of the SDK.

The initialization and application process of the fixed memory will be described below. First, the global variables of the present embodiment include:

(1) g _ start _ addr: fixed memory start addresses (virtual addresses in user space may be different, but all point to the same block of memory);

(2) ipuc _ app _ id: ipuc stores keys in fixed memory. Each soft table which needs to be stored in a fixed memory in real time is allocated with one app id;

(3) p _ ipuc _ app _ id _ node: a specific structure of a head node pointing to the fixed memory and storing IPUC information is shown as IPUC _ app _ id _ node in fig. 3;

(4) ipuc _ num: the number of routing entries supported by the current device;

(5) ipuc _ size: size of the structure ipuc _ info _ t.

After the routing device is cold started, the initialization process on the fixed memory comprises the following steps:

(1) during the cold boot process, the address is first shifted according to the number of routing entries and the current fixed memory.

p_ipuc_app_id_node＝g_start_addr；

start_addr+＝sizeof(ctc_wb_appid_t)；

start _ addr + (4) (ipuc _ num/32) (skip this segment of memory, which is used to store ipuc _ num divided into ipuc _ info memory, which part is currently used, assign to wb _ bmp).

(2) The p _ ipuc _ app _ id _ node is acquired, and the relevant field is assigned, and initialized as shown in the following code. Wherein wb _ bmp is used to indicate that ipuc _ num copies of ipuc _ info routing information are stored in the fixed memory, which are already used, store real routing information, which are currently empty and not used.

p_ipuc_app_id_node->app_id＝ipuc_app_id；

p_ipuc_app_id_node->entry_num＝ipuc_num；

p_ipuc_app_id_node->entry_size＝ipuc_size；

p _ ipuc _ app _ id _ node- > addr _ offset ═ p _ ipuc _ add _ id _ node-start _ addr (offset address);

p_ipuc_app_id_node->wb_bmp[ipuc_num/32]＝0；

start_addr+＝sizeof(ctc_wb_appid_t)；

start_addr+＝p_ipuc_app_id_node->entry_num*p_ipuc_add_id_node*entry_size。

(3) saving p _ ipuc _ app _ id _ node to g _ appid _ hash

malloc newhash node; (application from System memory)

Storing the p _ ipuc _ add _ id _ node into a system memory hash: g _ appid _ hash.

Step S102, storing the routing information generated by the upper layer in the soft table in real time;

and the routing related information is stored in the soft table. In this embodiment, the soft table storing the route is the key soft table, and as shown in step S101, the soft table is applied from the fixed memory. Other information, such as a linked list, an array, a hash and the like, which is used for connecting the routing information in series is also applied from the system memory.

In this embodiment, a specific execution process of creating a new route and applying a memory (i.e., the above-mentioned soft table) to store route information in the fixed memory includes:

(1) firstly, acquiring p _ ipuc _ appid _ node from g _ appid _ hash according to ipuc _ app _ id;

(2) acquiring an available memory from a fixed memory;

and traversing p _ ipuc _ appid _ node- > wb _ bmp, searching for the bit with the first 0 and the corresponding ipuc _ index according to the bit search.

p_ipuc_app_id_node->valid_cnt++；

p_ipuc_app_id_node->wb_bmp[ipuc_index/32]|＝p_ipuc_app_id_node->wb_bmp[ipuc_index％32]；

p_ipuc_info＝g_start_addr+p_ipuc_app_id_node->addr_offset+X*entry_size；

(3) Storing routing related information into p _ ipuc _ info

p_ipuc_info->ipda＝ipda；

p _ ipuc _ info- > mask ═ routing mask;

p _ ipuc _ info- > nexthop is the next hop exit.

(4) And storing the p _ ipuc _ info into a corresponding ipuc _ hash _ db table in the system memory.

And applying for a hash _ packet _ t node by using a system memory interface malloc.

hash_bucket_t->data＝p_ipuc_info；

hash_insert(ipuc_hash_db,p_ipuc_info)。

In a specific application, when a route is deleted, a corresponding memory needs to be synchronously released from a fixed memory, and a specific execution process is as follows:

(1) releasing p _ ipuc _ info from corresponding ipuc _ hash _ db table in system memory

hash_free(ipuc_hash_db,p_ipuc_info)；

(2) Firstly, acquiring p _ ipuc _ appid _ node from g _ appid _ hash according to ipuc _ app _ id;

(3) according to the p _ ipuc _ info address, the bit corresponding to the algorithm wb _ bmp is released;

ipuc_index＝(p_ipuc_info-g_start_addr-p_ipuc_app_id_node->addr_offset)/entry_size；

p_ipuc_app_id_node->wb_bmp[ipuc_index/32]^＝(1<<p_ipuc_app_id_node->wb_bmp[ipuc_index％32])；

p_ipuc_app_id_node->valid_cnt--。

in a specific application, when routing information is updated, a corresponding memory area in a fixed memory needs to be updated synchronously, and the specific implementation process is as follows:

(1) according to the routing information, searching p _ ipuc _ info from ipuc _ hash _ db;

ipuc_info.ipda＝ipda；

ipuc_info.masklen＝mask；

p_ipuc_info＝hash_lookup(ipuc_hash_db,&ipuc_info)。

(2) updating corresponding route egress information

p _ ipuc _ info- > nexthop _ id is the new next hop.

Step S103, an identification bit for identifying whether the hard table is configured is set in the generated routing information structure.

In the routing information structure of the embodiment of the present invention, the flag is set to 1 when the configuration of the hard table is not completed, and the flag is updated to be 0 and cleared after the configuration chip forwards the table entry to the hard table and the configuration is completed. By setting the identification bit for finishing the configuration of the hard table, whether the configuration of the hard table is finished can be judged, and the condition that the hard table and the soft table are inconsistent can be avoided.

And step S104, reconstructing the software state according to the routing information in the fixed memory during warm start.

When the routing module is started in a warm boot mode, the device does not configure the hard table at this time, but reconstructs only the soft table. The routing module obtains the address of the routing information storage through offset calculation according to the fixed memory address (namely, according to the routing information pointer in the fixed memory) transmitted by the warm boot initialization.

And judging whether a hard table is set in the routing information according to the identification bit in the routing information structure body. If the setting (the mark bit is 1 in the embodiment), it represents that the actual hard table is not issued to the chip, and the soft table information is deleted if the hard table and the soft table are inconsistent. If the identification bit is 0, the soft table is represented, the corresponding forwarding table entry exists, the processing is normal, and the reconstruction of the software state is completed.

Specifically, the operations after the hot-start routing table is rebuilt include:

(1) reconstructing a system g _ appid _ hash;

and g _ start _ addr according to the fixed memory.

And assigning a value to the g _ appid _ node, and calculating the size of the fixed memory occupied by the current g _ appid _ node according to the g _ appid _ node.

(2) When the routing module is initialized, the routing table item is rebuilt

Searching for a p _ ipuc _ app _ id _ node from the g _ appid _ hash for the first time;

traversing a loop p _ ipuc _ app _ id _ node- > wb _ bmp;

setting a bit in the corresponding wb _ bmp, and acquiring p _ ipuc _ info according to the address offset;

for(index＝0；index<p_ipuc_app_id_node->ipuc_num；index++)；

if(p_ipuc_app_id_node->wb_bmp[index/32]&(1<<

p_ipuc_app_id_node->wb_bmp[index％32]))

{

p_ipuc_info＝g_start_addr+p_ipuc_app_id_node->addr_offset+index*entry_size

hash _ bucket ═ malloc (sizeof (hash _ bucket _ t))// application from system memory

hash_bucket->data＝p_ipuc_info

hash_insert(ipuc_hash_db,p_ipuc_info)

}

According to the embodiment of the invention, the SDK soft table is directly applied from the fixed memory, so that real-time synchronization of data is realized, and the state before the CPU is suspended and dead can be completely recovered after sudden suspension and hot start in the running process of the CPU, thereby further improving the robustness of equipment and a network.

Example two

In order to solve the problems in the prior art, the present embodiment further discloses a hot start implementation apparatus, including:

the device comprises a setting unit, a memory area and a memory management unit, wherein the setting unit is used for applying for a memory area in a fixed memory; the memory area is used as a soft table for storing routing information;

the processing unit is used for storing the routing information generated by the upper layer in the soft table in real time; and setting an identification position for identifying whether the hard table is configured or not in the generated routing information structure body, and updating the identification position after the hard table is configured.

In a specific implementation, the processing unit is further configured to, when the hot boot is performed, analyze a storage address of the routing information in the memory area; judging whether the hard table configuration is finished or not according to the identification bit in the routing information structure body; and if the soft table is judged not to be completed, deleting the soft table.

In a specific implementation, the fixed memory includes a physical medium memory, or a virtual address space formed by mapping files in a file system to user states through a memory.

In a specific implementation, the SDK executes an operation on the fixed memory, and the size of the fixed memory is greater than or equal to a memory required by the SDK to operate.

In a specific implementation, the processing unit stores the routing information generated by the upper layer in the soft table in real time, including: when the routing information is updated, synchronously updating the routing information in the memory area; and releasing the memory area when the routing information is deleted.

It can be understood by those skilled in the art that the hot start implementation apparatus of embodiment 2 and the hot start implementation apparatus of embodiment 1 are based on the same inventive concept, and therefore, for the content of the related embodiments, reference may be made to the corresponding content in the foregoing, and details are not described here.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by associated hardware instructed by a program, which may be stored in a computer-readable storage medium, and the storage medium may include: ROM, RAM, magnetic or optical disks, and the like.

Although the present invention is disclosed above, the present invention is not limited thereto. Various changes and modifications may be effected therein by one skilled in the art without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (10)

1. A hot start implementation method is characterized by comprising the following steps:

applying for a memory area in the fixed memory; the memory area is used as a soft table for storing routing information;

storing the routing information generated by the upper layer in the soft table in real time;

and setting an identification position for identifying whether the hard table is configured or not in the generated routing information structure, and updating the identification position after the hard table is configured.

2. The warm-boot implementation method of claim 1, further comprising:

when the hot start is carried out, the storage address of the routing information in the memory area is analyzed;

judging whether the hard table configuration is finished or not according to the identification bit in the routing information structure body; and if the soft table is judged not to be completed, deleting the soft table.

3. A hot start implementation as claimed in claim 1,

the fixed memory comprises a physical medium memory or a virtual address space formed by mapping files in a file system to user states through the memory.

4. The method as claimed in claim 1, wherein the SDK performs the operation on the fixed memory, and the size of the fixed memory is greater than or equal to the memory required for the SDK to run.

5. The method of claim 1, wherein the storing the routing information generated by the upper layer in the soft table in real time comprises:

when the routing information is updated, synchronously updating the routing information in the memory area; and the number of the first and second groups,

and when the routing information is deleted, releasing the memory area.

6. A hot start enabling apparatus, comprising:

the device comprises a setting unit, a memory area and a memory management unit, wherein the setting unit is used for applying for a memory area in a fixed memory; the memory area is used as a soft table for storing routing information;

the processing unit is used for storing the routing information generated by the upper layer in the soft table in real time; and the number of the first and second groups,

and setting an identification position for identifying whether the hard table is configured or not in the generated routing information structure, and updating the identification position after the hard table is configured.

7. A hot start enabling device as defined in claim 6, wherein said processing unit is further configured to,

when the hot start is carried out, the storage address of the routing information in the memory area is analyzed;

judging whether the hard table configuration is finished or not according to the identification bit in the routing information structure body; and if the soft table is judged to be not complete, deleting the soft table.

8. A hot start enabling device as defined in claim 6,

the fixed memory comprises a physical medium memory or a virtual address space formed by mapping files in a file system to user states through the memory.

9. The apparatus of claim 6, wherein the SDK performs operations on the fixed memory, and wherein the size of the fixed memory is greater than or equal to a memory required for the SDK to run.

10. The apparatus as claimed in claim 6, wherein the processing unit stores the routing information generated by the upper layer in the soft table in real time includes:

when the routing information is updated, synchronously updating the routing information in the memory area; and the number of the first and second groups,

and releasing the memory area when the routing information is deleted.

Images