FPGA queue-based virtual network simulation test system and application method

Abstract

The application specifically relates to a virtual network simulation test system based on an FPGA queue and an application method; the system and the application method relate to: message transmission only involves an FPGA-STDMA queue, an ST ring buffer and an ST character device; based on this, memory copy nodes are reduced to reduce memory bandwidth overhead; the FPGA-MMDMA queue is combined with an MM-ARB, and the FPGA-STDMA queue is combined with an ST-ARB, so that a double-channel hardware isolation framework can be constructed, based on which configuration flow and service message concurrent operations can be respectively controlled; a docker management control channel is constructed between a traffic manager and a bridge unit to ensure that a container life cycle, a topology adjustment instruction and a service message DMA channel are completely isolated; by providing no less than 4096 groups of FPGA-MMDMA and FPGA-STDMA queues, and by ensuring that the allocation number of simulation containers satisfies K<=min(x, y), the complex large-scale networking verification demand can be met; registers Bar0 and Bar2 are set to isolate a configuration channel and a message channel, so that bus preemption and instruction coverage are not triggered when multiple nodes are concurrently configured.

Description

Technical Field

[0001] This invention relates to the field of FPGA hardware processing technology, and in particular to a virtual network simulation test system and application method based on FPGA queues. Background Technology

[0002] In the solution verification and networking testing phases of cloud data centers, 5G bearer networks, and industrial networks, it is necessary to build complex and large-scale simulation topologies involving "hundreds to thousands of PE gateways, CE access devices, and service terminals". The purpose is to simultaneously simulate a massive number of network nodes, quickly iterate networking solutions, and verify routing protocols and service interaction logic. However, existing containerization solutions based on Linux OVS (Open vSwitch), veth (Virtual Ethernet), and kernel bridges have significant shortcomings and cannot meet the needs of ultra-large-scale network simulation. These shortcomings involve the following aspects: 1) The message transmission involves four layers of redundant memory copy nodes, specifically: container cache --- veth cache --- OVS forwarding cache --- ringbuf ring cache --- FPGA-DMA cache, which leads to large memory bandwidth overhead; 2) The hardware configuration control flow and Docker business simulation data flow issued by the trafficmanager share the same bus for transmission, that is, there is no physical channel isolation, which leads to severe bus contention in concurrent scenarios; 3) Without an independent container management channel, container lifecycle instructions and business traffic are transmitted together, which makes batch topology changes more prone to instruction conflicts; 4) FPGA hardware queue resources are limited, making it impossible to allocate an independent isolated transmission channel for a single virtual simulation device. Multiple traffic streams interfere with each other, which in turn leads to distortion of test indicators. 5) Control flow and service flow share PCIe and software queues. When thousands of nodes are simulated concurrently, they compete for bandwidth, which leads to latency jitter, count distortion, configuration command overwriting, and poor reliability of network test indicators.

[0003] To address the aforementioned technical problems 1) to 5), this application proposes a virtual network simulation test system and application method based on FPGA queues. Summary of the Invention

[0004] In view of the above-mentioned shortcomings and deficiencies of the existing technology, the present invention provides a virtual network simulation test system and application method based on FPGA queues, which solves the current technical problem of "how to reduce memory bandwidth overhead while avoiding the following problems during virtual network simulation testing: concurrent scenarios - bus contention, batch topology changes - instruction conflicts, test index distortion, latency jitter, count distortion, and configuration instruction overlay".

