CN115766438B

CN115766438B - DPDK-based interface management method and system

Info

Publication number: CN115766438B
Application number: CN202310010305.XA
Authority: CN
Inventors: 李宁森
Original assignee: Beijing Ruifuxin Technology Co ltd
Current assignee: Beijing Ruifuxin Technology Co ltd
Priority date: 2023-01-05
Filing date: 2023-01-05
Publication date: 2023-04-18
Anticipated expiration: 2043-01-05
Also published as: CN115766438A

Abstract

The application relates to the technical field of computers, in particular to a DPDK-based interface management method and system. The interface provides a processing function for network data packets; the configuration information of the interface is stored in a configuration file. The method may include: monitoring a preset operation; responding to the monitoring of the preset operation, and managing an interface influenced by the preset operation; in response to completing the managing, updating the configuration file based on the most recent configuration information of the interface. Therefore, dynamic updating of the interface configuration can be realized, and the interface configuration is saved.

Description

DPDK-based interface management method and system

Technical Field

The application relates to the technical field of computers, in particular to a DPDK-based interface management method and system.

Background

With the continuous development of network technology, network traffic is increasing day by day, network bandwidth is increasing continuously, and the processing performance of network equipment is challenged by the processing pressure of a large number of data packets.

Currently, there are three general types of data packet processing hardware platforms: a network accelerator, a network processor and a multi-core general processor. The first two implement packet acceleration by specialized hardware devices. While multi-core processing platforms have a large and mature software ecosystem, there are many performance bottlenecks in operating system kernel based network packet processing, and a solution application that eliminates these performance limitations while maintaining system compatibility is needed.

The DPDK (Data Plane Development Kit) is used for implementing high-speed network packet processing on a multi-core general processor platform. The network card device bypasses the system kernel and performs data packet polling processing in a user mode so as to maximize network performance.

However, on one hand, the DPDK hosts a network card device, and cannot use some commands of the system to manage the packet receiving and transmitting interface, and on the other hand, the DPDK only provides a basic operation interface of the network interface and does not implement a complete set of upper management framework to manage the packet receiving and transmitting interface, so a method for interface management based on the DPDK is required to be provided.

Disclosure of Invention

In view of this, the present application discloses an interface management method based on DPDK. The interface provides a processing function for network data packets; the configuration information of the interface is stored in a configuration file. The method may include: monitoring a preset operation; responding to the monitoring of the preset operation, and managing an interface influenced by the preset operation; in response to completing the managing, updating the configuration file based on the most recent configuration information of the interface.

In some embodiments, the configuration file is a yaml file, and/or the configuration file stores configuration information of at least one of the interfaces in a tree structure.

In some embodiments, the managing, in response to monitoring the preset operation, an interface affected by the preset operation includes: responding to the monitoring of the preset operation, and generating an operation event corresponding to the preset operation; the operation event comprises event processing logic preset for the preset operation; and managing the interfaces influenced by the preset operation based on the event processing logic included in the operation event.

In some embodiments, the preset operation is a modify operation for the configuration file; the generating of the operation event corresponding to the preset operation in response to the monitoring of the preset operation comprises: in response to monitoring the modification operation aiming at the configuration file, acquiring the configuration file after modification; for each available interface, generating an initialization event for the available interface in the case that the configuration file after modification does not include the configuration information of the available interface, and/or generating a reconfiguration event for the available interface in the case that the configuration file after modification includes the configuration information of the available interface and the configuration information of the available interface is changed; the managing, by the event processing logic based on the operation event, an interface affected by the preset operation includes: in the case that the operation event is a reconfiguration event for the available interface, determining a change item of the available interface based on the current configuration information and the modified configuration information of the available interface; in the case that the change item indicates that the enabling state of the available interface is changed, adjusting the available interface to a corresponding state; and resetting the available interface to reconfigure the available interface under the condition that the change item indicates that the number of queues and/or the quantity of queue resources of the available interface are changed.

In some embodiments, the preset operation is a plug or pull operation for a network card; the network card corresponds to a plurality of interfaces; the generating of the operation event corresponding to the preset operation in response to the monitoring of the preset operation comprises: generating an adding event aiming at the plurality of interfaces in response to monitoring the inserting operation aiming at the network card; in response to monitoring the pulling operation aiming at the network card, generating removal events aiming at the plurality of interfaces; the managing, by the event processing logic based on the operation event, an interface affected by the preset operation includes: setting the number of interfaces as available interfaces in response to the increase event; and in response to the removal event, deleting the interfaces and releasing corresponding resources.

In some embodiments, the preset operation is a state change operation for a target interface; the responding to the monitoring of the preset operation, and generating an operation event corresponding to the preset operation, including: generating a state change event for a target interface in response to monitoring a state change operation for the target interface; the managing, based on the event processing logic included in the operation event, the interface affected by the preset operation includes: responding to the state change event, and acquiring a target state of the target interface to be changed; and adjusting the target interface to the target state under the condition that the target interface is determined to be required to be changed into the target state actually according to the operating environment of the target interface.

In some embodiments, the configuration file is a yaml file, and the yaml file stores configuration information of at least one of the interfaces in a tree structure; said updating said configuration file based on the latest configuration information of said interface in response to completion of said managing, comprising: in response to the completion of the management, building a yaml node tree; traversing the latest configuration information of each interface, and generating a node to be mounted on the yaml node tree based on the latest configuration information; updating the configuration file based on the yaml node tree.

In some embodiments, the method further comprises: receiving an acquisition request of an interface running state through a telemetering component; responding to the acquisition request, and returning the interface running state; the interface operating state comprises at least one of: an interface list; interface configuration information; and the interface transmits and receives the packet statistical data.

In some embodiments, the interface comprises at least one interface queue; the interface queue is used for storing network data packets; each interface object corresponds to at least one route routine; the route routine is used for acquiring and processing the network data packet from the interface queue; the method for managing the route routine comprises the following steps: in response to receiving a registration request for a target routine of any interface, replacing the routine of any interface with the target routine under the condition that the target routine is not a default routine; in response to receiving the uninstall request of the target routine, replacing the target routine with a default routine in the case that the target routine is not the default routine.

The application also provides an interface management system based on the DPDK. The system includes an event generation component, an event processing component, an interface options component, a telemetry component, and an external interface component; the event generating component is used for monitoring a preset operation and generating an operation event corresponding to the preset operation in response to the monitoring of the preset operation; the event processing component is used for calling a function in the interface option component based on an event processing logic included in the operation event, managing the interface influenced by the preset operation, responding to the completion of the management, and updating a configuration file based on the latest configuration information of the interface; the telemetering assembly is used for responding to an interface running state obtaining request and returning to the interface running state; and the external interface component is used for responding to a management request of the routine and finishing the management of the routine.

