Unified adaptation method for multi-vendor switches and SDN controller

Abstract

This application provides a unified adaptation method for multi-vendor switches and an SDN controller, including: allocating CMA physical pages for each switch model; establishing a model page table and a shadow bitmap byte array; the model page table records the CMA physical page base address of the switch model; and each bit of each byte in the array represents the existence status of the encoding / decoding context of each firmware version within the corresponding CMA physical page; when an encoding / decoding context of a firmware version for a switch model is generated, it is written to the corresponding slot in the CMA physical page, and the corresponding bit is set to valid; in response to a packet from the target switch, the model identifier and firmware version number are extracted; the target CMA physical page base address is obtained from the model page table based on the model identifier, the firmware version number is read from the shadow bitmap byte array, and the context address is calculated to obtain the encoding / decoding context. This application can avoid memory fragmentation, ensure the resident nature of the context in memory, and achieve fast context determination and latency addressing.

Description

Technical Field

[0001] This application belongs to the field of software-defined network controllers, and in particular relates to a unified adaptation method for multi-vendor switches and an SDN controller. Background Technology

[0002] Software-defined network controllers (SDN controllers) need to interface with numerous switch models from different manufacturers, and the same model may have multiple firmware versions. Each model-version combination corresponds to an independent YANG model encoding / decoding context. Existing adaptation solutions typically allocate memory blocks independently for each context and use hash tables to maintain the mapping relationship from model and version to context addresses.

[0003] The above method has many drawbacks in actual operation, including but not limited to: First, the independent allocation and release of a large number of small memory blocks can easily lead to memory fragmentation, and the hash table itself also occupies additional storage space; Second, for each packet processed by the data plane, it is necessary to go through steps such as hash function calculation and bucket linked list traversal to obtain the context address, which involves multiple memory accesses and pointer jumps, resulting in high addressing latency with significant fluctuations, making it difficult to meet deterministic latency requirements in high-throughput scenarios such as 100G line speed; Third, the encoding and decoding context is stored in general kernel memory, which faces the risk of being reclaimed or swapped out of memory. Once the context is lost, it will directly lead to the interruption of management services for the corresponding switch model and version.

[0004] Therefore, when it is necessary to adapt to a large number of switch models and firmware versions at the same time, how to avoid memory fragmentation and additional mapping overhead, while achieving fast context determination, latency addressing and stable dwell, has become a technical problem to be solved. Summary of the Invention

[0005] This application aims to provide a unified adaptation method and SDN controller for multi-vendor switches, so as to avoid memory fragmentation and additional mapping overhead, and achieve fast context determination, latency addressing and stable dwell when a large number of switch models and firmware versions need to be adapted.

[0006] This application discloses a unified adaptation method for multi-vendor switches, applicable to SDN controllers, including: Assign CMA physical pages to each switch model, establish a model page table indexed by the switch model, the table entries of the model page table record the base address of the CMA physical page corresponding to the switch model, and create a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with the CMA physical page. Each bit of each byte in the shadow bitmap byte array represents the existence state of the encoding and decoding context of each firmware version divided by fixed slots within the corresponding CMA physical page. When a codec context for a firmware version of a switch model is generated, the codec context is written into the slot corresponding to the firmware version number of the firmware version in the CMA physical page corresponding to the switch model, and the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array is set to the valid state. In response to receiving a message from the target switch, the model identifier and firmware version number of the target switch are extracted. The target CMA physical page base address is obtained from the model page table based on the model identifier, and the corresponding byte is read from the shadow bitmap byte array. Based on the state of the bit corresponding to the firmware version number in the corresponding byte, if it is determined that the context address exists, the context address is calculated based on the target CMA physical page base address and the firmware version number. The encoding and decoding context obtained by the context address is used to perform adaptation processing on the message.

[0007] Optionally, the process of allocating CMA physical pages to each switch model and establishing a model page table indexed by the switch model includes: Through the DMA allocation interface, a separate CMA physical page is allocated for each switch model from the reserved CMA area; The base address of the CMA physical page is used as a table entry, and the model identifier of the switch model is used as an index to store it in the model page table.

[0008] Optionally, the step of creating a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with a CMA physical page includes: Based on the total number of physical pages contained in the reserved CMA region, a byte array is allocated as a shadow bitmap, and the index of the shadow bitmap is consistent with the page index of the CMA physical page; Load the starting address of the shadow bitmap into the eBPF mapping.

[0009] Optionally, the step of writing the encoding / decoding context into the slot corresponding to the firmware version number in the CMA physical page corresponding to the switch model, and setting the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array to a valid state includes: Based on the firmware version number of the firmware version, determine the corresponding slot offset within the CMA physical page; Copy the encoding / decoding context to the location indicated by the slot offset; Atomic bit operations are performed on the corresponding bytes in the shadow bitmap byte array to set the bit corresponding to the firmware version number.

[0010] Optionally, performing atomic bit operations on the corresponding bytes in the shadow bitmap byte array includes: Using an atomic OR operation, the mask obtained by left-shifting the firmware version number bit by a value of 1 is bitwise ORed with the corresponding byte.

[0011] Optionally, in response to receiving a message from the target switch, the following steps are performed: extracting the model identifier and firmware version number of the target switch; obtaining the target CMA physical page base address from the model page table based on the model identifier; reading the corresponding byte from the shadow bitmap byte array; calculating the context address based on the target CMA physical page base address and the firmware version number when its existence is determined according to the state of the bit corresponding to the firmware version number in the corresponding byte; and performing adaptation processing on the message using the encoding / decoding context obtained from the context address. The model identifier and firmware version number are extracted from the fixed offset of the message using the eBPF program; The target CMA physical page base address is obtained by querying the eBPF mapping using the model identifier as the key, and the bytes corresponding to the target switch model are read from the shadow bitmap byte array. Detect whether the bit in the byte corresponding to the firmware version number is set; When the bit is set, the target CMA physical page base address is added to the slot offset corresponding to the firmware version number to obtain the context address; Access the encoding / decoding context based on the context address, and perform encoding / decoding adaptation on the message.

[0012] Optionally, detecting whether the bit corresponding to the firmware version number in the byte is set includes: Perform a bitwise AND operation between the byte and a mask, which is obtained by left-shifting 1 by the firmware version number. If the bitwise AND result is non-zero, then the bit is set.

[0013] Optional, also includes: Record the access time of each slot. For slots that have not been accessed for more than a preset time, clear the corresponding bits in the shadow bitmap byte array.

[0014] Optional, also includes: In response to the detection of a DMA release event of the target CMA physical page, the encoding and decoding context of each valid slot in the target CMA physical page is backed up to the user-space buffer before release. After the target CMA physical page is reallocated, the backed-up codec context is restored to the corresponding slot of the newly allocated CMA physical page, and the corresponding bit state in the shadow bitmap byte array is restored.

[0015] This application also discloses an SDN controller, comprising: The memory management module is used to allocate CMA physical pages for each switch model, establish a model page table indexed by the switch model, and create a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with the CMA physical page. Each bit of each byte in the shadow bitmap byte array represents the existence state of the encoding and decoding context of each firmware version divided by fixed slots within the corresponding CMA physical page. The context loading module is used to write the codec context into the slot corresponding to the firmware version number of the firmware version in the CMA physical page corresponding to the switch model when the codec context of a firmware version of a switch model is generated, and to set the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array to a valid state. The data plane query module is used to respond to a received packet from a target switch by extracting the target switch's model identifier and firmware version number, obtaining the target CMA physical page base address from the model page table based on the model identifier, reading the corresponding byte from the shadow bitmap byte array, and calculating the context address based on the state of the bit corresponding to the firmware version number in the corresponding byte, and using the encoding / decoding context obtained from the context address to perform adaptation processing on the packet.

