Hot start implementation method and device

Abstract

The present invention discloses a method and device for implementing hot start, wherein the method comprises: applying for a memory area in a fixed memory; the memory area is used as a soft table for storing routing information; the routing information generated by the upper layer is stored in the soft table in real time; in the generated routing information structure, a flag is set to identify whether the hard table is configured, and after the hard table is configured, the flag is updated. The device and method can solve the problem that the hot start may cause inconsistency between the soft and hard tables in the prior art.

Description

Technical Field

[0001] The invention relates to network communication technology, and in particular to a hot start implementation method and device. Background Art

[0002] Direct memory read and write warm boot (WarmBoot, WB) is to restart the device driver software while the hardware is running without interrupting data forwarding. It can be used in situations such as application software upgrades, driver upgrades, and software hang recovery. During the warm boot process, the software can re-establish the internal control state without affecting the forwarding layer through a special initialization sequence. In general, the establishment of the software internal state can be completed in the following ways:

[0003] Reconstruct the software state by directly reading registers and tables from the hardware. Before the chip supporting software SDK hot start, the data can be saved in a local disk file through the API, or stored in an external storage device specified by the upper user. When hot starting, read data from the external storage data source through the API to reconstruct the software state.

[0004] The most common hot start methods include:

[0005] (1) Before the system upgrade process, the running status related soft tables are synchronized to the preset database at one time, that is, the database mode. However, since it takes a long time to trigger a WarmBoot Sync to the database (maybe up to 10 minutes), and during this process, the upper-level users cannot issue new services, the database storage does not support timely or real-time updates of soft tables, and can only support functions such as planned software upgrades by users. In addition, since the database occupies a large amount of storage memory, and the memory of general embedded devices is limited, it is difficult to support the database mode in many cases, which limits its application;

[0006] (2) Regarding the database model issue, there is another method in current practical applications, that is, the user independently allocates a fixed memory, and the runtime data soft table is still requested from the system memory. The system periodically triggers the runtime data to be synchronized to the fixed memory. In this solution, since the soft table is directly stored in the memory, it only takes tens of milliseconds for the user to save the soft table of the relevant module. The upper-level user or SDK can periodically and actively trigger the soft table to be saved to the fixed memory.

[0007] The above method (2) solves the problem that some embedded devices do not support databases and need to be able to support timely synchronization scenarios. Since it is directly stored in the memory, reading and recovery are relatively fast, and the performance is better than database storage. However, there may still be a problem, that is, when storing data, the upper layer or SDK still needs to synchronize the soft table to the fixed memory regularly. If the soft table is changed but has not been synchronized to the fixed memory in time, if problems such as CPU hang occur at this time, the soft table data will be lost. After the hot start, it may cause inconsistency between the soft and hard tables. Summary of the invention

[0008] The technical problem to be solved by the embodiments of the present invention is how to solve the problem in the prior art that hot start may cause inconsistency between the soft and hard tables.

[0009] In order to solve the above technical problems, the present invention provides a hot start implementation method, which includes: applying for a memory area in a fixed memory; using the memory area as a soft table for storing routing information; storing the routing information generated by the upper layer in the soft table in real time; setting a flag bit in the generated routing information structure to identify whether the hard table has been configured, and updating the flag bit after the hard table has been configured.

[0010] The above-mentioned hot start implementation method further includes: when hot starting, analyzing the storage address of the routing information in the memory area; judging whether the hard table configuration is completed according to the identification bit in the routing information structure; if it is determined to be incomplete, deleting the soft table.

[0011] In the above-mentioned hot start implementation method, the fixed memory includes physical medium memory, or files in the file system are mapped to a virtual address space formed in user mode through memory.

[0012] In the above-mentioned hot start implementation method, the SDK performs operations 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.

[0013] In the above-mentioned hot start implementation method, the real-time storage of the routing information generated by the upper layer in the soft table includes: when the routing information is updated, the routing information in the memory area is synchronously updated; and when the routing information is deleted, the memory area is released.