In the solution described in the foregoing embodiment, after monitoring the preset operation, the interface affected by the preset operation may be managed, and the interface configuration file may be updated after the management is completed, on one hand, dynamic update of the interface configuration may be implemented, and compared with the related art, it is not necessary to suspend the project operation, which improves the interface management flexibility, and on the other hand, the configuration information of the interface may be stored by the configuration file, so that the interface configuration is saved.

In addition, the feedback of the interface running state can be completed, the operation and maintenance of the DPDK project are facilitated, the routine is registered or uninstalled, and the decoupling of the routine and the interface management is realized.

Drawings

The drawings that will be used in the description of the embodiments or the related art will be briefly described below.

Fig. 1 is a schematic flowchart illustrating an interface management method based on DPDK according to an embodiment of the present application;

FIG. 2 is a schematic view of the yaml document illustrated in the present application;

FIG. 3 is a flow chart illustrating an interface management event mechanism according to an embodiment of the present application;

FIG. 4 is a schematic illustration of an event shown in the present application;

FIG. 5 is a schematic diagram illustrating an event processing flow according to the present application;

FIG. 6 is a flowchart illustrating a method for generating an operational event after a modification operation is heard according to the present application;

FIG. 7 is a flowchart illustrating a method for generating an event based on a modified configuration file according to an embodiment of the present application;

FIG. 8 is a flow chart illustrating an interface management method according to the present application;

FIG. 9 is a schematic flow chart of a management interface according to the present application;

fig. 10 is a schematic flow chart of a method for generating an operation event after monitoring a network card plugging operation, shown in the present application;

FIG. 11 is a flow chart illustrating a method of event generation according to the present application;

FIG. 12a is a flow chart illustrating a method for removing an interface according to the present application;

FIG. 12b is a schematic flow chart of a method for adding interfaces according to the present application;

fig. 13 is a flowchart illustrating a method for generating an operation event after monitoring a state change operation of a target interface according to the present application;

FIG. 14 is a flow chart illustrating an exemplary interface management method according to the present application;

FIG. 15 is a flow chart illustrating a management interface according to the present application;

FIG. 16 is a flowchart illustrating a method for updating a configuration file according to the present application;

FIG. 17 is a schematic flow chart illustrating updating a configuration file according to the present application;

FIG. 18 is a flow chart illustrating a method for monitoring the operation status of an interface according to the present application;

FIG. 19 is a schematic diagram of a framework of interfaces and routines illustrated in the present application;

fig. 20 is a schematic flow chart of a method for managing route according to the present application;

fig. 21a is a schematic flow chart illustrating a method of registering a routine of routing according to the present application;

FIG. 21b is a schematic flow chart illustrating a method for offloading a routine, according to the present application;

FIG. 22 is a block diagram of an interface management system according to the present application;

FIG. 23 is a schematic diagram illustrating interaction between an interface receive-write packet unit and a functional unit according to an embodiment of the present application;

fig. 24 is a schematic structural diagram of an interface management device based on DPDK according to the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It should also be understood that the word "if" as used herein may be interpreted as "at ...when" or "when ...30, when" or "in response to a determination", depending on the context.

In some related arts, the DPDK-based interface management method includes the following two schemes:

firstly, the interface is configured once during program initialization, and then the configuration cannot be changed during program running until the program running is finished.

Secondly, defining an interface data type object according to the software requirement of the interface data type object, and repackaging a native operation interface; the DPDK cmdlene component is used to implement a dynamic management interface.

For the first scheme, the interface configuration related information is transmitted through the command line parameters, all required interface configurations are completed in the initialization stage, the configuration cannot be dynamically adjusted in the whole program operation stage, if the configuration needs to be modified, the operation is stopped, and the configuration is restarted after the configuration is modified, so that the interface management is not flexible.

For the second scheme, a basic interface management scheme is implemented, but the basic interface management scheme is highly coupled with the project, so that the basic interface management scheme is difficult to apply to other projects, the portability is poor, and the interface configuration is lost after the project operation is completed.

In view of this, the present application provides an interface management method based on DPDK. The method can manage the interface affected by the preset operation and update the interface configuration file after finishing the management after monitoring the preset operation, on one hand, the dynamic update of the interface configuration can be realized, compared with the related technology, the project operation does not need to be stopped, and the interface management flexibility is improved, on the other hand, the configuration information of the interface can be stored through the configuration file, so that the interface configuration is stored.

The embodiments are described below with reference to the drawings. Referring to fig. 1, fig. 1 is a schematic flowchart illustrating a DPDK-based interface management method according to an embodiment of the present application.

The DPDK-based interface management method illustrated in fig. 1 may be applied to an electronic device. The electronic device may execute the method by loading a software logic corresponding to the DPDK-based interface management method. The type of the electronic device may be a notebook computer, a server, a mobile phone, a Personal Digital Assistant (PDA), and the like. The type of the electronic device is not particularly limited in this application. The electronic device may also be a client device or a server device.

As shown in fig. 1, the method may include S102-S106. The present application does not specifically limit the order of execution of the steps unless specifically stated otherwise.

S102, monitoring preset operation.

The present application includes many types of interfaces. One type of interface is an interface that provides processing functions for network packets. The processing functions may include packet receiving and/or packet sending functions. This type of interface is an interface that needs to be managed by the DPDK. Other types of interfaces may also implement some of the preset functions. For example, a routine registration interface is used to provide routine registration functions. In the present application, an interface or a managed interface refers to an interface managed by a DPDK, and an interface with a name refers to other types of interfaces.

The preset operation refers to an operation that can cause the configuration of the managed interface to change, and can be set according to service requirements. For example, the preset operation may include network card hot plug, configuration file modification, interface state change, and the like. These preset operations all cause a change in the interface configuration.

In S102, some monitoring programs may be configured in advance for the preset operation to perform monitoring.

For example, monitoring can be performed by using rte dev event mechanism of the DPDK for network card hot plug. The rte dev event can report the plugging and unplugging actions of the network card in an interrupted mode. Namely, after the plugging action of the network card is monitored, reporting is carried out through an event mechanism, and monitoring is completed.

For another example, for the interface state change, the rte eth _ dev event mechanism of the DPDK may be used for monitoring. The rte eth _ dev event may report the interface status change information in the form of an interrupt. Namely, after monitoring the interface state change, reporting is carried out through an event mechanism, and monitoring is completed.

And S104, responding to the monitoring of the preset operation, and managing the interface influenced by the preset operation.

Some management logics corresponding to the preset operation can be preset in the DPDK, and after the preset operation is monitored, the management is completed through the management logics. The management logic may be set according to business requirements.

The management may include allocating resources to the interface, changing the state of the interface, setting the functions of the interface (receiving and/or sending packets), and so on. The management logic can be set according to different management requirements. For example, for resource allocation, resource allocation logic may be configured to allocate resources, such as memory resources, for the interface.

S106, responding to the completion of the management, and updating the configuration file based on the latest configuration information of the interface.

After the management is completed, the managed interfaces have the latest configuration information, and then the configuration file can be updated based on the latest configuration information, so that the current configuration file is saved.

Through the scheme recorded in S102-S106, after the preset operation is monitored, the interface affected by the preset operation can be managed, and the interface configuration file can be updated after the management is completed, on one hand, dynamic update of the interface configuration can be realized, compared with the related art, project operation does not need to be suspended, and interface management flexibility is improved, on the other hand, configuration information of the interface can be stored through the configuration file, so that the interface configuration is saved.

In some embodiments, the storage means for the configuration file may include a file store or a database store.

However, because the number of DPDK interface configurations is limited and there is a hierarchical relationship between the configurations, new external dependencies may be added by file storage or database storage.

In some embodiments, to reduce external dependencies, the configuration file is a yaml file.

Yaml, yaml Ain't Markup Language, is a format for expressing data serialization with high readability. Yaml references a variety of other languages, including: c language, python, perl, and gets inspiration from XML, data format of email (RFC 2822).

The Yaml format has simple grammar and clear hierarchy, supports various data types and has good software ecology. By utilizing the characteristic, the interface configuration information with the hierarchical relationship can be stored under the condition that no additional external dependency is added.

In some embodiments, the configuration file stores configuration information for at least one of the interfaces in a tree structure. The design is also used for storing interface configuration information with a hierarchical relationship under the condition that no additional external dependency is added.

In some embodiments, the configuration file is a yaml file, and the yaml file stores configuration information of at least one of the interfaces in a tree structure.

Please refer to fig. 2, fig. 2 is a schematic view of the yaml document in the present application.

As shown in fig. 2, the yaml file may include the following elements:

port: the root node is a primary child node of the root node, and the primary child node is the id number of each interface;

the Name: the pci address name of the interface, this name and id number are used for dpdk discerns the interface together;

alias: the attribute is an interface alias automatically generated by an interface module according to an interface speed, and considering that a pci address is not friendly to a software external user, an alias is provided for a user identification interface, an interface naming method refers to cisco, and the alias is automatically generated by respectively using Eth, FE, gigE and 10GigE as prefixes and using an interface identification sequence number as a suffix aiming at 10M, 100M, 1000M and 10000M interfaces;

rx: configuring the packet receiving direction;

enable: and if the packet receiving routine is enabled, starting the packet receiving routine to perform packet capturing processing after the packet receiving routine is started.

The Queue: related configuration of a packet receiving queue;

num: the number of the packet receiving queues, and each queue corresponds to one packet receiving thread.

mbufNum: and the number of the packet receiving single queues mbuf is used for allocating the data packet memory.

In the configuration, the name item is used for reading configuration of the interface management module, the alias item is used for identifying the configuration of the interface by the user management program, so that the two items belong to read-only configuration, other configurations can be read and written, and in order to ensure that the configuration file is not randomly tampered to cause interface configuration disorder, the file operation authority is set to be only read and written by the interface management module and the user management program, and other users only read.

These elements have a hierarchical relationship. The Port is a root node, the subordinate nodes of the Port are interface ID nodes, and the subordinate nodes of the interface ID nodes are Name, lias and Rx nodes. The Rx node lower level comprises Enable, queue, num and mbufNum nodes.

By combining the yaml file with the tree structure, interface configuration information can be stored more clearly and conveniently.

It should be noted that the interfaces illustrated in fig. 2 are all packet receiving interfaces, and therefore only rx elements exist; if the interface is a packet sending interface, the interface comprises a tx element; if the interface is a transceiving packet interface, the interface comprises rx and tx elements at the same time.

In the process of continuously operating the interface management method, there are a plurality of preset operations, and these operations may be monitored simultaneously or in a short time, so that the management interface may be confused. In some embodiments, to avoid interface management race confusion, management may be performed through an event mechanism.

Referring to fig. 3, fig. 3 is a flowchart illustrating an interface management event mechanism according to an embodiment of the present application. Fig. 3 is a supplementary explanation for S104. As shown in FIG. 3, the illustrated event mechanism includes S302-S304.

S302, responding to the monitoring of the preset operation, and generating an operation event corresponding to the preset operation; the operation event comprises event processing logic preset for the preset operation.

The event refers to an abstraction of the interface operation request. The event processing logic corresponds to a preset operation, and can be set in advance according to business requirements. The illustrated event handling logic is a piece of executable code that is executed to perform interface management. For example, the preset operation is a network card plugging operation, the event logic may be to determine a preset operation type, and if the preset operation is a plugging operation, the interface is deleted and the interface resource is released.

Referring to fig. 4, fig. 4 is a schematic diagram illustrating an event according to the present application. As shown in fig. 4, an event may include: a port (interface ID), func _ cb (callback processing function), free _ cb (destruction function), and param (user parameter). Wherein, portid refers to the interface id to be operated. func _ cb refers to a callback processing function of an event, i.e., the preset event processing logic. Param refers to incoming user parameters. free _ cb refers to the destroy function of param.

S304, managing the interface influenced by the preset operation based on the event processing logic included by the operation event.

The operation event generated in S302 may be stored in an event queue. In S304, a timing task may be executed by a start thread (e.g., a main thread), an operation event is acquired from the event queue, and the management is completed by executing the event processing logic (executable code).

Therefore, through S302-S304, the concurrent events can be processed in order based on the event mechanism, and the interface management competition confusion is avoided.

Referring to fig. 5, fig. 5 is a schematic view illustrating an event processing flow according to the present application. The steps illustrated in fig. 5 may be applied to one timing task of S304.

As shown in fig. 5, the illustrated process may include:

s501, judging whether an unprocessed event exists in the queue or not, and executing S502 if the unprocessed event exists; if there is no unprocessed event, S507 is executed.

And S502, acquiring a head of queue event.

S503, executing the func _ cb callback processing function of the acquisition event.

S504, whether param (user parameter) of the acquired event needs to be released is judged. Releasing execution S505 if necessary; if not, execution S506 is performed.

S505, the free _ cb calling the acquisition event releases param.

S504, the acquisition event is released, and then S501 is executed.

And S507, destroying the timer, and then ending the task.

The events in the event queue can be regularly and orderly executed through S501-S507, and the interface management is ensured not to be confused.

In some embodiments, the preset operation is a modify operation for the configuration file. In the interface management method, the interface may be managed based on a modification operation for the configuration file.

The modification operation may include an operation of uploading the configuration file through the configuration file upload interface based on a service requirement by any user, or a modification operation of the configuration file based on a code in the operating process of the DPDK program, and the like.

Referring to fig. 6, fig. 6 is a flowchart illustrating a method for generating an operation event after a modification operation is monitored according to the present application. The method illustrated in fig. 6 is a detailed description of S302. As shown in fig. 6, the method may include S602 and S604.

S602, in response to the monitoring of the modification operation for the configuration file, acquiring the modified configuration file.

A file monitor (file system listener) may be deployed in advance, and the file monitor may read the configuration file from the storage medium after listening to the modification operation. It should be noted that the currently read configuration file is a modified configuration file.

Through the analysis operation, the configuration information of each interface stored in the configuration file can be analyzed.

S604, for each available interface, generating an initialization event for the available interface in the case that the configuration file after modification does not include the configuration information of the available interface, and/or generating a reconfiguration event for the available interface in the case that the configuration file after modification includes the configuration information of the available interface and the configuration information of the available interface is changed.

The available interfaces refer to all interfaces which can be normally used for receiving and sending packets. These available interfaces may be used for sending and receiving packets, but may not be present in the configuration file.

To this end, in S604, each available interface may be traversed and, upon traversing to any available interface, a different event may be generated depending on whether the available interface appears in the modified configuration file.

Through S602 to S604, on one hand, if the configuration file does not include the available interface, which indicates that the available interface is not configured, an initialization event may be initiated for reporting. The initialization event is an event for generating configuration information for interface initialization based on preset initialization logic. After monitoring the initialization event, the DPDK procedure may perform a preset initialization configuration on an interface that is not configured. Therefore, when the program is operated for the first time and the configuration file has no interface configuration, the interface management module can generate an initial default interface configuration according to the process and store the initial default interface configuration in the configuration file in a later required process.

On the other hand, if the available interface is included in the configuration file, it is indicated that the available interface has been configured. Then, the current configuration information of the available interface can be obtained and compared with the configuration information in the configuration file to determine whether the configuration information of the interface is changed. If the configuration information is changed, a reconfiguration event aiming at the available interface can be generated and reported so as to reconfigure the interface with changed configuration information in time.

Referring to fig. 7, fig. 7 is a flowchart illustrating a method for generating an event based on a modified configuration file according to an embodiment of the present application. The method illustrated in fig. 7 is a detailed description of S604. As shown in fig. 7, the method may include S701-S709.

And S701, analyzing the configuration file.

In this step, the configuration information of each interface stored in the configuration file can be analyzed through the analysis operation.

S702, iterating the next available interface.

This step may be iterated in turn in a preset order (e.g., from small to large, or from large to small) based on the number of available interfaces.

S703, whether the configuration information of the available interface is found in the configuration file, if the configuration information of the available interface is found, the S704 is executed; if not, executing S707.

S704, checking the configuration information of the available interface in the configuration file.

In this step, the current configuration information of the available interface can be obtained, and the comparison result is obtained by comparing and checking the current configuration information with the configuration information in the configuration file.

S705, judging whether the available interface needs to be reconfigured according to the check result, and if so, executing the step S706; if S709 is not required to be executed.

In this step, if the comparison result indicates that the two are not consistent, it indicates that the available interface needs to be reconfigured, otherwise, the available interface does not need to be reconfigured.

S706 generates a port reconfiguration event, and executes S708.

S707 generates a port init (initialization) event, and S708 is executed.

And S708, reporting the event.

S709, judging whether the iteration of the available interface is finished or not, and if so, finishing; if not, S702 is executed.

The method described in S701 to S709 is an implementation of generating an event, and can generate an event in consideration of two situations, namely, an unconfigured interface and an event in which interface configuration information is changed, so as to ensure that a DPDK can perform interface management on the two situations.

In some embodiments, in the interface management method, in the case of polling to the reconfiguration event for the available interface generated through S604, the interface management may be completed based on the method illustrated in fig. 8.

Please refer to fig. 8, fig. 8 is a flowchart illustrating an interface management method according to the present application. As shown in fig. 8, the method may include: S802-S806.

S802, in the case that the operation event is a reconfiguration event for the available interface, determining a change item of the available interface based on the current configuration information and the modified configuration information of the available interface.

The change item is an item in the configuration information that is changed.

In this step, in a case that the operation event is a reconfiguration event for the available interface, the current configuration information of the available interface may be obtained and compared with the configuration information in the configuration file to obtain the change item.

S804, under the condition that the enabled state of the available interface is changed by the change item, the available interface is adjusted to a corresponding state.

This step includes at least two cases: in the case that the enabled state of the interface is from down to up, the available interface can be configured to be the enabled state; and in the case that the change item indicates that the enabling state of the available interface is from up to down, configuring the available interface into a disabling state.

S806, in case that the change item indicates that the queue number and/or the queue resource amount of the available interface is changed, resetting the available interface to reconfigure the available interface.

The available interfaces need to be reset to change the number of queues and/or the amount of queue resources of the available interfaces.

The interface reconfiguration may be completed with a response reconfiguration event, via S802-S806.

Referring to fig. 9, fig. 9 is a schematic flow chart of a management interface according to the present application. The method illustrated in FIG. 9 is a detailed description of S802-S806. As shown in fig. 9, the method may include S901-S907.

S901, comparing the configuration change items.

S902, check whether there is a change item that requires port disable (interface disable). If yes, executing S903; if not, go to S904.

In this step, a change item indicating that the enable state is changed from up to down, or a change item indicating that the number of queues and/or the amount of queue resources needs to be changed is found, and it can be determined that a change item that the interface needs to be disabled is found.

S903, port disable is executed, and the interface transceiving packet function is closed.

S904 checks whether or not there is a change item that requires port reset. If yes, executing S905; if not, go to step S906.

In this step, a change item indicating that the number of queues and/or the amount of queue resources needs to be changed is found, and it can be determined that a change item of interface reset is found.

S905, executing the port reset, and reconfiguring the interface according to the existing configuration of the receiving and sending packets.

S906 checks whether there is a change item that requires port enable. If yes, executing S907; if not, the interface management is ended.

In this step, a change item indicating that the number of queues and/or the amount of queue resources needs to be changed is found, and it can be determined that a change item of the interface enable is found.

S907, executing port enable and starting the interface packet receiving and sending function.

Through the scheme recorded in S901-S907, corresponding reconfiguration can be completed for various reconfiguration information.

In some embodiments, the preset operation is a plug or pull operation for a network card. The network card corresponds to a plurality of interfaces. In the interface management method, the interfaces can be managed based on plug or pull operations.

Referring to fig. 10, fig. 10 is a schematic flow chart of a method for generating an operation event after monitoring a network card plugging operation according to the present application. The method illustrated in fig. 10 is a detailed description of S302. As shown in fig. 10, the method may include S1002 and S1004.

S1002, in response to the monitoring of the plug-in operation aiming at the network card, generating an adding event aiming at the plurality of interfaces.

And S1004, generating removal events aiming at the plurality of interfaces in response to the fact that the pulling operation aiming at the network card is monitored.

Monitoring of network card hot plug can be realized by using rte dev event mechanism based on DPDK in advance. The rte dev event can report the plugging and unplugging actions of the network card in an interrupted mode. Namely, after the plugging action of the network card is monitored, reporting is carried out through an event mechanism, and monitoring is completed.

Referring to fig. 11, fig. 11 is a flowchart illustrating an event generating method according to the present application. The method illustrated in fig. 11 is a supplementary explanation of S1002 and S1004. As shown in fig. 11, the method may include S1101-S1104.

S1101, judging the operation type. If the operation is to pull the network card, S1102 is executed; if the operation is inserting a network card, the operation is executed S1103.

S1102, generate remove event. S1004 is executed.

S1103, an add event is generated. S1004 is executed.

S1104, reporting the event.

Through the steps described in S1101-S1104, the generation of the add-drop event or the add event can be completed.

In some embodiments, in the interface management method, in a case of polling to a removal event or an addition event for the number of interfaces, the interface management may be completed based on the method illustrated in fig. 12a and 12 b.

Referring to fig. 12a, fig. 12a is a schematic flow chart of an interface removing method according to the present application. As shown in fig. 12a, the method may include: S1201-S1202.

And S1201, closing the interface.

S1202, interface related resources are released.

Please refer to fig. 12b, fig. 12b is a schematic flow chart of the interface adding method according to the present application. As shown in fig. 12b, the method may include: S1203-S1204.

S1203, initializing an interface.

In this step, through the steps of S602-S604, initial default configuration may be performed for the newly added interface.

And S1204, configuring an interface according to the initial default configuration.

Through S1201-S1202 and S1203-S1204, interface management can be completed in a network card plugging scene.

In some embodiments, the preset operation is a state change operation for a target interface. The target interface refers to any managed interface. In the interface management method, the state of the target interface may be managed based on the state change operation of the target interface.

In the interface method, a state change event for a target interface may be generated in response to monitoring a state change operation for the target interface.

The rte eth _ dev event mechanism of the DPDK may be used to monitor the change of the interface status. The rte eth _ dev event may report the interface status change information in the form of an interrupt. Namely, after monitoring the interface state change, reporting is carried out through an event mechanism, and monitoring is completed.

In some embodiments, in addition to the state change operation, other operations may also be monitored using the rte eth _ dev event mechanism according to the traffic demand. The other operations may be set as desired. Examples of available interfaces include interfaces being released, newly discovered interfaces, and the like. If other operations can cause the interface configuration to change, corresponding event response logic can be registered to complete the interface management under other operations.

Referring to fig. 13, fig. 13 is a flowchart illustrating a method for generating an operation event after monitoring a state change operation of a target interface according to the present application. The method illustrated in fig. 13 is a detailed description of S302. As shown in FIG. 13, the method may include S1301-S1304.

And S1301, judging the operation type. If it is Lsc (link status change, which means the state of the interface is changed from UP to DOWN or from DOWN to UP), the operation proceeds to S1302; the other events execute S1303.

S1302, an lsc event (status change event) is generated. S1304 is performed.

S1303, generate another event. No reporting is performed.

And S1304, reporting the event.

Through S1301-S1304, an interface state change event can be generated and reported, and other events can be recorded.

In some embodiments, in the interface management method, in the case of polling to the event of changing the state of the interface by the generation, the interface management may be completed based on the method illustrated in fig. 14.

Referring to fig. 14, fig. 14 is a schematic flow chart of an interface management method according to the present application. As shown in fig. 14, the method may include: S1402-S1404.

S1402, responding to the state change event, and acquiring the target state after the target interface is changed.

The step can acquire the changed state of the target interface indicated in the state change event.

S1404, according to the running environment of the target interface, under the condition that the target interface is determined to need to be changed into the target state, adjusting the target interface to the target state.

In this step, whether to switch the state may be analyzed based on the current operating environment of the target interface. The runtime environment may include runtime information upstream and downstream of the target interface. The operation information may include whether the network card is working, whether the service party calls the interface, the packet receiving and transmitting rate of the network card, the packet receiving and transmitting backpressure between the network card and the service party, and the like. The operation information can be set according to the service requirement. Based on the running information, whether the state switching of the target interface is determined or not is analyzed, and the target interface is adjusted to the target state under the condition that the state switching is really needed.

Through S1402-S1404, the state adjustment of the target interface can be completed in a situation where the state change operation of the target interface is monitored.

Please refer to fig. 15, fig. 15 is a schematic flow chart of a management interface according to the present application. The method illustrated in FIG. 15 is a detailed description of S1402-S1404. As shown in fig. 15, the method may include S1501-S1506.

S1501, acquiring the interface link state.

S1502, judging the current interface state. If DOWN, executing S1503; if UP, then S1504 is performed.

S1503, whether the current interface needs to execute the disabling operation is judged. If necessary, perform S1505; if not, the interface management is finished.

In this step, it may be determined whether the network card is receiving and sending packets, or whether the service party needs to use the current interface, and if the network card is not working, or the service party does not call the current interface, it may be determined that the disabling operation needs to be performed. Otherwise no disabling operation need be performed.

S1504, judging whether the current interface needs to execute the enabling operation. If necessary, executing S1506; if not, the interface management is ended.

In this step, it can be determined whether the network card is transmitting/receiving packets or whether the service party needs to use the current interface, and if the network card is working or the service party needs to call the current interface, it can be determined that the enabling operation needs to be executed. Otherwise the enabling operation need not be performed.

S1505, performs a disabling operation on the interface.

S1506, an enable operation is performed on the interface.

Through S1501 to S1506, interface state switching can be completed for the case of interface state change.

In some embodiments, after interface management is completed for any of the predetermined operations, the configuration file is updated based on the latest configuration information of the interface. The configuration file is a yaml file, and the yaml file stores configuration information of at least one interface in a tree structure.

Referring to fig. 16, fig. 16 is a flowchart illustrating a method for updating a configuration file according to the present application. Fig. 16 is a detailed description of S106. As shown in FIG. 16, the method may include S1602-S1606.

S1602, in response to the completion of the management, a node tree of yaml (data serialization format) is newly created.

In this step, a storage space may be allocated for the yaml node tree to store node information.

S1604, traversing the latest configuration information of each interface, and generating a node to be hung on the yaml node tree based on the latest configuration information.

In this step, the latest configuration information of each interface may be traversed, and after the latest configuration information is traversed, the interface ID is used as a node index, and the latest configuration information is stored in a storage space corresponding to the node. The node index is then mounted below the yaml root node.

After traversing each interface, building a yaml node tree.

S1606, updating the configuration file based on the yaml node tree.

In this step, a preconfigured update configuration file interface may be called, and the yaml node tree is substituted for the original node shu2, so as to complete the update of the configuration file.

Through S1602-S1606, after the interface management is completed, the configuration file may be updated based on the latest configuration information of the interface.