[0016] As can be seen from the above technical solution, this invention, by allocating a dedicated CMA physical page for each switch model and using fixed slot partitioning, aggregates the encoding and decoding contexts of all firmware versions of the same model into the same non-swapable physical page memory. This avoids memory fragmentation caused by independent small memory allocation at the physical carrier level and ensures the resident nature of the context in memory. Simultaneously, the independently created shadow bitmap byte array corresponds one-to-one with the CMA physical page, with each bit of each byte directly marking the existence status of each version slot within the corresponding page. This achieves isolation between state maintenance and the kernel CMA allocation bitmap, preventing interference with kernel memory management logic. In the data path of packet adaptation, after the eBPF program extracts the packet's model identifier and firmware version number, it first queries using the model identifier. The model page table obtains the physical base address of the exclusive page for that model, and simultaneously reads the corresponding byte from the shadow bitmap. Then, it can directly determine whether the version context exists through single-bit detection. Once confirmed, it uses the fixed offset relationship between the firmware version number and the preset slot size to directly obtain the context address through a shift and addition operation. Then, it uses this address to access the context and perform encoding and decoding adaptation on the message. The whole process only involves two memory reads of the model page table and the shadow bitmap, as well as a small number of arithmetic instructions. No hash calculation, linked list traversal, or locking operations are required. Moreover, the page table and shadow bitmap are extremely small in size and can reside in the processor cache. Therefore, the addressing latency is low and highly deterministic. There is no tail latency jitter under high concurrency. The adaptation efficiency and stability are significantly improved compared with the existing hash mapping scheme. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart of an embodiment of the multi-vendor switch unified adaptation method provided in this application; Figure 2 The flowchart provided in this application illustrates the allocation of CMA physical pages to each switch model and the creation of a model page table indexed by the switch model. Figure 3 A flowchart for creating a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with a CMA physical page, as provided in this application; Figure 4 The flowchart of S200 provided for this application; Figure 5 The flowchart of S300 provided in this application; Figure 6 The structural block diagram of the SDN controller provided in this application. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0020] Please refer to Figure 1 , Figure 1 This is a flowchart of an embodiment of the multi-vendor switch unified adaptation method of this application. This method is applicable to SDN controllers, such as... Figure 1 As shown, it includes the following steps: S100: Allocate CMA physical pages for each switch model, establish a model page table indexed by the switch model, the table entries of the model page table record the base address of the CMA physical page corresponding to the switch model, and create a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with the CMA physical page. Each bit of each byte in the shadow bitmap byte array represents the existence state of the encoding and decoding context of each firmware version divided by fixed slots within the corresponding CMA physical page.

[0021] In SDN controllers, a CMA physical page refers to a contiguous block of physical memory allocated from a CMA region. The CMA region is a reserved contiguous physical memory area within the operating system kernel, managed by a dedicated memory allocator. It primarily serves devices requiring contiguous physical address space. In SDN controller applications, the encoding / decoding context needs to be accessed quickly and reliably; therefore, storing it in a contiguous memory area provides better performance and reliability. The size of the contiguous memory area can be configured based on the number of switch models to be supported. Typically, each switch model corresponds to one physical page of contiguous memory space, i.e., one CMA physical page. The size of the physical page is determined by the system architecture, with a common size being 4,000 bytes. For scenarios requiring support for 256 switch models, reserving one megabyte of contiguous memory space is sufficient.

[0022] In this embodiment, the model page table is a data structure used to store the mapping relationship between switch models and their corresponding CMA physical page base addresses. The model page table uses the switch model identifier as an index, and each entry corresponding to the index stores the physical base address of the CMA physical page allocated to that switch model, i.e., the CMA physical page base address. The switch model identifier can be any numerical value or string that uniquely identifies the switch model. In actual implementations, the switch model string is usually converted into a fixed-length integer identifier for use as an array index. The size of the model page table is the same as the number of switch models that need to be adapted. For a scenario with 256 switch models, the model page table contains 256 entries, each storing a physical address. In a 64-bit system, each entry occupies eight bytes, therefore the model page table occupies a total of 2048 bytes of memory space.

[0023] By aggregating and storing the codec contexts of all firmware versions of the same model within the same CMA physical page, memory fragmentation can be reduced compared to the prior art method of allocating memory blocks independently for each context. In the prior art, the independent allocation and release of a large number of small memory blocks leads to the fragmentation of memory space into many discontinuous small blocks. Memory fragmentation reduces memory utilization and may result in insufficient contiguous space when large blocks of contiguous memory need to be allocated. In this embodiment, however, memory allocation is at the physical page level, each physical page is contiguous, and is not frequently allocated and released, thus effectively reducing memory fragmentation.

[0024] The shadow bitmap byte array is a byte array of the same length as the number of CMA physical pages, with each byte of the shadow bitmap corresponding to one CMA physical page. Each byte contains eight bits, and each bit is used to indicate the presence status of a slot within the corresponding CMA physical page. When a bit is set to one, it indicates that a valid codec context has been stored in the slot corresponding to that bit; when a bit is set to zero, it indicates that a valid codec context has not been stored in the slot corresponding to that bit. The length of the shadow bitmap byte array is equal to the total size of the contiguous memory area divided by the size of the physical page. For a contiguous memory area of ​​one megabyte and a physical page of four thousand bytes, the length of the shadow bitmap byte array is two hundred and fifty-six bytes.

[0025] Specifically, the slot partitioning within a CMA physical page divides each physical page into multiple fixed-size storage areas. Each storage area stores the codec context corresponding to a firmware version. The number of slots determines the maximum number of firmware versions that each switch model can support, while the slot size is determined by the typical size of the codec context. In practical applications, the codec context typically contains path mapping information for the YANG model, data type definitions, codec rules, etc., and its size is usually between 256 and 480 bytes. Therefore, dividing each physical page into eight slots, each slot being 512 bytes in size, satisfies the storage needs of most codec contexts without causing excessive memory waste. The offset of each slot within the physical page can be calculated by multiplying the version number by the slot size. For a firmware version with version number n, the corresponding slot offset is n multiplied by 512 bytes. In existing technologies, memory blocks are allocated independently for each context, requiring memory allocation based on the actual size of each context. This results in small-granularity memory allocation and is prone to memory fragmentation. In this embodiment, the slot size is fixed and the granularity of memory allocation is the slot. Although there may be a small amount of memory waste, it can effectively reduce the generation of memory fragmentation and simplify the complexity of memory management.

[0026] In this embodiment, a separate shadow bitmap byte array is used to record the version existence status. Compared with the prior art's method of using hash tables to maintain mapping relationships, this reduces additional memory overhead. In the prior art, hash tables need to store key-value pairs. Each key-value pair, in addition to storing the context address, also needs to store model and version information, as well as pointers to hash collision chains and other additional information. This additional information consumes a large amount of memory space, especially when adapting to a large number of switch models and firmware versions, where the memory overhead of the hash table becomes very large. In this embodiment, however, the size of the shadow bitmap byte array is only the same as the number of CMA physical pages, with each physical page corresponding to one byte, thus the memory overhead is very small. For example, for 256 physical pages, the shadow bitmap byte array only occupies 256 bytes of memory space.

[0027] S200: When a codec context for a firmware version of a switch model is generated, the codec context is written into the slot corresponding to the firmware version number of the firmware version in the CMA physical page corresponding to the switch model, and the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array is set to a valid state.

