Morpheus：软件数据平面的特定领域运行时优化_Shel.zip

# Experiments Under this folder you can find scripts to run some experiments performed in our ASPLOS '22 [paper](https://sebymiano.github.io/publication/2022-morpheus/2022-morpheus.pdf). Here you can find a list of all the experiments. Every folder contains an additional `README.md` with the instructions to run the single experiment. ## Table of Contents 1. [Testbed setup](#testbed-setup) 2. [List of experiments](#list-of-experiments) 1. [Throughput (Figure 4)](#1-baseline-vs-morpheus-throughput-figure-4) 2. [Perf (Figure 5)](#2-perf-measurement--figure-5) 3. [Latency (Figure 6)](#3-latency-experiments-figure-6) 4. [Naive vs Adaptive instrumentation (Figure 7)](#4-naive-vs-adaptive-instrumentation-experiments-figure-7) 5. [Instrumentation overhead (Figure 8)](#5-instrumentation-overhead-experiments-figure-8) 6. [Experiment with dynamic traffic (Figure 9a)](#6-experiment-with-dynamic-changing-traffic-figure-9a) ## Testbed setup Our testbed is composed of two servers. The first one works as packet generator and uses DPDK to send packets at maximum speed. Both servers are connected back-to-back as indicated in the underlying figure. We use a modified version of the [`dpdk-burst-replay`](https://github.com/sebymiano/dpdk-burst-replay/tree/morpheus) tool to replay large PCAP traces (e.g., CAIDA), and [`Moongen`](https://github.com/emmericp/MoonGen) for the latency experiments, since it is able to exploit the hardware timestamp of the NIC instead of the software one. <p align="center"> <img src="testbed-setup.svg" alt="Testbed" width="60%"> </p> <p align="center"> _{Testbed setup} </p> ### Hardware & Software requirements The testbed needed to run the experiments in this repo requires two servers with two *separate* Ethernet interfaces connected back-to-back, as shown in the Figure above. In particular: #### **Packet generator server** This server runs all the script to start the tests and collect the results from the DUT (via SSH, if configured). The requirements for this server are: - DPDK v20.11.3 (or newer) - At least 10G of *large* hugepages (1G each) required to send large PCAPs - Two *ethernet* interfaces connected back-to-back with the *DUT* and one additional interface to perform the connection (via SSH) with the DUT (in our paper we used one *Intel Intel XL710* 40Gbps dual port NIC). #### **DUT server** In this server, we run the tests. The script executed on the *packet generator* server automatically collects the results and manages the lifecycles of the test via a separate SSH connection with the DUT. The requirements for this server are: - At least kernel v5.10 (the paper's test have been performed on kernel v5.12) - Two *ethernet* interfaces connected back-to-back with the *Packet generator* and one additional interface to perform the connection (via SSH) with the *Packet generator* (in our paper we used one *Intel Intel XL710* 40Gbps dual port NIC). - Both interfaces should have the possibility to set hardware rules in the NIC to redirect packets to a single core. The [script](common/setup_flow_director_single_core.sh) that performs this operation prints a warning in case this is not supported, and continue the configuration. You can run the test anyway, but the results will be different from the one presented in the paper. You can check if your interface supports this operation with the following command: ```console # sudo ethtool -k <if> | grep "ntuple-filters: on" ``` If the command does not produce any output, the operation is not supported. - The driver used by the two interface should be compatible with *XDP Native* mode. You can check [here](https://github.com/xdp-project/xdp-project/blob/master/areas/drivers/README.org) the list of supported drivers. - The `bpf_jit_enable` flag enabled on the kernel (this should be enabled by default on recent kernel, e.g. v4.18+) ### Run experiments on Cloudlab To further simplify the reproducibility of our experiments, in case you do not have the required hardware available, we provide a [Cloudlab](https://www.cloudlab.us/) profile ready to use. The profile is available on this repository [here](../profile.py). Running the experiment on Cloudlab is very easy. Just follow these steps: 1. Login to [Cloudlab](https://www.cloudlab.us/login.php) using your username and password 2. Go to `Experiments` > `Start Experiment` on the left tab (or follow directly [this](https://www.cloudlab.us/instantiate.php) link). 3. Click on `Change Profile` button on the right side of the page, and select the `Morpheus-ASPLOS` profile); then click `Next`. 4. You can now choose a hardware node type. We already provide a default type (i.e., `c220g1`) but you can use another (we only tested it on `c220g1`). ***Note:*** Althought `c220g1` hardware nodes are *similar* to our paper's testbed, it is not the same; the absolute results may be different, but the **Morpheus** behavior should be evident. 5. After the experiment is instantiated, you just need to wait for the setup to complete; then you can click on the `List View` tab to read the `ssh` command to log into the servers. 7. Log into the `pktgen` machine, clone the Morpheus repository and run the `setup_pktgen.sh` script. 8. In the meantime, log into the `dut` machine, clone the Morpheus repository and run the `setup_dut.sh` script. 9. At this point, you are ready to start. Follow the instructions below to run our experiments. Enjoy *Morpheus*! ### Install dependencies Before starting, you need to prepare the testbed with all the required software. Log in into the server that work as packet generator and execute the following commands. <!--- We suggest to use the [*automatic*](#automatic-installation) installation script, but if you have problems you can go with the [*manual*](#manual-installation) installation: --> #### Automatic installation After installing all the dependencies and the software required for the packet generator, it will ask if you want to setup the `hugepages` and the PCI address of the NIC interfaces to be bound to the DPDK `vfio-pci` driver. If the script fails in this last step, make sure you have `intel_iommu=on` flag enabled on your *GRUB* settings; if not, you can add this *flag* under `GRUB_CMDLINE_LINUX_DEFAULT`; then run `sudo update-grub` and *reboot* your server. ```console $ git clone https://github.com/Morpheus-compiler/Morpheus.git # Not needed if you downloaded the archive from Zenodo $ ./setup_pktgen.sh ``` ### PCAP Trace Generation Most of the experiments in our paper have been performed using either [*CAIDA*](https://www.caida.org/catalog/datasets/passive_dataset_download/) traces and *synthetic* traces with different traffic locality, generated using [ClassBench](https://www.arl.wustl.edu/classbench/). To simplify the reproducibility of our experiments, we also provide such traces under the [GIT Release of this repo](https://github.com/Morpheus-compiler/Morpheus/releases/tag/v0.1). <!--- You have two options here. If you trust us, you can download our traces, otherwise we provide a script to generate them automatically (although this would take ~1 hour to generate all the traces.). --> #### Download our traces If you have executed the `setup_pktgen.sh` script correctly, the traces are already downloaded and ready to use. If, for some reason, the script did not download the traces correctly, you can run the following script: ```console $ ./download_pcaps.sh ``` <!--- #### Generate the traces To generate the traces, you can run the following script. - [ ] Create configuration file with MAC, etc... --> ### Configuration file Before running most of the scripts in this repo, you need to fill the [`config.sh`](./config.sh) file with all the information specific to your testbed. This script is sourced by all the other scripts and used to configure the machines correctly. **Note: you need to clone the Morpheus repo in both servers (i.e., *pktgen* and *DUT*) and modify the script in both of