[0005] To achieve the above objectives, the main technical solutions adopted by the present invention include: This invention provides a virtual network simulation and testing system based on FPGA queues; the structure of the virtual network simulation and testing system involves: TrafficManager is based on bridge units and connected to the set of simulation containers via control paths; The simulation container set is sequentially connected to the following via the MM configuration path: MM character device set, MM ring buffer set, FPGA-MMDMA queue, and configuration instruction arbitration unit MM-ARB; The simulation container set is sequentially connected to the following via the ST service path: ST character device set, ST ring buffer set, FPGA-STDMA queue, and message traffic arbitration unit ST-ARB; MM-ARB / ST-ARB are connected to MAC / GTM via bus AXI-Lite / AXI-Stream, and MAC / GTM are connected to optical modules SFP+ / QSFP / QSFP-DD via Ethernet. The FPGA-MMDMA queue, configuration instruction arbitration unit, FPGA-STDMA queue, and message traffic arbitration unit constitute the DMA queue (Queue-DMA). TrafficManager maps resource files / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2 based on the control path; / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2 are connected to registers Bar0 and Bar2 through the control path; Register Bar0 is connected to Queue-DMA via the ST control path, and register Bar2 is connected to Queue-DMA via the MM control path; register Bar2 is connected to MAC / GTM and optical modules SFP+ / QSFP / QSFP-DD via control paths respectively; Among them, register Bar0, register Bar2, optical module SFP+ / QSFP / QSFP-DD, MAC / GTM, and Queue-DMA constitute the Hardware layer; FPGA kernel driver, MM ring buffer set, and ST ring buffer set constitute the Kernel layer. The Hardware layer is connected to the Kernel layer via the PCI-E bus.

[0006] Optionally, the connection methods corresponding to the control path, MM configuration path, ST service path, Ethernet, bus AXI-Lite / AXI-Stream, and bus PCI-E are bidirectional connections.

[0007] Optionally, the set of simulated containers can be represented as docker1~dockerK; K≤min(x,y), where x represents the number of FPGA-MMDMA queue groups and y represents the number of FPGA-STDMA queue groups, and x≥4096 and y≥4096; Any of docker1 to dockerK is equivalent to: an independent PE / CE gateway or terminal virtual device, and has built-in: a routing protocol stack, a traffic generation module, a protocol parsing module, and a performance statistics module; Any of docker1~dockerK can be bound to any number and encoding of MM character devices and ST character devices to adapt to different business loads.

[0008] Optionally, the trafficmanager, based on a global traffic management program, uses a bridge unit to uniformly manage docker1~dockerK to complete: the creation and destruction of emulated containers, the mounting and unbinding of character devices, the allocation of hardware queue resources, and large-scale topology scheduling, so as to achieve: hot-swappable management of virtual devices; The bridge unit is used to isolate management traffic and service message traffic by forwarding lifecycle instructions and topology adjustment instructions of the emulation container.

[0009] Optionally, based on / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2, the trafficmanager executes the mmap system call to directly access registers Bar0 and Bar2 to perform: global port rate configuration, basic information statistics, and priority scheduling.

[0010] Optionally, based on the FPGA kernel driver, generate: MM character device, ST character device, MM circular buffer, ST circular buffer; Each MM / ST character device corresponds to an MM / ST circular buffer, and each MM / ST circular buffer corresponds to an FPGA-MMDMA / FPGA-STDMA queue.

[0011] Optionally, register Bar0 is used to store ST message queue configuration, register BAR2 is used to store MM scheduling information and flow table entry configuration; FPGA-MMDMA queue is used for batch flow table and hardware configuration distribution, and FPGA-STDMA queue is used for sending and receiving service messages. ST-ARB is used to poll / weighted priority arbitration of multi-stream service message queues to schedule messages to be sent to MAC / GTM via the AXI-Stream bus in an orderly manner; MM-ARB is used to perform serial arbitration of concurrent access operations to FPGA-MMDMA queues and registers to process instructions involving port configuration and batch flow table entries in an orderly manner.

[0012] This invention also provides an application method based on the aforementioned virtual network simulation testing system, the application method involving: S1, the FPGA kernel driver completes the basic parameter configuration of the FPGA based on register Bar0 to generate all MM character devices and ST character devices; it supports the operation of MM character devices and ST character devices based on the FPGA-MMDMA queue / FPGA-STDMA queue. Synchronously initialize the Docker management channel between Trafficmanager and the bridge unit; S2. Based on the trafficmanager, map register BAR2-resources; create a simulation container according to the networking requirements, allocate MM character devices and ST character devices to it, and bind an independent CPU.

[0013] Optional, the application methods involve: S3. If there is an external test message entering the FPGA, then the external test message is split and passes through the FPGA-STDMA queue, ST ring buffer, and ST character device in sequence to reach the simulation container to generate a simulation message. The simulation message passes through the ST character device, ST circular buffer, and FPGA-STDMA queue in sequence to reach the ST-ARB; after high-priority scheduling based on ST-ARB, the simulation message is output to the outside world. If no external test message exists, then: instructions involving batch flow tables and port configurations across the entire network are issued through the FPGA-MMDMA queue, and MM-ARB performs serial arbitration to process the relevant instructions.

[0014] Optional, the application methods involve: S4. Simulation messages perform external interactions based on Ethernet ports; If it is determined that the simulation topology needs to be adjusted, then the trafficmanager issues commands involving container start / stop and character device mounting / unbinding through the bridge unit to perform simulation container hot-plugging; Otherwise: Integrate FPGA hardware timestamp marking and container session layer statistics, and determine whether it is necessary to add a new routing protocol or customize the terminal model; If it is necessary to add routing protocols or custom terminal models, then: allocate idle FPGA-MMDMA / FPGA-STDMA queues through the development simulation container-image to put them into simulation; Otherwise: Output a complete simulation report for large-scale networking scenarios.

[0015] The beneficial effects of this application include: In this application, message transmission involves FPGA-STDMA queue, ST ring buffer, and ST character device; compared with "container cache---veth cache---OVS forwarding cache---ringbuf ring buffer---FPGA-DMA cache", memory bandwidth overhead can be reduced by cutting memory copy nodes; In this application, the FPGA-MMDMA queue is combined with the configuration instruction arbitration unit MM-ARB, and the FPGA-STDMA queue is combined with the message flow arbitration unit ST-ARB, which can build a dual-channel hardware isolation architecture. Based on this, the configuration flow and concurrent operation of service messages can be managed separately. In this application, an independent Docker management and control channel is built between the trafficmanager and the bridge unit to ensure that: the container lifecycle, topology adjustment instructions and business message DMA channels are completely isolated; and then, by batch managing thousands of containers, the response speed for topology changes is ensured. This application provides: no less than 4096 FPGA-MMDMA queues and FPGA-STDMA queues, and the number of simulation containers allocated satisfies K≤min(x,y); based on this, the bottleneck of the number of nodes in OVS software switching is overcome to meet the verification requirements of complex large-scale networking. In this application, registers Bar0 and Bar2 are set to isolate the configuration channel and the message channel; based on this, it is ensured that bus preemption and instruction overwriting will not occur when performing large-scale multi-node concurrent configuration. In this application, if the simulation topology needs to be adjusted, the trafficmanager issues commands related to container start / stop and character device mounting / unbinding through the bridge unit to perform hot-plugging of the simulation container; Based on this, there is no need to restart the hardware and drivers, thus making it compatible with automated batch simulation test pipelines. In this application, if it is necessary to add a new routing protocol or customize a terminal model, then: the idle FPGA-MMDMA / FPGA-STDMA queues are allocated through the development of a simulation container-image for simulation. Based on this, there is no need to modify the FPGA, thus significantly shortening the hardware development and iteration cycle; In this application, the simulation container can be bound to any number and encoding of MM character devices and ST character devices to adapt to different business loads; based on this, resources can be allocated on demand to improve hardware resource utilization. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the structure of a virtual network simulation test system provided in one embodiment of the present invention; Figure 2 This is a schematic diagram of a system-application method provided in one embodiment of the present invention. Detailed Implementation

[0017] To better explain and facilitate understanding of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and that the scope of the present invention can be fully conveyed to those skilled in the art.