[0028] Specifically, the codec context is a data structure used to parse and generate protocol messages sent and received by the switch. Switches from different manufacturers, models, and firmware versions typically use different protocol models and data structures, therefore a corresponding codec context needs to be generated for each model and version. The codec context is usually generated by the user-space management program based on the switch's YANG model file. The generated codec context needs to be loaded into the kernel space so that data plane programs can access it quickly.

[0029] In this embodiment, a separate physical page is allocated for each switch model from the reserved CMA area via the DMA allocation interface. The physical base address of the physical page is used as an entry, and the identifier of the switch model is used as an index to store it in the model page table.

[0030] S300, in response to receiving a message from the target switch, extract the model identifier and firmware version number of the target switch, obtain the target CMA physical page base address from the model page table according to the model identifier, read the corresponding byte from the shadow bitmap byte array, and calculate the context address based on the target CMA physical page base address and the firmware version number when it is determined that the context address is present, according to the state of the bit corresponding to the firmware version number in the corresponding byte, and use the encoding and decoding context obtained by the context address to perform adaptation processing on the message.

[0031] Compared with related technologies, this disclosure allocates a dedicated CMA physical page for each switch model and uses fixed slot partitioning, aggregating the encoding and decoding contexts of all firmware versions of the same model into the same non-swapable physical page memory. This avoids memory fragmentation caused by independent small memory allocations at the physical carrier level and ensures the resident nature of the context in memory. Simultaneously, an independently created shadow bitmap byte array corresponds one-to-one with the CMA physical page, with each bit of each byte directly marking the existence status of each version slot within the corresponding page. This achieves isolation between state maintenance and the kernel CMA allocation bitmap, preventing interference with kernel memory management logic. In the data path of packet adaptation, after the eBPF program extracts the packet's model identifier and firmware version number, it first queries the model identifier. The model page table obtains the physical base address of the exclusive page for that model, and simultaneously reads the corresponding byte from the shadow bitmap. Then, it can directly determine whether the version context exists through single-bit detection. Once confirmed, it uses the fixed offset relationship between the firmware version number and the preset slot size to directly obtain the context address through a shift and addition operation. Then, it uses this address to access the context and perform encoding and decoding adaptation on the message. The whole process only involves two memory reads of the model page table and the shadow bitmap, as well as a small number of arithmetic instructions. No hash calculation, linked list traversal, or locking operations are required. Moreover, the page table and shadow bitmap are extremely small in size and can reside in the processor cache. Therefore, the addressing latency is low and highly deterministic. There is no tail latency jitter under high concurrency. The adaptation efficiency and stability are significantly improved compared with the existing hash mapping scheme.

[0032] Furthermore, in this embodiment, each switch model occupies a dedicated CMA physical page, and the codec contexts of different models are stored in different physical pages, preventing interference between them. In existing technologies, codec contexts of different models may be stored in adjacent memory blocks. If a memory out-of-bounds error occurs in one context, it may corrupt the data of other contexts, leading to system crashes. In this embodiment, however, each physical page is independent and has a memory protection mechanism; an error within one physical page will not affect the data in other physical pages, thus improving system reliability. Simultaneously, the shadow bitmap is completely independent of the kernel's contiguous memory allocation bitmap; any modification to the shadow bitmap will not affect the kernel's memory management logic. In existing technologies, directly modifying the kernel's memory management data structure may lead to kernel crashes or other unpredictable problems. In this embodiment, the shadow bitmap is an independent data structure managed by the kernel module of this application, and it will not conflict with other parts of the kernel, thus improving system stability and compatibility.

[0033] In one embodiment, such as Figure 2 As shown, the process of allocating CMA physical pages to each switch model and establishing a model page table indexed by the switch model includes: The S110 allocates an independent CMA physical page for each switch model from the reserved CMA area via the DMA (Direct Memory Access) allocation interface.

[0034] The DMA allocation interface is a standard interface provided by the operating system kernel for allocating contiguous physical memory. Memory allocated through the DMA allocation interface is physically address-contiguous and is not used by the kernel's regular memory allocator, thus ensuring memory stability and predictability. In this embodiment, using the DMA allocation interface to allocate physical pages from the CMA region ensures that each switch model obtains an independent, physically address-contiguous memory region for storing the codec context of all firmware versions for that model.

[0035] For example, when a CMA physical page needs to be allocated for a specific switch model, the kernel management module calls the DMA allocation interface, specifying the required memory size as the size of one physical page. The Direct Memory Access Allocator searches for a free physical page in the reserved CMA region and returns the physical base address of that page to the kernel management module. The kernel management module stores this physical base address in the model page table, using the switch model identifier as an index. If there are not enough free physical pages in the CMA region, the DMA allocation interface returns an error. The kernel management module can then handle the error accordingly, such as releasing some long-unused physical pages or prompting the user to increase the reserved size of the contiguous memory region.

[0036] S120, the CMA physical page base address of the CMA physical page is used as a table entry, and the model identifier of the switch model is used as an index to store it in the model page table.

[0037] The initialization of the model page table typically occurs during kernel module loading. The kernel module first reads the configuration file or obtains a list of switch models requiring adaptation from the user-space management program. Then, for each switch model, it calls the DMA allocation interface to allocate physical pages and stores the physical base address (i.e., the CMA physical page base address) in the model page table. For new switch models added during system operation, the kernel management module can dynamically allocate physical pages for them and update the model page table. The model page table is usually implemented as an array, where the array index corresponds to the switch model identifier, and the array elements correspond to the physical page base addresses. This implementation makes model page table lookups highly efficient, requiring only a single array index operation to retrieve the corresponding physical page base address.

[0038] In some embodiments, the DMA allocation interface also provides the function of releasing physical pages. When a switch model no longer needs to be adapted, the kernel management module can call the DMA release interface to release the physical pages corresponding to that model. The released physical pages are returned to the contiguous memory allocator and can be reassigned to other switch models. Before releasing the physical pages, the kernel management module needs to ensure that all encoding / decoding contexts within the physical page have been backed up or are no longer needed, and needs to clear all bits of the corresponding byte in the shadow bitmap to avoid subsequent erroneous access.

[0039] Optional, such as Figure 3 As shown, the creation of a shadow bitmap byte array, independent of the CMA allocation bitmap and corresponding one-to-one with a CMA physical page, includes: S130, based on the total number of physical pages contained in the reserved CMA region, allocate a byte array as a shadow bitmap, wherein the index of the shadow bitmap is consistent with the page index of the CMA physical page.

[0040] The creation of the shadow bitmap typically occurs during kernel module initialization. The kernel module first obtains the total size of the reserved CMA region and then calculates the total number of physical pages contained within that region. The total number of physical pages equals the total size of the contiguous memory region divided by the physical page size. The kernel module allocates a byte array based on the total number of physical pages, with the length of the byte array equal to the total number of physical pages. Each byte is initialized to zero, indicating that no slots within any physical page store a valid codec context.

[0041] For example, there is a one-to-one correspondence between the index of the shadow bitmap and the page index of the CMA physical page. The first physical page in the CMA region corresponds to the first byte of the shadow bitmap, the second physical page corresponds to the second byte of the shadow bitmap, and so on. This one-to-one correspondence allows the corresponding byte in the shadow bitmap to be located directly using the physical page index, without the need for additional mapping relationships. The physical page index can be calculated from the base address of the physical page; the physical page index equals the physical page base address divided by the physical page size.

[0042] S140, the starting address of the shadow bitmap is loaded into the extended Berkeley Packet Filter (eBPF) mapping.

[0043] eBPF mapping is a mechanism for sharing data between kernel space and user space. eBPF mapping supports various types, including array mapping, hash mapping, and queue mapping. In this embodiment, both the model page table and the shadow bitmap need to be accessed by the eBPF program, therefore their starting addresses need to be loaded into the eBPF mapping. Typically, an array mapping is used to store the starting addresses of the model page table and the shadow bitmap. The array mapping uses fixed indices, allowing the eBPF program to retrieve the starting addresses of the model page table and the shadow bitmap using these fixed index values.