[0014] In order to solve the above technical problems, the present invention provides a hot start implementation device, which includes: a setting unit, used to apply for a memory area in a fixed memory; the memory area is used as a soft table for storing routing information; a processing unit, used to store the routing information generated by the upper layer in the soft table in real time; and in the generated routing information structure, a flag is set to indicate whether the configuration of the hard table is completed, and the flag is updated after the configuration of the hard table is completed.

[0015] In the above-mentioned hot start implementation device, the processing unit is also used to, when hot starting, analyze the storage address of the routing information in the memory area; determine whether the hard table configuration is completed based on the identification bit in the routing information structure; if it is determined to be incomplete, delete the soft table.

[0016] In the above-mentioned hot start implementation device, the fixed memory includes physical medium memory, or a virtual address space formed by mapping files in the file system to the user state through memory.

[0017] In the above-mentioned hot start implementation device, the SDK performs operations 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.

[0018] The above-mentioned hot start implementation device, 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, the routing information in the memory area is synchronously updated; and when the routing information is deleted, the memory area is released.

[0019] The present invention aims at the problems in the prior art, and achieves the purpose of real-time synchronization by applying for an area in the fixed memory as an SDK soft table for storing routing information. This can avoid the need in the prior art to store the soft table from the real-time memory to the fixed memory. In the process of saving the final saved data to the database or the fixed memory, there is a transformation of the data structure in the middle, which requires a certain time to realize the data transformation, and then store it in the database or the fixed memory, etc. A series of processing operations. The present invention can realize real-time synchronization of data, and support the CPU operation process. Even if it suddenly hangs, it can be completely restored to the state before the CPU hangs after hot start. In addition, since the identification bit of whether the hard table is configured is set, it can be determined whether the hard table has been configured, and the inconsistency between the soft and hard tables can be avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is a schematic diagram of a flow chart of Embodiment 1 of the present invention;

[0021] Figure 2 is a flow chart of step S104 in embodiment 1 of the present invention;

[0022] Figure 3 It is a schematic diagram of the structure of the routing information header node in the fixed memory of embodiment 1 of the present invention. DETAILED DESCRIPTION

[0023] In the existing hot start method, in order to solve the problem of database mode, a fixed memory will be independently allocated for the user, and the runtime data soft table will still be requested from the system memory. The runtime data is triggered regularly in the system and synchronized to the fixed memory. In this solution, since the soft table is directly stored in the memory, it only takes tens of milliseconds for the user to save the soft table of the relevant module. The upper-level user or SDK can actively trigger the soft table to be saved in the fixed memory regularly. Although this method solves the problem that some embedded devices do not support databases and need to support timely synchronization scenarios, there may still be a problem, that is, when storing data, the upper layer or SDK still needs to synchronize the soft table to the fixed memory regularly. If it happens that the soft table is changed but has not been synchronized to the fixed memory in time, once problems such as CPU hang occur, the soft table data will be lost. After the hot start, there may be inconsistencies between the soft and hard tables.

[0024] In view of the problems in the prior art, the embodiments of the present invention achieve the purpose of real-time synchronization by applying for an area in the fixed memory as an SDK soft table for storing routing information. This can avoid the need in the prior art to store the soft table from the real-time memory to the fixed memory. In the process of saving the final saved data to the database or the fixed memory, there is a transformation of the data structure in the middle, which requires a certain amount of time to achieve the data transformation, and then store it in the database or the fixed memory, etc. A series of processing operations. The present invention can achieve real-time synchronization of data and support the CPU. Even if it suddenly hangs during operation, it can be completely restored to the state before the CPU hangs after hot start. In addition, since an identification bit is set to indicate whether the configuration of the hard table has been completed, it can be determined whether the configuration of the hard table has been completed, which can avoid the inconsistency between the soft and hard tables.

[0025] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0026] Example 1

[0027] A hot start implementation method of an embodiment of the present invention can be widely applied to all embedded devices, not limited to switching network devices. For the sake of convenience, this embodiment is described by taking a network routing device as an example. Specifically, the hot start implementation method includes:

[0028] Step S101, applying for a memory area in a fixed memory;