Please refer to fig. 17, fig. 17 is a flowchart illustrating a process of updating a configuration file according to the present application. The steps illustrated in FIG. 17 are detailed descriptions of S1602-S1606. As shown in fig. 17, the method may include S1701-S1703.

S1701, a yaml node tree is newly built.

The process of creating the node tree can be understood as a process of allocating a storage space.

S1702, add the relevant configuration of all interfaces to the yaml node tree.

The generation of the yaml node tree can be completed by traversing the interface in the step.

S1703, calling the yaml node tree to a corresponding yaml dump interface, and overwriting the yaml node tree in the configuration file.

The yaml dump interface was developed in advance for updating configuration files. Configuration file updates can be done by calling the yaml dump interface.

Through S1701-S1703, after the interface management is completed, the configuration file is updated based on the latest configuration information of the interface.

In some embodiments, the telemetric component of the DPDK may also be used to complete the feedback of the operating state of the interface, so as to facilitate the operation and maintenance of the DPDK item.

Referring to fig. 18, fig. 18 is a schematic flow chart of an interface operation state monitoring method according to the present application. As shown in fig. 18, the method may include S1802-S1804.

And S1802, receiving an acquisition request of the interface running state through a telemeasurement component.

The telemeasurement component is used for providing relevant information of an internal interface for the outside of software and is realized based on the dpdk telemeasurement v 2.

In this step, a telemetric thread is started in the dpdk application, and a specified UNIX domain socket is monitored on the thread, so as to achieve the purpose of receiving an acquisition request of the interface running state. If the external part needs to initiate a request, the UNIX domain socket needs to be linked, the registered query command is sent to the socket in the json format, the telemeasure finds the corresponding callback function according to the requested command, and the request result is returned in the json format.

And S1804, responding to the obtaining request, and returning the running state of the interface.

The running state of the interface can be set according to the service requirement. In some embodiments, the interface operational state may include at least one of: an interface list; interface configuration information; and the interface transmits and receives the packet statistical data.

In this step, the interface running state may be returned through a json format.

Through steps S1802 to S1804, the feedback of the interface operating state may be completed by using the telemetric component of the DPDK, which is convenient for operation and maintenance of the DPDK project.

In some embodiments, the DPDK application can customize the packet receiving and sending processing, realize the decoupling of the service module and the interface module, and the DPDK application can conveniently customize the packet receiving and sending processing without changing the code of the interface management part, and can meet various service requirements.

Considering that this module is an interface management module, it should be decoupled from the downstream traffic processing, and the main location of decoupling is in the receive-write packet portion and the subsequent traffic processing portion of the data packet. The polling capture of the data packet belongs to the control content of the interface management module, and the processing of the data packet is positioned in the polling internal loop. If decoupling is desired, extensive processing is required.

Based on the above principles, the following framework of interfaces and routines can be devised:

the interface comprises at least one interface queue; the interface queue is used for storing network data packets; each interface object corresponds to at least one route routine; the routing routine is used for acquiring and processing the network data packet from the interface queue.

The framework can be employed to decouple the routine from the interface. The service party can deploy the routine of route according to the requirement without influencing the code calculation of the interface management part.

Referring to fig. 19, fig. 19 is a block diagram of an interface and routine framework according to the present application. As shown in FIG. 19, port _0 (interface _ 0) is for an (mbuf pool) memory pool. The memory pool is corresponding to n queues. The queue is used for storing network data packets sent and received by port _ 0. Each queue corresponds to a respective route (instance).

The queue.num and queue.mbufnum of each interface (e.g., the interface configuration file illustrated in fig. 2) are configured in the configuration information of the interfaces. The mbuf pool size corresponding to each interface can be obtained according to the following formula:

mbufPoolSize = queue.num * (queue.mbufNum + BURST_SIZE) + lcoresNum * MBUF_CACHE_SIZE。

the BURST _ SIZE, lcoresNum, and MBUF _ CACHE _ SIZE are all preset according to dependent hardware performance.

Under the framework illustrated in fig. 19, one lcore may be allocated to each interface queue according to the queue, and each lcore may run one route.

The framework illustrated in fig. 19 may decouple the routine from the interface. The service party can deploy the routine of route according to the requirement without influencing the code calculation of the interface management part.

Under the framework illustrated by any of the foregoing embodiments, the present application further supports management of a routine developed by a business party.

Referring to fig. 20, fig. 20 is a schematic flow chart of a method for managing route according to the present application. As shown in fig. 20, the method may include: S2002-S2004.

S2002, in response to receiving a registration request for a target routine (instance) of any interface, in the case that the target routine is not a default routine, replacing the routine of the any interface with the target routine.

The default routine may be set according to business requirements. For example, the default routine may be an empty routine.

In this step, the service party may develop a target routine for any interface, and then initiate the registration request by calling a routine registration interface.

In response to the registration request, it may be determined whether the target routine is a default routine, and if so, the routine does not need to be replaced, and if not, the replacement needs to be completed.

S2004, in response to receiving the unloading request of the target routine, replacing the target routine with the default routine when the target routine is not the default routine.

In this step, the service party may initiate the offload request by calling an offload routine offload interface without running the target routine.

In response to the unloading request, it may be determined whether the target routine is a default routine, if so, the target routine does not need to be replaced by the default routine, and if not, the target routine needs to be replaced by the default routine to complete unloading.

Through the scheme recorded in the S2002-S2004, the route routine developed by the business party can be managed, and various business scenes are supported.

Referring to fig. 21a, fig. 21a is a schematic flow chart of a method for registering a routine of routing according to the present application. Fig. 21a is a detailed description of S2002. As shown in FIG. 21a, the method includes S2101-S2106.

S2101, determine whether the route to be registered is default route. If not, go to S2102; if yes, the registration process is ended.

The default routine is an empty routine. In the step, whether the route to be registered comprises any code can be judged to be default route.

S2102, disabling the port corresponding to the route to be registered, and closing the package receiving and sending routine.

S2103, replacing the route corresponding to the port as the route to be registered.

S2104, the port is enabled, and the packet sending and receiving routine is started.

S2105, judging whether the replaced routine is default route. If not, executing S2106; if yes, the registration process is ended.

S2106, the replaced routine is released.

The routine registration can be completed through S2101-S2106.

Referring to fig. 21b, fig. 21b is a schematic flow chart illustrating a method for unloading a routine of route according to the present application. Fig. 21b is a detailed description of S2004. As shown in FIG. 21b, the method includes S2107-S2111.

S2107, judging whether the route to be unloaded is the default route. If not, executing S2108; if yes, the unloading process is ended.

S2108, forbidding the port corresponding to the route to be unloaded, and closing the packet receiving and sending routine.

S2109, replacing the original route corresponding to the port as default route.

S2110, enabling the port and starting a packet receiving and sending routine.

S2111, the replaced routine is released.