[0044] Furthermore, after loading the starting address of the shadow bitmap into the eBPF mapping, eBPF programs can directly access the contents of the shadow bitmap. An eBPF program can calculate the address of the corresponding byte in the shadow bitmap using the physical page index, then read the content of that byte to determine if a specific version of the codec context exists. Because the shadow bitmap is very small, typically only a few hundred bytes, its contents can easily reside in the processor's cache, making access to the shadow bitmap by eBPF programs very fast.

[0045] In this embodiment, the model page table and shadow bitmap are loaded into the eBPF mapping, enabling the eBPF program to directly access these data structures and complete context addressing operations on the data plane. In existing technologies, context addressing is typically performed in user space, requiring packets to be copied from kernel space to user space for addressing and processing, and then copied back to kernel space, resulting in significant performance overhead. However, in this embodiment, the context addressing operation is performed within the eBPF program in kernel space, eliminating the need to copy packets to user space. This reduces data copying overhead and improves system processing performance.

[0046] Optional, please refer to Figure 4 , Figure 4 The flowchart of S200 provided for this application, such as Figure 4 As shown, the step of writing the encoding / decoding context into the slot corresponding to the firmware version number in the CMA physical page corresponding to the switch model, and setting the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array to a valid state includes: S210, determine the corresponding slot offset within the CMA physical page based on the firmware version number of the firmware version.

[0047] The slot offset is calculated based on the firmware version number and the slot size. The slot size is a pre-defined fixed value; in this embodiment, the slot size is 512 bytes. Therefore, the slot offset corresponding to firmware version number n is n multiplied by 512 bytes. For example, the slot offset corresponding to firmware version number zero is zero bytes, the slot offset corresponding to firmware version number one is 512 bytes, the slot offset corresponding to firmware version number two is 1024 bytes, and so on.

[0048] S220, copy the encoding / decoding context to the position indicated by the slot offset.

[0049] For example, after the user-space management program generates a codec context for a specific switch model and firmware version, it sends the codec context to the kernel management module. The kernel management module first retrieves the corresponding CMA physical page base address from the model page table based on the switch model identifier, and then calculates the slot offset based on the firmware version number. The kernel management module then copies the codec context from user-space to the corresponding slot position of the CMA physical page in kernel space. After the copy is complete, the kernel management module needs to update the shadow bitmap, setting the bit corresponding to the version number in the corresponding byte to one, indicating that a valid codec context has been stored in that slot.

[0050] In this embodiment, the codec context is stored in CMA physical pages, which improves the stability of context storage compared to the prior art method of storing it in general kernel memory. In the prior art, general kernel memory is reclaimed by the kernel's memory reclamation mechanism or swapped to disk. If the codec context is reclaimed or swapped out, it will cause the management services of the corresponding switch model to be interrupted. However, CMA physical pages are managed by a dedicated allocator and are not used by the regular memory allocator, nor are they reclaimed or swapped to disk by the kernel's memory reclamation mechanism. Therefore, the resident nature of the codec context in memory can be guaranteed, improving system stability.

[0051] Furthermore, the address of the encoding / decoding context is the physical page base address plus the slot offset corresponding to the firmware version number. Compared with the existing method of looking up the context address using a hash table, this improves addressing efficiency and ensures deterministic addressing latency. In existing technologies, hash table lookups require steps such as calculating hash values, locating hash buckets, and traversing the collision list. These steps involve multiple memory accesses and pointer jumps, resulting in high addressing latency, which fluctuates significantly due to hash collisions. In this embodiment, however, the calculation of the context address requires only one addition and one shift operation, both highly efficient and completed in a very short time. Moreover, since all operations are fixed, the addressing latency is deterministic and will not fluctuate due to increased concurrency or other factors.

[0052] S230, perform atomic bit operations on the corresponding byte in the shadow bitmap byte array to set the bit corresponding to the firmware version number.

[0053] Specifically, atomic bit operations are operations that ensure the correctness of results in a multi-processor concurrent environment. In a multi-processor system, multiple processors may operate on the same memory location simultaneously. Without atomic operations, inconsistent results may occur. In this embodiment, multiple firmware versions may be accessed simultaneously, therefore atomic bit operations are needed to update the shadow bitmap to avoid errors in the shadow bitmap state caused by concurrent operations. Atomic bit operations include atomic set operations, atomic clear operations, and atomic test and set operations. In this embodiment, atomic set operations are used to set the corresponding bit of the corresponding byte in the shadow bitmap to one.

[0054] Compared to related technologies, the embodiments of this application use atomic bit operations to update the shadow bitmap, which can guarantee the correctness of the operation results in a multi-processor concurrent environment. In the prior art, hash table updates usually require the use of locks to ensure concurrency safety. The use of locks incurs additional overhead and may lead to lock contention in high-concurrency situations, reducing system performance. Atomic bit operations, on the other hand, are implemented based on the processor's atomic instructions and do not require locks. Therefore, they can avoid the performance loss caused by lock contention and improve the system's concurrent processing capabilities.

[0055] Furthermore, during the copying of the codec context to the CMA physical page, the integrity and correctness of the copy operation must be ensured. The kernel management module can use memory copy functions to copy the codec context from user space to kernel space. After the copy is complete, the kernel management module can verify the copied content to ensure that it matches the content sent by the user-space management program. If the verification fails, the kernel management module can either re-perform the copy operation or return an error message to the user-space management program.

[0056] Optionally, performing atomic bit operations on the corresponding byte in the shadow bitmap byte array includes: using an atomic OR operation to perform a bitwise OR operation on the mask obtained by left-shifting the value of 1 by the version number bit and the corresponding byte.

[0057] The atomic OR operation is a type of atomic bitwise operation that performs a bitwise OR operation between the content of a specified memory location and a given mask, and stores the result back to the original memory location. The atomic OR operation ensures that in a multiprocessor concurrent environment, multiple concurrent OR operations will not interfere with each other, and the result will be correct.

[0058] In this embodiment, using atomic OR operations to update the shadow bitmap ensures that the state of the shadow bitmap will not be incorrect when multiple firmware versions are accessed simultaneously.

[0059] For example, when it's necessary to set the nth bit of a byte in the shadow bitmap to one, a mask is first generated. The mask value is one shifted left by n bits. For instance, when n is zero, the mask value is one, represented in binary as 00000001; when n is one, the mask value is two, represented in binary as 00000010; when n is two, the mask value is four, represented in binary as 00000100, and so on. Then, a bitwise OR operation is performed between the current value of the corresponding byte in the shadow bitmap and the mask. The result of this operation sets the nth bit of that byte to one, while the other bits remain unchanged.

[0060] Specifically, the implementation of atomic OR operations typically relies on atomic instructions provided by the processor. Different processor architectures provide different atomic instructions; for example, the x86 architecture provides instructions with the `lock` prefix, while the ARM architecture provides `ldrex` and `strex` instructions. The operating system kernel encapsulates these low-level atomic instructions into a unified atomic operation interface for use by kernel modules. In this embodiment, the kernel management module calls the atomic OR operation interface provided by the kernel, passing in the address of the corresponding byte in the shadow bitmap and the generated mask. The kernel then executes the corresponding atomic instructions according to the processor architecture to complete the atomic OR operation.

[0061] Furthermore, when using atomic OR operations to update the shadow bitmap, multiple bit-setting operations on different bits can be performed simultaneously without overwriting each other. For example, when two different firmware versions connect simultaneously, they will generate different masks and perform atomic OR operations on the same byte. Since the two masks are set at different positions, the result of the bitwise OR operation will set both bits to one, preventing one operation from overwriting the result of the other. This allows the embodiments of this application to support scenarios where multiple firmware versions connect simultaneously, improving the system's concurrent processing capabilities.

[0062] Optional, please refer to Figure 5 , Figure 5 The flowchart of S300 provided for this application, such as Figure 5 As shown, in response to receiving a message from a target switch, the following steps are performed: extracting the target switch's model identifier and firmware version number; obtaining the target CMA physical page base address from the model page table based on the model identifier; reading the corresponding byte from the shadow bitmap byte array; and, based on the state of the bit corresponding to the firmware version number in the corresponding byte, calculating a context address based on the target CMA physical page base address and the firmware version number when its existence is determined. The message is then adapted using the encoding / decoding context obtained from the context address. S310, the model identifier and firmware version number are extracted from the fixed offset of the message using the eBPF program.

[0063] An eBPF program is a program that runs in kernel space and processes network packets in the early stages before they reach the kernel protocol stack. An eBPF program can be mounted on the receive path of the network interface card (NIC) driver or on a flow control entry hook of the kernel protocol stack. In this embodiment, the eBPF program is mounted on the receive path of the NIC driver, allowing the extraction of the packet's model identifier and firmware version number for context addressing before the packet is processed by the kernel protocol stack.

[0064] For example, the model identifier and firmware version number are typically encoded in the message header or specific protocol fields. In practical applications, the management protocol messages sent by the switch usually contain the switch's model information and firmware version information. This information is usually located at a fixed offset in the message, so the eBPF program can directly read this information from the fixed offset of the message. For example, the model identifier may be located in bytes sixteen to nineteen of the message, and the firmware version number may be located in byte twentieth of the message. The eBPF program can directly access these locations through pointer operations to extract the model identifier and firmware version number.

[0065] S320: Use the model identifier as the key to query the eBPF mapping to obtain the target CMA physical page base address, and read the bytes corresponding to the target switch model from the shadow bitmap byte array.

[0066] Specifically, after extracting the model identifier and firmware version number, the eBPF program first queries the eBPF mapping using the model identifier as the key to obtain the starting address of the model page table. Then, based on the starting address of the model page table and the model identifier, the eBPF program calculates the address of the corresponding entry in the model page table, reads the content of that entry, and obtains the base address of the target CMA physical page. Simultaneously, the eBPF program calculates the index of the CMA physical page corresponding to that model based on the model identifier, and then calculates the address of the corresponding byte in the shadow bitmap based on the starting address of the shadow bitmap and the physical page index, reading the content of that byte.

[0067] S330, detect whether the bit in the byte corresponding to the firmware version number is set.

[0068] Specifically, after the eBPF program reads the content of the corresponding byte in the shadow bitmap, it needs to check whether the bit corresponding to the firmware version number in that byte is set. If the bit is set, it indicates that the codec context for that version already exists in the CMA physical page, and the eBPF program can continue to calculate the context address. If the bit is not set, it indicates that the codec context for that version has not yet been loaded, and the eBPF program can handle it according to a preset strategy, such as discarding the packet or forwarding the packet to the user-space management program, triggering the on-demand loading of the codec context.

[0069] S340, when setting, add the target CMA physical page base address to the slot offset corresponding to the firmware version number to obtain the context address.

[0070] S350, access the encoding / decoding context based on the context address, and perform encoding / decoding adaptation on the message.

[0071] Optionally, detecting whether the bit corresponding to the firmware version number in the byte is set includes: performing a bitwise AND operation on the byte and a mask, wherein the mask is obtained by left-shifting 1 by the firmware version number bits; if the bitwise AND result is non-zero, it is determined that the bit is set.

[0072] The bitwise AND operation is a basic bitwise operation that performs a bitwise AND operation on corresponding bits of two operands. The corresponding bit of the result is 1 only if both corresponding bits are 1; otherwise, it is zero. In this embodiment, the bitwise AND operation is used to detect whether a specific bit in the shadow bitmap byte is set. By performing a bitwise AND operation between the shadow bitmap byte and a mask in which only the target bit is 1, if the result is non-zero, it indicates that the target bit is set; if the result is zero, it indicates that the target bit is not set.

[0073] For example, when it's necessary to detect whether the nth bit in the shadow bitmap byte is set, a mask is first generated, with its value shifted left by n bits. For instance, when n is two, the mask value is four, represented in binary as 00000100. Then, a bitwise AND operation is performed between the current value of the shadow bitmap byte and this mask. If the nth bit of the shadow bitmap byte is one, the result of the bitwise AND operation is the value of the mask, which is non-zero; if the nth bit of the shadow bitmap byte is zero, the result of the bitwise AND operation is zero.

[0074] Specifically, the advantages of this detection method are its simplicity and speed, requiring only one shift operation and one bitwise AND operation. In eBPF programs, these operations are highly efficient and can be completed in a very short time. Furthermore, this detection method requires no conditional branches, or only a simple conditional branch to determine if the result is zero. This helps improve program execution efficiency and reduces performance loss caused by branch prediction failures.

[0075] Furthermore, in practical implementations, eBPF programs can combine mask generation and bitwise AND operations into a single instruction, further improving execution efficiency. For example, in the x86 architecture, the `test` instruction can be used to simultaneously perform a bitwise AND operation and result evaluation. The `test` instruction performs a bitwise AND operation on the two operands and sets the flag register based on the result, but it does not modify the values ​​of the operands. eBPF programs can use the `test` instruction to detect whether a specific bit in the shadow bitmap byte is set, and then perform appropriate processing based on the state of the flag register.

[0076] In some embodiments, the method further includes: recording the access time of each slot, and clearing the corresponding bits in the shadow bitmap byte array for slots that have not been accessed for a preset time.

[0077] The slot access time recording is used to implement hot and cold management of the codec context. In practical applications, certain firmware versions of some switch models may not be accessed for a long time. The codec contexts of these versions occupy physical page space in contiguous memory areas, resulting in a waste of memory resources.

[0078] This embodiment can identify cold versions that have not been accessed for a long time by recording the access time of each slot, remove their encoding and decoding context from the CMA physical page, and free up slot resources for other versions to use.

[0079] For example, the access time of a slot can be recorded in the header of the CMA physical page or in a separate statistics array. In this embodiment, a portion of space can be reserved at the beginning of each CMA physical page to record the last access time of each slot within that page. For instance, the first 64 bytes of each physical page can be used to record the last access time of eight slots, with each slot's last access time occupying eight bytes, storing a timestamp accurate to the second. When an eBPF program accesses the encoding / decoding context of a slot, it can update the last access time corresponding to that slot.

[0080] Specifically, the user-space management program periodically scans the slot access times of all CMA physical pages. For each slot, the user-space management program calculates the difference between the current time and the last access time of that slot. If the difference exceeds a preset time threshold, it indicates that the codec context corresponding to that slot has not been accessed for a long time and can be considered a cold version. The user-space management program can compress and dump the codec context of that slot to ordinary memory or disk, and then call the kernel management module's interface to clear the corresponding bits in the shadow bitmap byte array. After clearing the bits, the slot can be reassigned to other firmware versions.

[0081] Furthermore, the preset time threshold can be adjusted according to the actual application scenario. For scenarios where the switch model and firmware version change frequently, the time threshold can be set shorter to release infrequently used slot resources in a timely manner; for scenarios where the switch model and firmware version are relatively stable, the time threshold can be set longer to avoid frequent loading and unloading of the codec context. Typical values ​​for the time threshold can be one hour, one day, or one week, depending on the system's memory resources and business requirements.

[0082] In some embodiments, the method further includes: In response to the detection of a DMA release event of the target CMA physical page, the encoding and decoding context of each valid slot in the target CMA physical page is backed up to the user-space buffer before release. After the target CMA physical page is reallocated, the backed-up codec context is restored to the corresponding slot of the newly allocated CMA physical page, and the corresponding bit state in the shadow bitmap byte array is restored.

[0083] In this embodiment, although the CMA region is mainly used for codec context storage in this application embodiment, the operating system kernel may also allocate the CMA region to other devices that require contiguous physical memory. When other devices need to use physical pages in the CMA region, the kernel may reclaim physical pages already allocated to the switch model. To avoid losing the codec context when physical pages are reclaimed, this application embodiment provides a mechanism for reclamation event listening and proactive backup.

[0084] For example, the kernel provides a mechanism that allows kernel modules to listen for DMA release events. A release event is triggered when the kernel is ready to release a CMA physical page. Kernel modules can listen for this event by attaching a probe or trace point to the entry point of the DMA release function. When a release event is detected, the kernel module first obtains the address of the physical page to be released, and then looks up the corresponding shadow bitmap bytes based on that address to determine which slots within the physical page store valid encoding / decoding context.

[0085] Specifically, after the kernel module determines the valid slots, it copies the encoding / decoding context from these slots to a pre-allocated user-space circular buffer. The user-space circular buffer is an efficient data structure for transferring data between kernel space and user space. It manages memory using a circular queue and supports lock-free concurrent read / write operations. After copying the encoding / decoding context to the user-space circular buffer, the kernel module clears all bits of the corresponding byte in the shadow bitmap, indicating that all slots within that physical page are no longer valid. Then, the kernel performs a physical page release operation, allocating the physical page to other devices.

[0086] Using a user-space circular buffer to back up and restore the encoding / decoding context enables efficient data transfer between kernel space and user space. In existing technologies, data transfer between kernel space and user space typically requires copy operations, which incurs significant performance overhead. The user-space circular buffer, however, employs shared memory, allowing kernel and user-space programs to directly access the same memory region without data copying, thus improving data transfer efficiency.

[0087] The CMA physical page reclamation event monitoring and proactive backup mechanism provided in this application embodiment can automatically back up and restore the codec context when a physical page is reclaimed by other devices, ensuring service continuity. In existing technologies, if the memory storing the codec context is reclaimed, it leads to context loss and service interruption. However, in this application embodiment, by monitoring DMA release events, the codec context can be backed up in a timely manner before the physical page is released and automatically restored after the physical page is reallocated. The entire process is transparent to upper-layer services and will not cause service interruption.

[0088] Furthermore, once other devices have finished using the physical page and released it back to the contiguous memory allocator, the kernel management module will reallocate a new CMA physical page for the corresponding switch model. The user-space management program will read the previously backed-up codec context from the user-space circular buffer and then write this codec context back to the corresponding slot of the newly allocated physical page. After the write-back is complete, the user-space management program will call the kernel management module's interface to restore the corresponding bit state in the shadow bitmap byte array. The entire backup and restore process is transparent to upper-layer services and will not cause service interruption or packet loss.

[0089] It should be noted that in the embodiments of this application, all technical solutions are implemented based on the native mechanisms of the operating system kernel, without requiring modification of the kernel's core code or the introduction of additional third-party components. In existing technologies, some solutions require modification of the kernel's memory allocator or network protocol stack, which increases system complexity and maintenance costs, and may also lead to conflicts with other kernel modules. In contrast, the contiguous memory regions, DMA allocation interfaces, eBPF, and atomic bit operations used in the embodiments of this application are standard mechanisms provided by the kernel, thus possessing good compatibility and portability, and can run on different kernel versions.

[0090] Based on the same inventive concept, this application also provides an SDN controller, such as... Figure 6 As shown, the SDN controller includes: The memory management module 10 is used to allocate CMA physical pages for each switch model, establish a model page table indexed by the switch model, and create a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with the CMA physical page. Each bit of each byte in the shadow bitmap byte array represents the existence state of the encoding and decoding context of each firmware version divided by fixed slots within the corresponding CMA physical page. The context loading module 20 is used to write the encoding and decoding context into the slot corresponding to the firmware version number of the firmware version in the CMA physical page corresponding to the switch model when the encoding and decoding context of a firmware version of a switch model is generated, and to set the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array to a valid state. The data plane query module 30 is used to, in response to receiving a message from the target switch, extract the model identifier and firmware version number of the target switch, obtain the target CMA physical page base address from the model page table according to the model identifier, read the corresponding byte from the shadow bitmap byte array, and, based on the state of the bit corresponding to the firmware version number in the corresponding byte, calculate the context address based on the target CMA physical page base address and the firmware version number when it is determined to exist, and use the encoding and decoding context obtained by the context address to perform adaptation processing on the message.

[0091] The memory management module 10, context loading module 20, and data surface query module 30 described above will be explained in detail below with a specific example.

[0092] For example, in a real-world application scenario, an operator's SDN controller needs to adapt to multiple switches from different vendors, each of which may have multiple different firmware versions. Upon system startup, the kernel boot parameters first configure a contiguous memory region, reserving a one-megabyte contiguous physical memory block as the CMA region. Then, the kernel management module is loaded, and the memory management module initializes the CMA region, creating a model page table and a shadow bitmap byte array. The model page table contains 256 entries, each occupying eight bytes, for a total of 2048 bytes. The shadow bitmap byte array is 256 bytes long, with each byte initialized to zero.

[0093] When the first firmware version of a switch is connected to the network for the first time, the user-space management program detects the switch's access and obtains its model identifier and firmware version number. The user-space management program then searches its local model library for the model file corresponding to that model version and generates a codec context based on the model file. After generating the codec context, the user-space management program sends it to the kernel's context loading module 20.

[0094] The context loading module 20 first checks whether a CMA physical page has already been allocated for the switch model. If not, the context loading module 20 calls the interface of the memory management module to allocate a CMA physical page for the switch model. The memory management module calls the DMA allocation interface to allocate a 4,000-byte physical page from the CMA region and stores the base address of the physical page in the model page table, using the switch model identifier as an index.

[0095] After obtaining the physical page base address, the context loading module 20 calculates the slot offset based on the firmware version number. For example, if the firmware version number is zero, the slot offset is zero bytes; if the firmware version number is one, the slot offset is 512 bytes. The context loading module 20 copies the encoding / decoding context from user space to the corresponding slot position of the CMA physical page in kernel space. After copying, the context loading module 20 performs an atomic OR operation on the corresponding bytes in the shadow bitmap byte array, setting the corresponding version number bit to one. For example, if the firmware version number is zero and the mask of the atomic OR operation is one, the value of the corresponding byte in the shadow bitmap will become one; if the firmware version number is one and the mask is two, the value of the corresponding byte in the shadow bitmap will become three.

[0096] When the switch sends a management protocol message to the controller, the message first reaches the network interface card (NIC), which then passes it to the kernel driver. The eBPF program, mounted on the NIC driver's receive path, processes the message before it is processed by the kernel protocol stack. The eBPF program extracts the switch's model identifier and firmware version number from fixed offsets in the message. For example, the model identifier might be located between bytes sixteen and nineteen of the message, and the firmware version number might be located in the twentieth byte.

[0097] After extracting the model identifier and firmware version number, the eBPF program queries the eBPF mapping using the model identifier as the key to obtain the starting address of the model page table. Then, based on the starting address of the model page table and the model identifier, the eBPF program calculates the address of the corresponding entry in the model page table, reads the content of that entry, and obtains the CMA physical page base address corresponding to the switch model. Simultaneously, the eBPF program calculates the physical page index corresponding to the model based on the model identifier, and then calculates the address of the corresponding byte in the shadow bitmap based on the starting address of the shadow bitmap and the physical page index, reading the content of that byte.

[0098] After reading the contents of the shadow bitmap bytes, the eBPF program generates a mask whose value is one left-shifted firmware version number bits. Then, the eBPF program performs a bitwise AND operation between the shadow bitmap bytes and the mask. If the result of the bitwise AND is non-zero, it indicates that the codec context for that version already exists, and the eBPF program calculates the context address. The context address equals the physical page base address plus the firmware version number multiplied by 512 bytes. For example, if the physical page base address is 0x10000000 and the firmware version number is two, then the context address is 0x10000000 plus two multiplied by 512 bytes, which equals 0x10000400.

[0099] After calculating the context address, the eBPF program stores the context address in the packet's metadata, or passes the address to the user-space codec program via an eBPF helper function. The eBPF program then passes the packet to the kernel protocol stack for further processing. Upon receiving the packet and the context address, the user-space codec program directly uses the address to access the encoding / decoding context, parsing and processing the packet. After processing, the user-space codec program generates a response packet and sends it to the switch.

[0100] During system operation, the user-space management program periodically scans the access times of all slots. For each slot, the user-space management program calculates the difference between the current time and the last access time of that slot. If the difference exceeds a preset time threshold, such as one hour, the user-space management program compresses and dumps the encoding / decoding context of that slot to disk, and then calls the kernel management module's interface to clear the corresponding bit in the shadow bitmap. After clearing the bit, the slot can be reassigned to other firmware versions.

[0101] If other devices need to use a physical page in the CMA area during system operation, the kernel will trigger a DMA release event. The kernel module will listen for this event and, before the physical page is released, copy the encoding / decoding context of all valid slots within that physical page to the user-space circular buffer. After copying, the kernel module will clear all bits of the corresponding byte in the shadow bitmap. Then, the kernel will complete the physical page release operation and allocate the physical page to other devices. When other devices finish using the physical page and release it, the kernel management module will reallocate a new physical page for the corresponding switch model. The user-space management program will read the backed-up encoding / decoding context from the user-space circular buffer, write it back to the corresponding slot of the newly allocated physical page, and restore the corresponding bit state in the shadow bitmap. The entire process has no impact on upper-layer services and will not cause service interruption.

[0102] This application implements hot and cold management of encoding / decoding contexts, automatically identifying cold versions that have not been accessed for a long time, releasing the memory resources they occupy, and improving memory utilization. In the prior art, once an encoding / decoding context is loaded, it occupies memory resources until the system restarts or is manually unloaded. This leads to memory resources being occupied by infrequently used contexts, reducing system memory utilization. However, in this application embodiment, by recording the access time of slots, cold versions can be automatically identified and dumped to disk or ordinary memory, releasing physical page resources in contiguous memory areas for use by other versions, thus improving memory utilization.

[0103] In this embodiment, the context address is calculated within the eBPF program. Since the eBPF program runs in kernel space and can directly access physical memory, the calculation and access speed of the context address is very fast. In the prior art, the context address is usually a virtual address, requiring address translation by the memory management unit before accessing physical memory, which incurs a performance overhead. However, in this embodiment, physical addresses are used, eliminating the need for address translation and thus improving memory access speed.

[0104] In this embodiment, the model page table and shadow bitmap are very small in size and can reside permanently in the processor's cache, resulting in very fast access speeds. In the prior art, hash tables are typically large and difficult to reside entirely in the cache, often leading to cache misses and requiring data to be read from main memory, which incurs significant performance overhead. However, in this embodiment, the total size of the model page table and shadow bitmap is only a few kilobytes, allowing them to reside entirely in the processor's L1 or L2 caches. Therefore, access to them almost never results in cache misses, leading to very fast access speeds.

[0105] In this embodiment, the firmware version number is directly mapped to the slot index and bits in the shadow bitmap, without requiring any complex conversions or mappings. In existing technologies, the version number typically needs to be converted to a hash table key, or other mapping relationships are used to look up the context address, which increases the complexity and latency of addressing. However, in this embodiment, the version number has a direct linear mapping relationship with the slot index and bits, making the addressing process very simple and efficient.

[0106] In this embodiment, the codec contexts of multiple firmware versions are stored in the same physical page, which improves the utilization of the processor cache. When the processor accesses the codec context of a certain version, it loads the entire physical page or part of the physical page into the cache. Since the codec contexts of different firmware versions of the same model are stored in the same physical page, when the processor accesses the codec context of other versions of the same model, it is likely already in the cache, thus improving the cache hit rate and reducing memory access latency.

[0107] In this embodiment, each byte of the shadow bitmap corresponds to a physical page, and the eight bits of each byte correspond to eight slots. This design makes the shadow bitmap structure very compact and easy to manage. Each byte can independently represent the existence status of all slots within a physical page, so operations on a single physical page only require accessing one byte, which is highly efficient. Furthermore, when the entire physical page needs to be released, it is only necessary to clear the corresponding byte in the shadow bitmap to zero, without having to clear each bit individually, thus simplifying the operation process.

[0108] In this embodiment, atomic OR operations are used to update the shadow bitmap, allowing multiple bit-setting operations on different bits to be performed simultaneously without interference. This enables this embodiment to support scenarios where multiple firmware versions are accessed simultaneously, improving the system's concurrency processing capabilities. In the prior art, hash table updates typically require locks, and lock contention can lead to performance degradation under high concurrency. However, this embodiment does not require locks, thus avoiding performance loss caused by lock contention.

[0109] In this embodiment, the eBPF program is mounted on the receive path of the network card driver, enabling context addressing to be completed before the packet is processed by the kernel protocol stack. This ensures that the latency of context addressing does not affect the processing time of the kernel protocol stack, improving the overall system performance. In the prior art, context addressing is usually performed after protocol stack processing or in user space, which increases packet processing latency. However, in this embodiment, context addressing is completed in the early stages of packet reception, thus reducing the overall packet processing latency.

[0110] In this embodiment, the loading of the codec context is performed on demand. The corresponding codec context is only generated and loaded when a switch with a certain firmware version is first connected. This avoids loading all possible codec contexts at system startup, reducing system startup time and memory usage. In existing technologies, some solutions load all codec contexts at system startup, which leads to excessively long system startup times and consumes a large amount of memory resources. In this embodiment, on-demand loading allows the codec context to be loaded according to actual service requirements, improving system resource utilization.

[0111] In this embodiment, the size of the contiguous memory area can be flexibly configured according to the actual number of switch models to be adapted. If a large number of switch models need to be adapted, the reserved size of the contiguous memory area can be increased; if a small number of switch models need to be adapted, the reserved size of the contiguous memory area can be decreased. This flexible configuration allows this embodiment to adapt to application scenarios of different scales, from small enterprise networks to large carrier networks.

[0112] In this embodiment, the number and size of the slots can also be adjusted according to actual needs. If a switch model needs to support more firmware versions, the number of slots can be increased, and the size of each slot can be reduced accordingly; if the size of the codec context is generally large, the number of slots can be reduced, and the size of each slot can be increased accordingly. This flexible adjustment method allows this embodiment to adapt to different codec context sizes and firmware version requirements.

[0113] In this embodiment, all operations are implemented based on standard operating system interfaces and mechanisms, thus exhibiting good maintainability and scalability. When new features need to be added or problems need to be fixed, only the kernel module or eBPF program code needs to be modified, without modifying the core kernel code. This makes system maintenance and upgrades more convenient and reduces maintenance costs.

[0114] In this embodiment, by aggregating and storing the encoding / decoding context in the CMA physical page and using an independent shadow bitmap to record the existence state, fixed offset addressing is implemented in the eBPF data plane, forming a complete, efficient, and stable unified adaptation solution for multi-vendor switches. This solution solves the problems of memory fragmentation, high addressing latency, and easy loss of context in the prior art, improves the performance and stability of the SDN controller, and can meet the application requirements of high throughput and low latency.

[0115] It should be noted that the memory management module 10 is the core module in the SDN controller responsible for memory resource management. The main functions of the memory management module 10 include CMA region initialization, physical page allocation and release, model page table creation and maintenance, and shadow bitmap creation and maintenance. The memory management module 10 is typically implemented as a kernel module, running in kernel space, and can directly access the operating system kernel's memory management interface.

[0116] For example, the context loading module 20 is responsible for loading the codec context from user space into the CMA physical page in kernel space. The main functions of the context loading module 20 include receiving the codec context sent by the user-space manager, copying the codec context to the corresponding slot in the CMA physical page, and updating the state of the shadow bitmap. The context loading module 20 is typically implemented as a kernel module, working closely with the memory management module to jointly complete the loading and management of the codec context.

[0117] Specifically, the data plane query module 30 is responsible for context addressing and message adaptation processing on the message receiving path. The main functions of the data plane query module 30 include extracting the model identifier and firmware version number from the message, querying the model page table to obtain the physical page base address, reading the shadow bitmap to determine if the context exists, calculating the context address, and passing the context address to the user-space encoder / decoder. The data plane query module is typically implemented as an eBPF program, running on the message receiving path in kernel space, and can process messages at extremely high speeds.

[0118] In addition, the SDN controller may include other auxiliary modules, such as a user-space management module, a codec processing module, and a protocol processing module. The user-space management module is responsible for interacting with users, managing the configuration of switch models and firmware versions, generating codec contexts, and monitoring the system's operational status. The codec processing module is responsible for accessing the codec context based on the context address and parsing and generating packets. The protocol processing module is responsible for handling various network management protocols, enabling communication and management functions with the switch. These modules work together to form a complete SDN controller system.

[0119] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A unified adaptation method for multi-vendor switches, applicable to SDN controllers, characterized in that, include: Assign CMA physical pages to each switch model, establish a model page table indexed by the switch model, the table entries of the model page table record the base address of the CMA physical page corresponding to the switch model, and create a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with the CMA physical page. Each bit of each byte in the shadow bitmap byte array represents the existence state of the encoding and decoding context of each firmware version divided by fixed slots within the corresponding CMA physical page. When a codec context for a firmware version of a switch model is generated, the codec context is written into the slot corresponding to the firmware version number of the firmware version in the CMA physical page corresponding to the switch model, and the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array is set to the valid state. In response to receiving a message from the target switch, the model identifier and firmware version number of the target switch are extracted. The target CMA physical page base address is obtained from the model page table based on the model identifier, and the corresponding byte is read from the shadow bitmap byte array. Based on the state of the bit corresponding to the firmware version number in the corresponding byte, if it is determined that the context address exists, the context address is calculated based on the target CMA physical page base address and the firmware version number. The encoding and decoding context obtained by the context address is used to perform adaptation processing on the message.

2. The method according to claim 1, characterized in that, The process of allocating CMA physical pages to each switch model and establishing a model page table indexed by the switch model includes: Through the DMA allocation interface, a separate CMA physical page is allocated for each switch model from the reserved CMA area; The base address of the CMA physical page is used as a table entry, and the model identifier of the switch model is used as an index to store it in the model page table.

3. The method according to claim 1, characterized in that, The creation of a shadow bitmap byte array, independent of the CMA allocation bitmap and corresponding one-to-one with a CMA physical page, includes: Based on the total number of physical pages contained in the reserved CMA region, a byte array is allocated as a shadow bitmap, and the index of the shadow bitmap is consistent with the page index of the CMA physical page; Load the starting address of the shadow bitmap into the eBPF mapping.

4. The method according to claim 1, characterized in that, The step of writing the encoding / decoding context into the slot corresponding to the firmware version number in the CMA physical page corresponding to the switch model, and setting the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array to a valid state includes: Based on the firmware version number of the firmware version, determine the corresponding slot offset within the CMA physical page; Copy the encoding / decoding context to the location indicated by the slot offset; Atomic bit operations are performed on the corresponding bytes in the shadow bitmap byte array to set the bit corresponding to the firmware version number.

5. The method according to claim 4, characterized in that, The step of performing atomic bit operations on the corresponding bytes in the shadow bitmap byte array includes: Using an atomic OR operation, the mask obtained by left-shifting the firmware version number bit by a value of 1 is bitwise ORed with the corresponding byte.

6. The method according to claim 1, characterized in that, In response to receiving a message from the target switch, the method extracts the model identifier and firmware version number of the target switch, obtains the target CMA physical page base address from the model page table based on the model identifier, reads the corresponding byte from the shadow bitmap byte array, and calculates a context address based on the target CMA physical page base address and the firmware version number, and performs adaptation processing on the message using the encoding / decoding context obtained from the context address, based on the state of the bit corresponding to the firmware version number in the corresponding byte. The model identifier and firmware version number are extracted from the fixed offset of the message using the eBPF program; The target CMA physical page base address is obtained by querying the eBPF mapping using the model identifier as the key, and the bytes corresponding to the target switch model are read from the shadow bitmap byte array. Detect whether the bit in the byte corresponding to the firmware version number is set; When the bit is set, the target CMA physical page base address is added to the slot offset corresponding to the firmware version number to obtain the context address; Access the encoding / decoding context based on the context address, and perform encoding / decoding adaptation on the message.

7. The method according to claim 6, characterized in that, The step of detecting whether the bit corresponding to the firmware version number in the byte is set includes: Perform a bitwise AND operation between the byte and a mask, which is obtained by left-shifting 1 by the firmware version number. If the bitwise AND result is non-zero, then the bit is set.

8. The method according to claim 1, characterized in that, Also includes: Record the access time of each slot. For slots that have not been accessed for more than a preset time, clear the corresponding bits in the shadow bitmap byte array.

9. The method according to claim 1, characterized in that, Also includes: In response to the detection of a DMA release event of the target CMA physical page, the encoding and decoding context of each valid slot in the target CMA physical page is backed up to the user-space buffer before release. After the target CMA physical page is reallocated, the backed-up codec context is restored to the corresponding slot of the newly allocated CMA physical page, and the corresponding bit state in the shadow bitmap byte array is restored.

10. An SDN controller, characterized in that, include: The memory management module is used to allocate CMA physical pages for each switch model, establish a model page table indexed by the switch model, and create a shadow bitmap byte array that is independent of the CMA allocation bitmap and corresponds one-to-one with the CMA physical page. Each bit of each byte in the shadow bitmap byte array represents the existence state of the encoding and decoding context of each firmware version divided by fixed slots within the corresponding CMA physical page. The context loading module is used to write the codec context into the slot corresponding to the firmware version number of the firmware version in the CMA physical page corresponding to the switch model when the codec context of a firmware version of a switch model is generated, and to set the bit corresponding to the firmware version number in the byte corresponding to the CMA physical page in the shadow bitmap byte array to a valid state. The data plane query module is used to respond to a received packet from a target switch by extracting the target switch's model identifier and firmware version number, obtaining the target CMA physical page base address from the model page table based on the model identifier, reading the corresponding byte from the shadow bitmap byte array, and calculating the context address based on the state of the bit corresponding to the firmware version number in the corresponding byte, and using the encoding / decoding context obtained from the context address to perform adaptation processing on the packet.

Images