[0029] After the user creates a layer 3 route at the upper layer, execute step S101. The soft table of this embodiment refers to the maintenance table on the software, such as the soft layer 2 forwarding table, the soft layer 3 routing table, and the soft access control table, etc.; in contrast, the hard table refers to the maintenance table on the hardware, such as the chip layer 2 forwarding table entry, the chip layer 3 routing forwarding table entry, and the chip access control table, etc. The difference between this embodiment and the prior art is that the memory area is used as a soft table for storing routing information, that is, the soft table required by the SDK operation process is directly applied from the fixed memory, and there is no need to store the soft table from the real-time memory to the fixed memory, thereby realizing real-time synchronization of data.

[0030] The fixed memory is different from the system memory, exists independently of the system memory, and is managed separately. After the CPU is restarted, the content in the fixed memory can remain unchanged. For example, in the event of a software upgrade or CPU abnormality, the data saved in the fixed memory will not be lost. After the software is restarted, the data recovery soft table can also be obtained from the fixed memory. In a specific implementation, the fixed memory includes various types of physical media memory, or files in the file system are mapped to a virtual address space in the user state through memory mapping (MMAP). The SDK performs operations on the fixed memory, and the size of the fixed memory needs to be greater than or equal to the memory required for the SDK to run.

[0031] The following will describe the initialization and application process of fixed memory. First, the global variables of this embodiment include:

[0032] (1) g_start_addr: fixed memory start address (the virtual address in user space may be different, but it will point to the same memory block);

[0033] (2) ipuc_app_id: ipuc stores the key in fixed memory. Each soft table that needs to be stored in fixed memory in real time will be assigned an app id;

[0034] (3) p_ipuc_app_id_node: points to the head node storing IPUC information in fixed memory. The specific structure is as follows Figure 3 As shown in ipuc_app_id_node;

[0035] (4) ipuc_num: the number of routing entries supported by the current device;

[0036] (5)ipuc_size: the size of the structure ipuc_info_t.

[0037] When the router is cold-started, the initialization process on the fixed memory includes:

[0038] (1) During the cold start process, the number of routing entries and the current fixed memory offset address are first determined.

[0039] p_ipuc_app_id_node=g_start_addr;

[0040] start_addr+=sizeof(ctc_wb_appid_t);

[0041] start_addr+=4*(ipuc_num / 32) (skip this memory, this memory is used to save ipuc_num divided by ipuc_info memory, which part is currently in use and assigned to wb_bmp).

[0042] (2) Get p_ipuc_app_id_node, assign values ​​to related fields, and initialize related fields as shown in the following code. Among them, wb_bmp is used to indicate which of the ipuc_num copies of ipuc_info routing information are stored in fixed memory, which ones have been used and store real routing information, and which ones are currently empty and not used.

[0043] p_ipuc_app_id_node->app_id=ipuc_app_id;

[0044] p_ipuc_app_id_node->entry_num=ipuc_num;

[0045] p_ipuc_app_id_node->entry_size=ipuc_size;

[0046] p_ipuc_app_id_node->addr_offset=p_ipuc_add_id_node-start_addr (offset address);

[0047] p_ipuc_app_id_node->wb_bmp[ipuc_num / 32]=0;

[0048] start_addr+=sizeof(ctc_wb_appid_t);

[0049] start_addr+=p_ipuc_app_id_node->entry_num*p_ipuc_add_id_node*entry_si ze.

[0050] (3) Save the p_ipuc_app_id_node node to g_appid_hash

[0051] malloc new hash node; (request from system memory)

[0052] Store p_ipuc_add_id_node in system memory hash: g_appid_hash.

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

[0054] The routing related information is stored in the soft table. In this embodiment, the soft table storing the routing is a key soft table, as shown in step S101, which is applied from the fixed memory. Other information of the serialized routing information, such as linked lists, arrays, hashes, etc., is also applied from the system memory.

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

[0056] (1) First, get p_ipuc_appid_node from g_appid_hash according to ipuc_app_id;

[0057] (2) Obtain available memory from fixed memory;

[0058] Traverse p_ipuc_appid_node->wb_bmp, search by bit, find the first bit that is 0, and the corresponding ipuc_index.

[0059] p_ipuc_app_id_node->valid_cnt++;

[0060] p_ipuc_app_id_node->wb_bmp[ipuc_index / 32]|=p_ipuc_app_id_node->wb_bmp[ipuc_index%32];

[0061] p_ipuc_info=g_start_addr+p_ipuc_app_id_node->addr_offset+X*entry_size;

[0062] (3) Store routing information in p_ipuc_info

[0063] p_ipuc_info->ipda=ipda;

[0064] p_ipuc_info->masklen = routing mask;

[0065] p_ipuc_info->nexthop = next hop exit.

[0066] (4) Store p_ipuc_info in the corresponding ipuc_hash_db table in the system memory.

[0067] Use the system memory interface malloc to apply for a hash_bucket_t node.

[0068] hash_bucket_t->data=p_ipuc_info;

[0069] hash_insert(ipuc_hash_db,p_ipuc_info).

[0070] In a specific application, when a route is deleted, the corresponding memory needs to be released from the fixed memory synchronously. The specific execution process is as follows:

[0071] (1) Release p_ipuc_info from the corresponding ipuc_hash_db table in the system memory

[0072] hash_free(ipuc_hash_db,p_ipuc_info);

[0073] (2) First, from g_appid_hash, according to ipuc_app_id, obtain p_ipuc_appid_node;

[0074] (3) According to the address of p_ipuc_info, the corresponding bit of algorithm wb_bmp is released;

[0075] ipuc_index=(p_ipuc_info-g_start_addr-p_ipuc_app_id_node->addr_offset) / en try_size;

[0076] p_ipuc_app_id_node->wb_bmp[ipuc_index / 32]^=(1<<p_ipuc_app_id_node-> wb_bmp[ipuc_index%32]);

[0077] p_ipuc_app_id_node->valid_cnt--.

[0078] In a specific application, when updating routing information, the corresponding memory area in the fixed memory needs to be updated synchronously. The specific execution process is as follows:

[0079] (1) According to the routing information, find p_ipuc_info from ipuc_hash_db;

[0080] ipuc_info.ipda=ipda;

[0081] ipuc_info.masklen = mask;

[0082] p_ipuc_info=hash_lookup(ipuc_hash_db,&ipuc_info).

[0083] (2) Update the corresponding routing exit information

[0084] p_ipuc_info->nexthop_id = new next hop.

[0085] Step S103: In the generated routing information structure, a flag is set to indicate whether the hard table has been configured.

[0086] In the routing information structure of the embodiment of the present invention, the flag bit is set to 1 when the hard table configuration is not completed, and after the configuration chip and the forwarding table entry are configured to the hard table, the flag bit is updated to 0. By setting the flag bit indicating whether the hard table configuration is completed, it is possible to determine whether the hard table configuration is completed, thereby avoiding the inconsistency between the soft and hard tables.

[0087] Step S104, during hot start, the software state is rebuilt according to the routing information in the fixed memory.

[0088] When the routing module is started in hot boot mode, the device will not configure the hard table, but only reconstruct the soft table. The routing module obtains the address where the routing information is stored through offset calculation based on the fixed memory address entered by the hot boot initialization (i.e., based on the routing information pointer in the fixed memory).

[0089] According to the flag in the routing information structure, determine whether the hard table in the routing information is set. If it is set (the flag is 1 in this embodiment), it means that the actual hard table has not been sent to the chip, there is a phenomenon of inconsistency between the soft and hard tables, and the soft table information is deleted. If the flag is 0, it means that the corresponding forwarding table entry of the soft table exists, the processing is normal, and the reconstruction of the software state is completed.

[0090] Specifically, the above operations after the hot start routing table is rebuilt include:

[0091] (1) Rebuild the system g_appid_hash;

[0092] According to the fixed memory g_start_addr.

[0093] First assign a value to g_appid_node, and then calculate the fixed memory size currently occupied by g_appid_node based on g_appid_node.

[0094] (2) When the routing module is initialized, the routing table entries are rebuilt

[0095] First, find p_ipuc_app_id_node from g_appid_hash;

[0096] Traverse the loop p_ipuc_app_id_node->wb_bmp;

[0097] If the corresponding bit in wb_bmp is set, p_ipuc_info is obtained according to the address offset;

