PROPUESTA DE LA INVESTIGACIÓN

Identification of configuration instruction. Given their configuration agnos-

tic implementation, most of the software data plane functions need to retrieve configuration variables at runtime from specific Match-Action-Tables (MAT) or configuration files, which can be dynamically changed by the control plane without having to restart the data plane with the new configuration. In most of the NF frameworks, this is done through the use of fixed APIs that allow both the control plane to configure those variables and the data plane to retrieve the runtime con- figuration. Configuration variables have the characteristic of (i) being generated by a single read from a configuration file or a MAT and (ii) never being modified during the execution of the data plane.

During the analysis phase, a Kecleon analysis pass operates as described in Algorithm 3. It scans the entire set of instructions available in the IR code and retrieves the corresponding signature, which should be identified by the back-end plugin as a configuration instruction. If the answer is positive, the method and

7 – Kecleon: A Dynamic Compiler and Optimizer for Software Network Data Planes

Algorithm 3: Identification of configuration instructions

Input: IRM (Module), IR of the original program Input: P (Plugin), Reference to target Kecleon plugin Function AnalysisConfigPass:

1 foreach IRinstr in IRM do

2 is_conf ig ← P.IsConfigInstr(IRinstr)

3 if is_config is True and IsReadOnly(IRinstr) then 4 IRM.MarkConfig(IRinstr)

Algorithm 4: Identification of state instructions

Input: IRM (Module), IR of the original program Input: P (Plugin), Reference to target Kecleon plugin Function AnalysisStatePass:

1 foreach IRinstr in IRM do

2 is_table ← P.IsTableFunction(IRinstr)

3 if is_table is True then

4 tid ← P.GetTableID(IRinstr)

5 IRM.MarkTable(IRinstr)

6 IRM.StoreTID(tid)

the associated variable are marked, and their use is tracked along with the execu- tion of the program. The marking procedure works by constructing specific debug metadata for the IR instruction, following the DWARF terminology1_{, which can}

be retrieved by the other passes. Kecleon adds to the IR instruction a debug infor- mation indicating the configuration nature of the function and associates a unique

metadata identifier that references an entry into an internal Kecleon data structure.

This entry contains additional details of the method itself (e.g., if the configuration variable is stored into a MAT or not, the maximum number of possible values). The subsequent passes can then use that information to perform the optimizations.

Identification of MAT instructions. As for the configuration variables, Ke-

cleon has to discover the instructions accessing to stateful information, which can then be retrieved and used by the subsequent optimization passes. Algorithm 4

shows the behavior of this analysis pass; it scans the entire set of instructions to find the function associated with an operation into a MAT. When found, it “marks”

1_{The Debugging With Attributed Record Formats (DWARF) is a widely recognized and stan-}

7 – Kecleon: A Dynamic Compiler and Optimizer for Software Network Data Planes

that method (e.g., the lookup function used to read the table content) and extracts

(i) a unique table ID (TID) used to retrieve the table content at runtime, (ii) the

layout associated with the table itself, which contains the type of data structure used (e.g., array, hash, lpm) and (optionally) (iii) a cost function used by Kecleon to understand the cost of performing the data structure change.

7.4.1.1 Implementation Details (eBPF Plugin)

We will now take an example the Kecleon eBPF Plugin, and we will apply the operations to a small code snippet (Listing 7.1) of the Katran load balancer [76], whose data plane is written in eBPF.

1 v i p . p o r t = p c k t . f l o w . p o r t 1 6 [ 1 ] ; 2 v i p . p r o t o = p c k t . f l o w . p r o t o ; 3 v i p _ i n f = bpf_map_lookup_ele(&vip_map ,& v i p ) ; 4 i f ( ! v i p _ i n f ) { 5 v i p . p o r t = 0 ; 6 v i p _ i n f = bpf_map_lookup_ele(&vip_map ,& v i p ) ; 7 i f ( ! v i p _ i n f ) { 8 return XDP_PASS; 9 } 10 } 11 . . .

Listing 7.1: Sample eBPF code from Katran NF

In an eBPF data path, the only way to set configuration values is to use specific eBPF maps, which are filled by the control plane when the program starts and retrieved at runtime from the data plane. On line 3 it performs a lookup into an eBPF map containing the list virtual IPs associated to a particular flow. The role of the Kecleon analysis pass is to discover that method and the associated eBPF map so that the subsequent passes can use the runtime values to optimize the new code. Once executed, Kecleon generates the IR code of the original eBPF program, shown in Listing 7.2, which is then given as input to the different analysis passes. Following the previously-mentioned procedure, the Kecleon analysis pass will rec- ognize the signatures at line 5 and 12 as an operation to a MAT (in this case, a map_lookup) and will proceed with the Algorithm 3 to check if the variable retrieved from the map is later modified in the data plane.

1 %226 = gep %vip , %vip* %22, i 6 4 0 , i 3 2 1

2 s t o r e i 1 6 %220, i 1 6 * %226, a l i g n 4

3 %227 = gep %vip , %vip* %22, i 6 4 0 , i 3 2 2

4 s t o r e i 8 %167, i 8 * %227, a l i g n 2 5 %228 = c a l l i 8 * i n t t o p t r ( i 6 4 1 to i 8 * ( i 8 ∗ , i 8 * ) * ) ( i 8 * b i t c a s t ( @vip_map to i 8 * ) , i 8 * n o n n u l l %46) #3 6 %229 = b i t c a s t i 8 * %228 to %vip_meta* 7 %230 = icmp eq i 8 * %228, n u l l 8 br i 1 %230, l a b e l %231, l a b e l %241

7 – Kecleon: A Dynamic Compiler and Optimizer for Software Network Data Planes 9 10 ; <l a b e l >:231: 11 s t o r e i 1 6 0 , i 1 6 * %226, a l i g n 4 12 %232 = c a l l i 8 ∗ i n t t o p t r ( i 6 4 1 to i 8 * ( i 8 * , i 8 * ) * ) ( i 8 * b i t c a s t ( @vip_map to i 8 * ) , i 8 * n o n n u l l %46) #3 13 %233 = b i t c a s t i 8 * %232 to %vip_meta* 14 %234 = icmp eq i 8 * %232, n u l l 15 br i 1 %234, l a b e l %688, l a b e l %235

Listing 7.2: LLVM IR code of the Listing 7.1

We use the LLVM memory dependency analysis (i.e., MemorySSA) to reason about the interactions between various memory operations, hence detecting if the variable has been modified or not2_{. Finally, if the result of the previous analysis}

detects that the map and the variables are read-only, the Kecleon analysis pass will mark the instruction. It will allocate an internal Kecleon data structure holding the information related to that variable, such as the maximum size of the map, the layout (eBPF HASH), or the unique map identifier, which are extracted by the eBPF plugin.