[0019] Example 1 This embodiment proposes a virtual network simulation and testing system based on FPGA queues; Figure 1 This is a schematic diagram of the virtual network simulation test system structure; combined with the aforementioned Figure 1 The structure of the virtual network simulation test system involves the following: In this embodiment, as Figure 1 As shown, the trafficmanager is connected to the set of simulation containers via a control path based on the bridge unit; preferably, the set of simulation containers is represented as docker1~dockerK; It should be noted that K≤min(x,y), where x represents the number of FPGA-MMDMA queue groups, y represents the number of FPGA-STDMA queue groups, and x≥4096 and y≥4096; Regarding the aforementioned set of simulated containers docker1~dockerK, it should be noted that: Any of docker1 to dockerK is equivalent to: an independent PE / CE gateway or terminal virtual device, and has built-in: a routing protocol stack, a traffic generation module, a protocol parsing module, and a performance statistics module; Any of docker1~dockerK can be bound to any number and encoding of MM character devices and ST character devices to adapt to different business loads.

[0020] Furthermore, based on the global traffic management program, the trafficmanager manages docker1~dockerK uniformly through the bridge unit, and can complete: creation and destruction of emulated containers, mounting and unbinding of character devices, allocation of hardware queue resources, and large-scale topology scheduling to achieve: hot-swappable management of virtual devices; among them, the bridge unit is used to: isolate management traffic and service packet traffic by forwarding the life cycle instructions and topology adjustment instructions of emulated containers.

[0021] In this embodiment, as Figure 1 As shown, docker1~dockerK, trafficmanager, and bridge units constitute the user layer.

[0022] In this embodiment, as Figure 1 As shown, the simulation container set is sequentially connected to the following via the MM configuration path: MM character device set, MM ring buffer set, FPGA-MMDMA queue, and configuration instruction arbitration unit MM-ARB; the simulation container set is sequentially connected to the following via the ST service path: ST character device set, ST ring buffer set, FPGA-STDMA queue, and packet traffic arbitration unit ST-ARB. In this embodiment, as Figure 1 As shown, the MM-ARB is connected to the MAC / GTM via the AXI-Lite bus, and the ST-ARB is connected to the MAC / GTM via the AXI-Stream bus; the MAC / GTM is connected to the optical modules SFP+ / QSFP / QSFP-DD via Ethernet.

[0023] Combination Figure 1 It should be noted that the following are generated based on the FPGA kernel driver: MM character device, ST character device, MM circular buffer, and ST circular buffer; such as Figure 1 As shown, each MM / ST character device corresponds to an MM / ST circular buffer, and each MM / ST circular buffer corresponds to an FPGA-MMDMA / FPGA-STDMA queue.

[0024] It should be noted that: 1) The FPGA-MMDMA queue is used for the batch flow table and hardware configuration distribution; 2) The FPGA-STDMA queue is used for the transmission and reception of service messages; 3) The ST-ARB is used for polling / weighted priority arbitration of the multi-stream service message queue to orderly schedule messages to be sent to MAC / GTM via the AXI-Stream bus; 4) The MM-ARB is used for serial arbitration of the FPGA-MMDMA queue and concurrent register access operations to orderly process instructions involving port configuration and batch flow table entry distribution.

[0025] In this embodiment, as Figure 1 As shown, the FPGA-MMDMA queue, configuration instruction arbitration unit, FPGA-STDMA queue, and message traffic arbitration unit constitute the DMA queue Queue-DMA.

[0026] In this embodiment, as Figure 1 As shown, the trafficmanager maps resource files based on the control path; preferably, the resource files include: / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2; In this embodiment, as Figure 1 As shown, / sys / ... / bdf / resource0 is connected to register Bar0 through a control path, and / sys / ... / bdf / resource2 is connected to register / Bar2 through a control path.

[0027] Preferably, based on / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2, the trafficmanager directly accesses registers Bar0 and Bar2 by executing the mmap system call to complete: global port rate configuration, basic information statistics, and priority scheduling; It should be noted that the aforementioned priority scheduling supports multiple scheduling algorithms, and the specific scheduling algorithms involved are: RR / WRR / WFQ (including: Round Robin / Weighted Round Robin / Weighted FairQueuing), with RR as the default.

[0028] It should be noted that register Bar0 is used to store ST message queue configuration, and register BAR2 is used to store MM scheduling information and flow table entry configuration.

[0029] like Figure 1As shown, register Bar0 is connected to Queue-DMA based on the ST control path, and register Bar2 is connected to Queue-DMA based on the MM control path; register Bar2 is connected to MAC / GTM and optical modules SFP+ / QSFP / QSFP-DD through control paths respectively.

[0030] In this embodiment, as Figure 1 As shown, / sys / ... / bdf / resource0, / sys / ... / bdf / resource2, the MM character device set, and the ST character device set constitute the VFS layer.

[0031] In this embodiment, as Figure 1 As shown, the optical modules SFP+ / QSFP / QSFP-DD, MAC / GTM, register Bar0, register Bar2, and Queue-DMA constitute the Hardware layer; the FPGA core driver, MM ring buffer set, and ST ring buffer set constitute the Kernel layer; the Hardware layer is connected to the Kernel layer via the PCI-E bus.

[0032] In this embodiment, it should be noted that the connection methods corresponding to the aforementioned control path, MM configuration path, ST service path, Ethernet, bus AXI-Lite / AXI-Stream, and bus PCI-E are bidirectional connections.

[0033] This embodiment also provides an application method based on the aforementioned virtual network simulation testing system. Figure 2 This is a schematic diagram of the system-application method flow; In this embodiment, combined with Figure 2 The application method involves the following S1 to S4: S1, the FPGA kernel driver completes the basic parameter configuration of the FPGA based on register Bar0 to generate all MM character devices and ST character devices; it supports the operation of MM character devices and ST character devices based on the FPGA-MMDMA queue / FPGA-STDMA queue. Synchronously initialize the Docker management channel between Trafficmanager and the bridge unit; S2. Based on the trafficmanager, map register BAR2-resources; create a simulation container according to the networking requirements, allocate MM character devices and ST character devices to it, and bind it to an independent CPU; S3. If there is an external test message entering the FPGA, then the external test message is split and passes through the FPGA-STDMA queue, ST ring buffer, and ST character device in sequence to reach the simulation container to generate a simulation message. The simulation message passes through the ST character device, ST circular buffer, and FPGA-STDMA queue in sequence to reach the ST-ARB; after high-priority scheduling based on ST-ARB, the simulation message is output to the outside world. If no external test message exists, then: instructions involving batch flow tables and port configurations across the entire network are sent through the FPGA-MMDMA queue, and MM-ARB performs serial arbitration to process the relevant instructions; S4. Simulation messages perform external interactions based on Ethernet ports; If it is determined that the simulation topology needs to be adjusted, then the trafficmanager issues commands involving container start / stop and character device mounting / unbinding through the bridge unit to perform simulation container hot-plugging; Otherwise: Integrate FPGA hardware timestamp marking and container session layer statistics, and determine whether it is necessary to add a new routing protocol or customize the terminal model; If it is necessary to add routing protocols or custom terminal models, then: allocate idle FPGA-MMDMA / FPGA-STDMA queues through the development simulation container-image to put them into simulation; Otherwise: Output a complete simulation report for large-scale networking scenarios.

[0034] Based on the virtual network simulation test system and application method described in Embodiment 1 above, message transmission involves FPGA-STDMA queue, ST ring buffer, and ST character device; compared with "container cache---veth cache---OVS forwarding cache---ringbuf ring buffer---FPGA-DMA cache", memory bandwidth overhead can be reduced by cutting memory copy nodes; Furthermore, the FPGA-MMDMA queue, combined with the configuration instruction arbitration unit MM-ARB, and the FPGA-STDMA queue, combined with the message flow arbitration unit ST-ARB, can construct a dual-channel hardware isolation architecture, based on which configuration flow and concurrent operation of service messages can be managed separately. Furthermore, an independent Docker management and control channel is established between the trafficmanager and the bridge unit to ensure that: the container lifecycle, topology adjustment instructions and business message DMA channels are completely isolated; and then, by batch managing thousands of containers, the response speed for topology changes is ensured. In addition, it provides: no less than 4096 FPGA-MMDMA queues and FPGA-STDMA queues, and the number of simulation containers allocated satisfies K≤min(x,y); based on this, by breaking through the bottleneck of the number of nodes in OVS software exchange, it meets the verification requirements of complex large-scale networking. Furthermore, by setting registers Bar0 and Bar2, the configuration channel and message channel are isolated; based on this, it is ensured that bus preemption and instruction overwriting will not occur when performing large-scale multi-node concurrent configuration. Additionally, if the simulation topology needs to be adjusted, the trafficmanager issues commands related to container start / stop and character device mounting / unbinding through the bridge unit to perform hot-plugging of the simulation container; Based on this, there is no need to restart the hardware and drivers, thus making it compatible with automated batch simulation test pipelines. Furthermore, if new routing protocols or customized terminal models are required, idle FPGA-MMDMA / FPGA-STDMA queues can be allocated for simulation by developing simulation containers-images. Based on this, there is no need to modify the FPGA, thereby significantly shortening the hardware development and iteration cycle. Furthermore, the simulation container can be bound to any number and encoding of MM character devices and ST character devices to adapt to different business workloads; based on this, resources can be allocated on demand to improve hardware resource utilization.

[0035] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The words "a" or "an" preceding a component do not exclude the presence of a plurality of such components. The use of the terms first, second, third, etc., is for convenience only and does not indicate any order. These terms can be understood as part of the component names.

[0036] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0037] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0038] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. A virtual network simulation and testing system based on FPGA queues, characterized in that: The structure of the virtual network simulation testing system involves: TrafficManager is based on bridge units and connected to the set of simulation containers via control paths; The simulation container set is sequentially connected to the following via the MM configuration path: MM character device set, MM ring buffer set, FPGA-MMDMA queue, and configuration instruction arbitration unit MM-ARB; The simulation container set is sequentially connected to the following via the ST service path: ST character device set, ST ring buffer set, FPGA-STDMA queue, and message traffic arbitration unit ST-ARB; MM-ARB / ST-ARB are connected to MAC / GTM via bus AXI-Lite / AXI-Stream, and MAC / GTM are connected to optical modules SFP+ / QSFP / QSFP-DD via Ethernet. The FPGA-MMDMA queue, configuration instruction arbitration unit, FPGA-STDMA queue, and message traffic arbitration unit constitute the DMA queue (Queue-DMA). TrafficManager maps resource files / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2 based on the control path; / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2 are connected to registers Bar0 and Bar2 through the control path; Register Bar0 is connected to Queue-DMA via the ST control path, and register Bar2 is connected to Queue-DMA via the MM control path; register Bar2 is connected to MAC / GTM and optical modules SFP+ / QSFP / QSFP-DD via control paths respectively; Among them, register Bar0, register Bar2, optical module SFP+ / QSFP / QSFP-DD, MAC / GTM, and Queue-DMA constitute the Hardware layer; FPGA kernel driver, MM ring buffer set, and ST ring buffer set constitute the Kernel layer. The Hardware layer is connected to the Kernel layer via the PCI-E bus.

2. The virtual network simulation testing system according to claim 1, characterized in that: The control path, MM configuration path, ST service path, Ethernet, AXI-Lite / AXI-Stream bus, and PCI-E bus are all bidirectional connections.

3. The virtual network simulation testing system according to claim 1, characterized in that: The set of simulated containers is represented as docker1~dockerK; K≤min(x,y), where x represents the number of FPGA-MMDMA queue groups and y represents the number of FPGA-STDMA queue groups, and x≥4096 and y≥4096; Any of docker1 to dockerK is equivalent to: an independent PE / CE gateway or terminal virtual device, and has built-in: a routing protocol stack, a traffic generation module, a protocol parsing module, and a performance statistics module; Any of docker1~dockerK can be bound to any number and encoding of MM character devices and ST character devices to adapt to different business loads.