The route unloading can be completed through S2107-S2111.

The application also provides an interface management system based on the DPDK. The system can utilize the event generation component, the event processing component and the interface option component to manage the interface influenced by the preset operation and update the interface configuration file after the preset operation is monitored, on one hand, the dynamic update of the interface configuration can be realized, compared with the related technology, the project operation does not need to be stopped, the interface management flexibility is improved, on the other hand, the configuration information of the interface can be stored through the configuration file, so that the interface configuration is stored, compared with the related technology, the decoupling can be carried out with the project, the transportability of the interface configuration is improved, and the interface configuration can not be lost after the project operation is finished.

In addition, the system can also utilize a telemetering component to complete the feedback of the running state of the interface, so that the operation and maintenance of the DPDK project are facilitated. The system can also register or uninstall the routine of the routine by utilizing an external interface component, so as to realize the decoupling of the routine and the interface management.

Referring to fig. 22, fig. 22 is a schematic structural diagram of an interface management system according to the present application. As shown in fig. 22, the illustrated system may include an event generation component 2201, an event processing component 2202, an interface options component 2203, a telemetry component 2204, and an external interface component 2205. The interface management system is used to manage the interfaces illustrated in fig. 22.

The event generating component 2201 is configured to monitor a preset operation, and generate an operation event corresponding to the preset operation in response to the preset operation being monitored.

For the preset operation, operation events, and the related description of the processing method of the event generating component 2201, reference may be made to any of the foregoing embodiments. And will not be described in detail herein.

For example, the preset operation is a configuration file modification operation, and the steps illustrated in S701 to S709 may be referred to generate a relevant event and report the event to the event processing component 2202.

For another example, the prediction operation is a network card insertion or removal operation, and the steps illustrated in S1101-S1104 may be referred to generate a relevant event and report the event to the event processing component 2202.

For another example, the preset operation is an interface state change operation, and the steps illustrated in S1301 to S1304 may be referred to generate a related event and report the related event to the event processing component 2202.

The event processing component 2202 is configured to call a function in the interface option component 2203 based on an event processing logic included in the operation event, manage an interface affected by the preset operation, and update a configuration file based on the latest configuration information of the interface in response to completion of the management.

Many functions corresponding to the event handling logic may be pre-registered in the interface options component 2203. As shown in fig. 22, these functions are used to complete event processing.

Reference may be made to any of the foregoing embodiments with respect to the flow of operational event processing, the flow of management interfaces, and the flow of updating configuration files.

For example, the operation event processing may refer to the steps illustrated in S501 to S507.

For example, in the case where the preset operation is a profile modification operation, the interface management can be completed with reference to the steps illustrated in S901 to S907. In the case where the preset operation is a network card insertion or removal operation, the interface removal may be completed with reference to the steps illustrated in S1201 to S1202, and the interface addition may be completed with reference to the steps illustrated in S12033 to S1204. In the case where the preset operation is an interface state change, the interface state switching may be completed with reference to the steps indicated by S1501 to S1506.

For example, the flow of updating the configuration file may refer to the steps illustrated in S1701 to S1703.

The telemetry component 2204 is configured to return the interface operating status in response to the interface operating status obtaining request.

The workflow of telemetry component 2204 may be described with respect to the operational status of the interface, in any of the embodiments described above.

For example, the workflow of the telemetry component 2204 may be as illustrated with reference to steps S1802-S1804.

The external interface component 2205 is configured to respond to a management request of a route routine and complete route routine management.

Management of the routine may include registration and uninstallation.

The routine and the interface can be interfaced with the interface framework according to any of the embodiments described above. For example, reference may be made to the frame illustrated in figure 19.

Referring to fig. 23, fig. 23 is a schematic diagram illustrating interaction between an interface write packet receiving unit and a functional unit according to an embodiment of the present application. As shown in fig. 23, the external interface components include a routine (instance) registration interface and a routine offload interface. The routine includes three parts: pre, process, aft.

Where Pre (preprocessing), called before starting to receive or send packets, performs some preprocessing operations. Process (intermediate Process) processes the network packet. Aft (post-processing), after the interface is disabled, is responsible for the release and cleanup functions of some resources.

The interface write packet unit may include a drive write packet subunit, a preprocessing subunit, and a corresponding routine. The routine is registered through a registration interface and is developed by a service party.

The drive receiving and writing packet subunit can drive receiving or writing packets according to the service requirement.

The preprocessing subunit may include two preprocessing operations, filter and timestamp. The filter is used for filtering the network data packet based on a preset filtering rule, and the timestamp is used for stamping the timestamp for the receiving and writing packet.

Wherein reference may be made to any of the embodiments described above with respect to the flow of route registration and offloading.

For example, routine registration may refer to the steps illustrated by S2101-S2106. The unloading of the route can refer to the steps illustrated by S2107-S2111.

In some embodiments, in addition to the interface for providing the service party with the management routine, the external interface component may include many other predefined functional interfaces for providing the functionality of the operational interface to external modules (e.g., service party modules). For example, the configuration file uploading interface is used for the administrator to upload the configuration file. As another example, an event registration interface is used to register events.

In the DPDK-based management interface system, the event generating component, the event processing component, and the interface option component may be used to manage the interface affected by the preset operation and update the interface configuration file after the preset operation is monitored, on one hand, dynamic update of the interface configuration may be implemented, and compared with the related art, the interface management flexibility may be improved without suspending the operation of the project.

Corresponding to any of the foregoing embodiments, the present application also provides a DPDK-based interface management apparatus. The interface provides a processing function for network data packets; the configuration information of the interface is stored in a configuration file.

Referring to fig. 24, fig. 24 is a schematic structural diagram of an interface management device based on DPDK according to the present application.

As shown in fig. 24, the apparatus 2400 may include:

a monitoring module 2410, configured to monitor a preset operation;

a management module 2420, configured to manage, in response to monitoring the preset operation, an interface affected by the preset operation;

an update module 2430 for updating the configuration file based on the latest configuration information of the interface in response to completion of the managing.

In some embodiments, the management module 2420 is further configured to:

responding to the monitoring of the preset operation, and generating an operation event corresponding to the preset operation; the operation event comprises event processing logic preset for the preset operation;

and managing the interfaces influenced by the preset operation based on the event processing logic included in the operation event.

In some embodiments, the preset operation is a modify operation for the configuration file;

the management module 2420, further configured to:

in response to monitoring the modification operation aiming at the configuration file, acquiring the configuration file after modification;

for each available interface, generating an initialization event for the available interface in the case that the configuration file after modification does not include the configuration information of the available interface, and/or generating a reconfiguration event for the available interface in the case that the configuration file after modification includes the configuration information of the available interface and the configuration information of the available interface is changed;

in the case that the operation event is a reconfiguration event for the available interface, determining a change item of the available interface based on the current configuration information and the modified configuration information of the available interface;