[0098] for(index=0; index<p_ipuc_app_id_node-> ipuc_num;index++);

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

[0100] p_ipuc_app_id_node->wb_bmp[index%32]))

[0101] {

[0102] p_ipuc_info=g_start_addr+p_ipuc_app_id_node->addr_offset+index*entry_si ze

[0103] hash_bucket = malloc (sizeof (hash_bucket_t)) / / apply from system memory

[0104] hash_bucket->data=p_ipuc_info

[0105] hash_insert(ipuc_hash_db,p_ipuc_info)

[0106] }

[0107] The embodiment of the present invention directly applies from the fixed memory through the SDK soft table, realizes real-time synchronization of data, supports the process of CPU running, and can completely restore to the state before the CPU hangs up after sudden hang up and hot restart, thereby further improving the robustness of the device and the network.

[0108] Embodiment 2

[0109] In order to solve the problems in the prior art, this embodiment further discloses a hot start implementation device, including:

[0110] A setting unit is used to apply for a memory area in a fixed memory; the memory area is used as a soft table for storing routing information;

[0111] The processing unit is used to store the routing information generated by the upper layer in the soft table in real time; and, in the generated routing information structure, set a flag for identifying whether the hard table is configured, and update the flag after the hard table is configured.

[0112] In a specific implementation, the processing unit is also used to, when hot starting, analyze the storage address of the routing information in the memory area; determine whether the hard table configuration is completed based on the identification bit in the routing information structure; if it is determined to be incomplete, delete the soft table.

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

[0114] In a specific implementation, the SDK performs operations 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.

[0115] 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 when the routing information is deleted, releasing the memory area.

[0116] Those skilled in the art can understand that the hot start implementation device of the second embodiment and the hot start implementation method of the first embodiment are based on the same inventive concept, so the contents of the relevant embodiments can be referred to the corresponding contents in the previous text and will not be repeated here.

[0117] A person skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the relevant hardware through a program, and the program can be stored in a computer-readable storage medium, which can include: ROM, RAM, disk or CD, etc.

[0118] Although the present invention is disclosed as above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the scope defined by the claims.

Claims

1. A hot start implementation method, characterized in that: include: Allocate a memory area in fixed memory; The memory area is used as a soft table for storing routing information; The routing information generated by the upper layer is stored in the soft table in real time; In the generated routing information structure, a flag is set to indicate whether the hard table has been configured, and after the hard table has been configured, the flag is updated; the method further includes: When hot starting, analyzing the storage address of the routing information in the memory area; According to the identification bit in the routing information structure, it is determined whether the hard table configuration is completed; if it is determined to be incomplete, the soft table is deleted.

2. The hot start implementation method according to claim 1, characterized in that: The fixed memory includes physical medium memory, or a virtual address space formed by mapping files in a file system to a user state through memory mapping.

3. The hot start implementation method according to claim 1, characterized in that: The SDK performs operations 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.

4. The hot start implementation method according to claim 1, characterized in that: The real-time storage of the routing information generated by the upper layer in the soft table includes: When the routing information is updated, the routing information in the memory area is synchronously updated; and, When the routing information is deleted, the memory area is released.

5. A hot start implementation device, characterized in that: include: A setting unit, used for applying for a memory area in a fixed memory; The memory area is used as a soft table for storing routing information; A processing unit, used for storing the routing information generated by the upper layer in the soft table in real time; as well as, In the generated routing information structure, a flag is set to indicate whether the hard table has been configured, and after the hard table has been configured, the flag is updated; When hot starting, analyzing the storage address of the routing information in the memory area; According to the identification bit in the routing information structure, it is determined whether the hard table configuration is completed; if it is determined to be incomplete, the soft table is deleted.

6. The hot start implementation device according to claim 5, characterized in that: The fixed memory includes physical medium memory, or a virtual address space formed by mapping files in a file system to a user state through memory mapping.

7. The hot start implementation device according to claim 5, characterized in that: The SDK performs operations 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.

8. The hot start implementation device according to claim 5, characterized in that: 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, the routing information in the memory area is synchronously updated; and, When the routing information is deleted, the memory area is released.

Images