4. The virtual network simulation testing system according to claim 3, characterized in that: TrafficManager is based on a global traffic management program. Through the bridge unit, it uniformly manages docker1~dockerK to complete: the creation and destruction of emulated containers, the mounting and unbinding of character devices, the allocation of hardware queue resources, and large-scale topology scheduling, so as to achieve: hot-swappable management of virtual devices. The bridge unit is used to isolate management traffic and service message traffic by forwarding lifecycle instructions and topology adjustment instructions of the emulation container.

5. The virtual network simulation testing system according to claim 1, characterized in that: Based on / sys / ... / bdf / resource0 and / sys / ... / bdf / resource2, the trafficmanager executes the mmap system call to directly access registers Bar0 and Bar2 to perform: global port rate configuration, basic information statistics, and priority scheduling.

6. The virtual network simulation testing system according to claim 1, characterized in that: Based on FPGA kernel driver to generate: MM character device, ST character device, MM circular buffer, ST circular buffer; Each MM / ST character device corresponds to an MM / ST circular buffer, and each MM / ST circular buffer corresponds to an FPGA-MMDMA / FPGA-STDMA queue.

7. The virtual network simulation testing system according to claim 1, characterized in that: Register Bar0 is used to store ST message queue configuration, and register BAR2 is used to store MM scheduling information and flow table entry configuration; the FPGA-MMDMA queue is used for batch flow table and hardware configuration distribution, and the FPGA-STDMA queue is used for sending and receiving service messages. ST-ARB is used to poll / weighted priority arbitration of multi-stream service message queues to schedule messages to be sent to MAC / GTM via the AXI-Stream bus in an orderly manner; MM-ARB is used to perform serial arbitration of concurrent access operations to FPGA-MMDMA queues and registers to process instructions involving port configuration and batch flow table entries in an orderly manner.

8. An application method based on the virtual network simulation testing system according to any one of claims 1 to 7, characterized in that: The application methods involve: S1, the FPGA kernel driver completes the basic parameter configuration of the FPGA based on register Bar0 to generate all MM character devices and ST character devices; it supports the operation of MM character devices and ST character devices based on the FPGA-MMDMA queue / FPGA-STDMA queue. Synchronously initialize the Docker management channel between Trafficmanager and the bridge unit; S2. Based on the trafficmanager, map register BAR2-resources; create a simulation container according to the networking requirements, allocate MM character devices and ST character devices to it, and bind an independent CPU.

9. The application method according to claim 8, characterized in that: The application methods involve: S3. If there is an external test message entering the FPGA, then the external test message is split and passes through the FPGA-STDMA queue, ST ring buffer, and ST character device in sequence to reach the simulation container to generate a simulation message. The simulated message passes sequentially through the ST character device, the ST circular buffer, and the FPGA-STDMA queue before reaching the ST-ARB. After ST-ARB high-priority scheduling, simulation messages are output to the outside world. If no external test message exists, then: instructions involving batch flow tables and port configurations across the entire network are issued through the FPGA-MMDMA queue, and MM-ARB performs serial arbitration to process the relevant instructions.

10. The application method according to claim 9, characterized in that: The application methods involve: S4. Simulation messages perform external interactions based on Ethernet ports; If it is determined that the simulation topology needs to be adjusted, then the trafficmanager issues commands involving container start / stop and character device mounting / unbinding through the bridge unit to perform simulation container hot-plugging; Otherwise: Integrate FPGA hardware timestamp marking and container session layer statistics, and determine whether it is necessary to add a new routing protocol or customize the terminal model; If it is necessary to add routing protocols or custom terminal models, then: allocate idle FPGA-MMDMA / FPGA-STDMA queues through the development simulation container-image to put them into simulation; Otherwise: Output a complete simulation report for large-scale networking scenarios.

Images