in the case that the change item indicates that the enabling state of the available interface is changed, adjusting the available interface to a corresponding state;

and resetting the available interface to reconfigure the available interface under the condition that the change item indicates that the queue number and/or the queue resource amount of the available interface are changed.

In some embodiments, the preset operation is a plug-in or plug-out operation for a network card; the network card corresponds to a plurality of interfaces;

the management module 2420 is further configured to:

responding to the monitoring of the insertion operation aiming at the network card, and generating an adding event aiming at the plurality of interfaces;

in response to monitoring the pulling operation aiming at the network card, generating removal events aiming at the plurality of interfaces;

setting the number of interfaces as available interfaces in response to the increase event;

and in response to the removal event, deleting the interfaces and releasing corresponding resources.

In some embodiments, the preset operation is a state change operation for a target interface;

the management module 2420, further configured to:

generating a state change event for a target interface in response to monitoring a state change operation for the target interface;

responding to the state change event, and acquiring a target state of the target interface to be changed;

and adjusting the target interface to the target state under the condition that the target interface is determined to be required to be changed into the target state actually according to the operating environment of the target interface.

In some embodiments, the configuration file is a yaml file, and the yaml file stores configuration information of at least one of the interfaces in a tree structure;

the update module 2430, further configured to:

in response to completion of the management, creating a yaml node tree;

traversing the latest configuration information of each interface, and generating a node to be mounted on the yaml node tree based on the latest configuration information;

updating the configuration file based on the yaml node tree.

In some embodiments, the apparatus 2400 further includes:

the operation state feedback module is used for receiving an acquisition request of the interface operation state through the telemetric component;

responding to the acquisition request, and returning the interface running state; the interface operating state comprises at least one of: an interface list; interface configuration information; and the interface transmits and receives the packet statistical data.

In some embodiments, the interface comprises at least one interface queue; the interface queue is used for storing network data packets; each interface object corresponds to at least one route routine; the route routine is used for acquiring and processing the network data packet from the interface queue;

the apparatus 2400 further includes a routines management module;

the routine management module is used for responding to a registration request of a target routine of any interface, and replacing the routine of any interface with the target routine under the condition that the target routine is not a default routine;

in response to receiving the uninstall request of the target routine, replacing the target routine with a default routine in the case that the target routine is not the default routine.

According to the scheme described in the embodiment, after the preset operation is monitored, the interface affected by the preset operation can be managed, and the interface configuration file can be updated after the management is completed, so that on one hand, the dynamic update of the interface configuration can be realized, and compared with the related technology, the project operation does not need to be stopped, and the management flexibility of the interface is improved.

In addition, the feedback of the interface running state can be completed, the operation and maintenance of the DPDK project are facilitated, the routine of the routine is registered or uninstalled, and the decoupling of the routine and the interface management is realized.

As will be appreciated by one of skill in the art, one or more embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

In this application "and/or" means having at least one of the two. The embodiments in the present application are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the data processing apparatus embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and for the relevant points, reference may be made to part of the description of the method embodiment.

Although this application contains many specific implementation details, these should not be construed as limiting the scope of any disclosure or of what may be claimed, but rather as merely describing features of particular disclosed embodiments. Certain features that are described in this application in the context of separate embodiments can also be implemented in combination in a single embodiment. In other instances, features described in connection with one embodiment may be implemented as discrete components or in any suitable subcombination. Moreover, although features may be described as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the described embodiments is not to be understood as requiring such separation in all embodiments, and it is to be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

The above description is only for the purpose of illustrating the preferred embodiments of the present application and is not intended to limit the present application to the particular embodiments of the present application, and any modifications, equivalents, improvements, etc. made within the spirit and principles of the present application should be included within the scope of the present application.

Claims

1. An interface management method based on DPDK is characterized in that the interface provides the processing function for network data packets; the configuration information of the interface is stored in a configuration file; the interface comprises at least one interface queue; the interface queue is used for storing network data packets; each interface object corresponds to at least one route routine; the route routine is used for acquiring and processing the network data packet from the interface queue;

the method comprises the following steps:

monitoring a preset operation;

responding to the monitoring of the preset operation, and managing an interface influenced by the preset operation;

in response to completing the managing, updating the configuration file based on the latest configuration information of the interface;

the method for managing the route routine comprises the following steps:

in response to receiving a registration request for a target routine of any interface, replacing the routine of any interface with the target routine under the condition that the target routine is not a default routine;

2. The DPDK-based interface management method of claim 1, wherein the configuration file is a yaml file, and/or the configuration file stores configuration information of at least one of the interfaces in a tree structure.

3. The DPDK-based interface management method according to claim 1 or 2, wherein the managing the interface affected by the preset operation in response to monitoring the preset operation includes:

4. The DPDK-based interface management method of claim 3, wherein the predetermined operation is a modify operation for the configuration file;

the generating of the operation event corresponding to the preset operation in response to the monitoring of the preset operation comprises:

the managing, based on the event processing logic included in the operation event, the interface affected by the preset operation includes:

5. The DPDK-based interface management method according to claim 3, wherein the predetermined operation is a plug-in or plug-out operation for a network card; the network card corresponds to a plurality of interfaces;

generating an adding event aiming at the plurality of interfaces in response to monitoring the inserting operation aiming at the network card;

6. The DPDK-based interface management method of claim 3, wherein the predetermined operation is a state change operation for a target interface;

7. The DPDK-based interface management method of claim 1, wherein the configuration file is a yaml file, and the yaml file stores configuration information of at least one of the interfaces in a tree structure;

said updating said configuration file based on the latest configuration information of said interface in response to completion of said managing, comprising:

in response to completion of the management, creating a yaml node tree;

updating the configuration file based on the yaml node tree.

8. The DPDK-based interface management method of claim 1, wherein the method further includes:

receiving an acquisition request of an interface running state through a telemetering component;

9. A DPDK-based interface management system, the system comprising an event generation component, an event processing component, an interface options component, a telemetry component, and an external interface component;

the event generating component is used for monitoring a preset operation and generating an operation event corresponding to the preset operation in response to the monitoring of the preset operation;

the event processing component is used for calling a function in the interface option component based on an event processing logic included in the operation event, managing the interface influenced by the preset operation, responding to the completion of the management, and updating a configuration file based on the latest configuration information of the interface; the interface comprises at least one interface queue; the interface queue is used for storing network data packets; each interface object corresponds to at least one route routine; the route routine is used for acquiring and processing the network data packet from the interface queue;

the telemetering assembly is used for responding to an interface running state obtaining request and returning to the interface running state;

the external interface component is used for responding to a management request of the routine and finishing the management of the routine; the method for managing the route routine comprises the following steps:

in response to receiving an offload request for the target routine, replacing the target routine with a default routine in the event that the target routine is not the default routine.