Rewrite of the behavioral model as a C++ project without auto-generated code (except for the PD interface)
Permalink
Failed to load latest commit information.
PI Fix linking for simple_switch_grpc Sep 23, 2018
docs Add checksum_error field and behavior to simple_switch docs (#660) Sep 22, 2018
hooks Add build hook for dockerhub May 30, 2018
include Add support for setting checksum error in Simple Switch Sep 21, 2018
m4 port to mac os x and g++-5 (#201) Sep 28, 2016
mininet Option in mininet switch to have bmv2 log to console (#286) Feb 10, 2017
pdfixed Comment out printfs for bmv2 notifications (#220) Oct 18, 2016
src Add support for setting checksum error in Simple Switch Sep 21, 2018
targets Do not compile l2_switch/learn_client if nanomsg missing Oct 16, 2018
tests Add 2 hash functors to the Bmv2 core library Aug 22, 2018
third_party add missing functional includes Oct 30, 2017
thrift_src Support "default-default" entry for tables with ability to reset Feb 9, 2018
tools p4dbg.py: don't use thrift if socket and json are specified (#668) Oct 9, 2018
travis Use docker image in travis tests (#437) Sep 8, 2017
.dockerignore Exclude some unnecessary files from the Docker image Apr 7, 2017
.gitignore Support for injecting / receiving pkts with gRPC Jul 6, 2017
.gitmodules got rid of infra Mar 16, 2015
.travis.yml Build simple_switch_grpc in Dockerfile Dec 7, 2017
CONTRIBUTING.md Remove Werror from CXXFLAGS Dec 28, 2017
CPPLINT.cfg added CPPLINT.cg files, cpplint.py and a script to invoke cpplint in … Dec 8, 2015
Dockerfile Add build hook for dockerhub May 30, 2018
Dockerfile.grpc Update requirement for grpc to 1.3.0 (#378) May 23, 2017
Dockerfile.noPI Add Dockerfile.noPI Dec 6, 2017
Doxyfile Allow switch to start without JSON configuration (#281) Feb 1, 2017
Doxymain.md added main page for the target-design doxygen documentation Jan 22, 2016
LICENSE Added licensing info Jun 4, 2015
Makefile.am Install simpleswitch_runner library Aug 9, 2018
README.md Fix p4-dev mailing list address in README Oct 19, 2018
VERSION changed VERSION number to 1.12.0 for release Jul 23, 2018
autogen.sh Add autogen.sh, configure.ac from tm_sim May 4, 2015
configure.ac Add option --load-modules to simple_switch (#605) May 29, 2018
install_deps.sh Fix for ubuntu18.04 (#657) Sep 18, 2018

README.md

BEHAVIORAL MODEL REPOSITORY

Build Status

This is the second version of the P4 software switch (aka behavioral model), nicknamed bmv2. It is meant to replace the original version, p4c-behavioral, in the long run, although we do not have feature equivalence yet. Unlike p4c-behavioral, this new version is static (i.e. we do not need to auto-generate new code and recompile every time a modification is done to the P4 program) and written in C++11. For information on why we decided to write a new version of the behavioral model, please look at the FAQ below.

Dependencies

On Ubuntu 14.04, the following packages are required:

  • automake
  • cmake
  • libjudy-dev
  • libgmp-dev
  • libpcap-dev
  • libboost-dev
  • libboost-test-dev
  • libboost-program-options-dev
  • libboost-system-dev
  • libboost-filesystem-dev
  • libboost-thread-dev
  • libevent-dev
  • libtool
  • flex
  • bison
  • pkg-config
  • g++
  • libssl-dev

You also need to install the following from source. Feel free to use the install scripts under travis/.

To use the CLI, you will need to install the nnpy Python package. Feel free to use travis/install-nnpy.sh

To make your life easier, we provide the install_deps.sh script, which will install all the dependencies needed on Ubuntu 14.04.

Our Travis regression tests now run on Ubuntu 14.04.

On MacOS you can use the tools/macos/bootstrap_mac.sh script to install all the above dependencies using homebrew. Note that in order to compile the code you need XCode 8 or later.

Building the code

1. ./autogen.sh
2. ./configure
3. make
4. [sudo] make install  # if you need to install bmv2

In addition, on Linux, you may have to run sudo ldconfig after installing bmv2, to refresh the shared library cache.

Debug logging is enabled by default. If you want to disable it for performance reasons, you can pass --disable-logging-macros to the configure script.

In 'debug mode', you probably want to disable compiler optimization and enable symbols in the binary:

./configure 'CXXFLAGS=-O0 -g'

The new bmv2 debugger can be enabled by passing --enable-debugger to configure.

Running the tests

To run the unit tests, simply do:

make check

If you get a nanomsg error when running the tests (make check), try running them as sudo

Running your P4 program

To run your own P4 programs in bmv2, you first need to transform the P4 code into a json representation which can be consumed by the software switch. This representation will tell bmv2 which tables to initialize, how to configure the parser, ... It is produced by the p4c-bm tool. Please take a look at the README for this repo to find out how to install it. Once this is done, you can obtain the json file as follows:

p4c-bm --json <path to JSON file> <path to P4 file>

The json file can now be 'fed' to bmv2. Assuming you are using the simple_switch target:

sudo ./simple_switch -i 0@<iface0> -i 1@<iface1> <path to JSON file>

In this example <iface0> and <iface1> are the interfaces which are bound to the switch (as ports 0 and 1).

Using the CLI to populate tables...

The CLI code can be found at tools/runtime_CLI.py. It can be used like this:

./runtime_CLI.py --thrift-port 9090

The CLI connect to the Thrift RPC server running in each switch process. 9090 is the default value but of course if you are running several devices on your machine, you will need to provide a different port for each. One CLI instance can only connect to one switch device.

The CLI is realized using the Python's cmd module and supports auto-completion. If you inspect the code, you will see that the list of supported commands. This list includes:

- table_set_default <table name> <action name> <action parameters>
- table_add <table name> <action name> <match fields> => <action parameters> [priority]
- table_delete <table name> <entry handle>

The CLI include commands to program the multicast engine. Because we provide 2 different engines (SimplePre and SimplePreLAG), you have to specify which one your target is using when starting the CLI, using the --pre option. Accepted values are: None, SimplePre (default value) and SimplePreLAG. The l2_switch target uses the SimplePre engine, while the simple_switch target uses the SimplePreLAG engine.

You can take a look at the commands.txt file for l2_switch and simple_router to see how the CLI can be used.

Using the debugger

To enable the debugger, make sure that you passed the --enable-debugger flag to configure. You will also need to use the --debugger command line flag when starting the switch.

Use tools/p4dbg.py as follows when the switch is running to attach the debugger to the switch:

sudo ./p4dbg.py [--thrift-port <port>]

Displaying the event logging messages

To enable event logging when starting your switch, use the --nanolog command line option. For example, to use the ipc address ipc:///tmp/bm-log.ipc:

sudo ./simple_switch -i 0@<iface0> -i 1@<iface1> --nanolog ipc:///tmp/bm-log.ipc <path to JSON file>

Use tools/nanomsg_client.py as follows when the switch is running:

sudo ./nanomsg_client.py [--thrift-port <port>]

The script will display events of significance (table hits / misses, parser transitions, ...) for each packet.

Integrating with Mininet

We will provide more information in a separate document. However you can test the Mininet integration right away using our simple_router target.

In a first terminal, type the following:

- cd mininet
- sudo python 1sw_demo.py --behavioral-exe ../targets/simple_router/simple_router --json ../targets/simple_router/simple_router.json

Then in a second terminal:

- cd targets/simple_router
- ./runtime_CLI < commands.txt

Now the switch is running and the tables have been populated. You can run pingall in Mininet or start a TCP flow with iperf between hosts h1 and h2.

When running a P4 program with simple_switch (instead of simple_router in the above example), just provide the appropriate simple_switch binary to 1sw_demo.py with --behavioral-exe.

FAQ

Why did we need bmv2 ?

  • The new C++ code is not auto-generated for each P4 program. This means that it becomes very easy and very fast to change your P4 program and test it again. The whole P4 development process becomes more efficient. Every time you change your P4 program, you simply need to produce the json for it using p4c-bm and feed it to the bmv2 executable.
  • Because the bmv2 code is not auto-generated, we hope it is easier to understand. We hope this will encourage the community to contribute even more to the P4 software switch.
  • Using the auto-generated PD library (which of course still needs to be recompiled for each P4 program) is now optional. We provide an intuitive CLI which can be used to program the runtime behavior of each switch device.
  • The new code is target independent. While the original p4c-behavioral assumed a fixed abstract switch model with 2 pipelines (ingress and egress), bmv2 makes no such assumption and can be used to represent many switch architectures. Three different -although similar- such architectures can be found in the targets/ directory. If you are a networking company interested in programming your device (parser, match-action pipeline, deparser) with P4, you can use bmv2 to reproduce the behavior of your device.

How do program my own target / switch architecture using bmv2 ?

You can take a look at the targets/ directory first. We have also started writing some doxygen documentation specifically targetted at programmers who want to implement their own switch model using the bmv2 building blocks. You can generate this documentation yourself (if you have doxygen installed) by running doxygen Doxyfile. The output can be found under the doxygen-out directory. You can also browse this documentation online.

What else is new in bmv2 ?

  • Arithmetic is now possible on arbitrarily wide fields (no more limited to <= 32-bit fields) and variable-length fields are now supported.
  • We finally have unit tests!
  • While it is still incomplete, we provide a convenient 'event-logger' built on top of nanomsg. Every time a 'significant' event happens (e.g. table hit, parser transition,...) a message is broadcast on a nanomsg channel and any client can consume it.

Are all features supported yet ?

At this time, we are aware of the following unsupported P4_14 features:

  • direct registers

If you find more missing features or if you would like to request that a specific feature be added, please send us an email (p4-dev@lists.p4.org) or submit an issue with the appropriate label on Github. Do not hesitate to contribute code yourself!

How do I signal a bug ?

Please submit an issue with the appropriate label on Github.

How can I contribute ?

See CONTRIBUTING.md.