Architecture Models

Development

Figure 1 OVS control panel development model

• Hook functions: Functions defined in hook.h, which need to be developed and implemented using C language.

  For details about the functions and invoking requirements, see "Hook Functions" in the BeiMing 26.0.RC1 FlexDA Programming Framework API Reference.

• libapi: flexda_custom_api_t structure in libapi.h, which provides interfaces for the programming framework to invoke.
  • For details, see "Hardware Flow Table Editing Interfaces", "Packet Header Extraction Interfaces", and "Memory Management Interfaces" in the BeiMing 26.0.RC1 FlexDA Programming Framework API Reference.
  • The input parameter flexda_custom_api_t api of the initialization hook function (flexda_custom_init) stores the addresses of all interfaces provided by the programming framework for invocation. After saving this parameter as a global variable, these interfaces can be invoked within the implementation code of other hook functions.
  • libapi.h also defines static inline functions that facilitate the invocation of libapi interfaces. These functions can be utilized provided that a global variable of flexda_custom_api_t g_api has been defined and correctly populated with the interface addresses provided by the programming framework.

Initialization

Figure 2 OVS control plane initialization process

Figure 3 OVS control plane deinitialization process

During the OVS startup process, the system attempts to link the custom_openvswitch_plugin.so dynamic library in the /usr/lib64/ directory.

• If the linking is successful, the user-implemented hook functions are mounted into the initialization, deinitialization, and flow entry issuing procedures. Otherwise, the system executes the default issuing logic.
• Then, the system invokes flexda_custom_init, passing libapi (provided for user invocation) as an input parameter to execute user-defined global initialization.

Flow Entry Issuance

Figure 4 OVS control plane flow entry issuing process

When a packet hits an OVS flow table and triggers flow entry issuance, the process enters the OVS control plane to implement the following functions:

• Flow entry normalization: Multiple software flow entries hit by the same packet (table jumping scenario) are merged into a single hardware flow entry.

  This is implemented by the programming framework, which saves data—such as the input port information from the initial issuance triggered by the packet and the actions from each issuance—into a packet context indexed by this packet.

  If the packet hits a software flow table that contains an output port and no further jump actions, the framework concatenates the recorded software flow table actions and invokes the custom issuing logic.

  

  Currently, flow entry normalization does not support the following scenario: A single packet sequentially hits three or more software flow entries (jumping twice or more), and any flow entry other than the final two contains actions that modify the packet.

• Custom issuance: After the key (item), actions (action list), and attributes of a hardware flow entry are customized, the DPDK hardware flow entry issuing interfaces are invoked.

  This is implemented by the user OVS control plane code, which the programming framework invokes sequentially according to the process.

  Prior to issuing the hardware flow entry, its key, action list, and attributes are edited and assembled based on the custom packet context and other relevant packet information.

  

  • The initial state of the key is empty, with a maximum length of 15.
  • The initial state of the action list consists of concatenated software flow table actions, with a maximum length of 13.
  • Initial configurations of the attributes are as follows: The group field is 1, and all other fields are 0.