Controls

Functions of a Control Block

• Connecting the parser to the forwarding logic

  Initiates packet processing upon completion of packet header parsing. It utilizes extracted header field information to perform table lookup, which determines the specific action to be executed on the packet.

• Table lookup

  Defines the match table and application logic. Table lookup is performed by matching lookup keys against packet header fields.

• Action execution

  Executes the action based on the lookup result. A table miss triggers the miss action.

Basic Syntax of a Control Block

control <control_name> (param1, param2, ...) {
    @<pre/main/post>
    table <table_name> {
        key = {
            <field_name>: <match_type>;
            ...
        }
        actions = {
            <action_name0>;
            <action_name1>;
            ...
        }
        default_action = <default_action>
        size = <val>
        timer_en = <true/false>
        aging_time = <val>        
    }
    apply {
        //apply_result res = xxx.apply();
        if(<table_name>.apply().hit){
          ...
        }
    }
}

Table

The table in a control block is used to define the flow table structure and describe a match-action collection.

• The @pre, @main, or @post annotation must be marked before the table to indicate the table type. For details about the specifications and constraints of different table types, see OVS Specifications.
• The @rss_fastpath annotation can be marked before the table to enable the Receive-Side Scaling (RSS) fast path.

The key list specifies the construction rule and matching mechanism for match fields. This version supports exact and ternary matching. Ternary matching is also known as fuzzy match. During the matching, AND operations are applied to the packet fields and a mask; the results are used for flow table lookup. You can construct a key using basic, header, and header_union types. If you construct a key using headers (with the @dpdk annotation) provided in hydra_builtin.hdr, standard DPDK enumerations are utilized. Table 1 lists the DPDK enumerations supported by the architecture file.

• This version does not support the use of expressions for key construction; for example, "a + b : exact" is not supported.
• The isValid() method of headers cannot be used to construct keys.
• Enumeration types cannot be used to construct keys.
• The number of custom keys cannot exceed 64.
• When utilizing the header_union type for key construction, the protocols corresponding to the header members cannot co-exist (e.g., a packet may contain either IPv4 or IPv6, not both).
• Key construction supports IPv4/IPv6 multiplexing at L3 and TCP/UDP/ICMP/ICMPv6 multiplexing at L4. The following default header_union structures are provided:

  header_union ip_union {
      rte_ipv4_hdr_t dpdk_ipv4;
      rte_ipv6_hdr_t dpdk_ipv6;
  }
  
  header_union port_icmp_union {
      rte_tcp_hdr_t dpdk_tcp;
      rte_udp_hdr_t dpdk_udp;
      rte_icmp_hdr_t dpdk_icmp;
      rte_icmp6_hdr_t dpdk_icmp6;
  }
  
  header_union port_union {
      rte_tcp_hdr_t dpdk_tcp;
      rte_udp_hdr_t dpdk_udp;
  }
  
  header_union icmp_union {
      rte_icmp_hdr_t dpdk_icmp;
      rte_icmp6_hdr_t dpdk_icmp6;
  }

• When utilizing the header_union type for key construction, setValid() must be explicitly called in the apply block to mark the protocol type that takes effect in header_union. The following uses ip_union as an example:

  control Pipe(in headers hdr){
        ip_union l3_union;
        table t{
              ...      
              key = {
                    l3_union : exact;
                    ...
              }
              ...
        }
        apply{
              if (hdr.l3.ipv4.isValid()) {
                    l3_union.dpdk_ipv4.setValid();
                    l3_union.dpdk_ipv4.protocol = hdr.l3.ipv4.protocol;
                    l3_union.dpdk_ipv4.sip = hdr.l3.ipv4.sip;
                    l3_union.dpdk_ipv4.dip = hdr.l3.ipv4.dip;
              } else if (hdr.l3.ipv6.isValid()) {
                    l3_union.dpdk_ipv6.setValid();
                    l3_union.dpdk_ipv6.next_header = hdr.l3.ipv6.next_header;
                    l3_union.dpdk_ipv6.sip = hdr.l3.ipv6.sip;
                    l3_union.dpdk_ipv6.dip = hdr.l3.ipv6.dip;
              }
              ...
              t.apply();
        }
  }

size = 0x1000000; // legal
size = 16 * 1024 * 1024; // illegal

• The programming framework supports the use of aging_time to customize hardware flow table aging intervals. The DPAK's original aging configuration item flow_max_idle is no longer effective under this framework.
• For data beyond the committed constraints, the compiler automatically truncates the data during compilation, which may lead to unexpected errors.

apply

The apply method serves as the entry point for a control. In the apply block, you can invoke the apply method of a table to perform key construction and lookup operations. This method returns a structure containing {bool hit; bool miss; bool error;}. This structure type is declared in the architecture file.

The following MyPrePipe control defines a main table named fullnat_exact. It utilizes standard DPDK enumerations for IPv4 and IPv6, along with custom src_port and dst_port fields as the key. The number of flow entries is 2M. In the apply method, variables are populated based on the packet parsing results. If the IPv4 header is valid and the time to live (TTL) is greater than 1, the system initiates a match against the fullnat_exact table. Upon a table hit, the actions defined in the action list are executed; if a table miss occurs, the default action (flexda_upcall) is performed. Example: