Difference between revisions of "VPP/Command-line Arguments"

Revision as of 20:22, 17 November 2018

Introduction

The VPP network stack comes with several configuration options that can be provided and applications built on the VPP stack have been known to require a dozen arguments, depending on requirements. This page describes commonly used configuration options. Please help maintain and improve this document!

The configuration options can be provided to VPP either as command-line arguments or in a configuration file.

Command-line arguments

Parameters are grouped by a section name. When providing more than one parameter to a section all parameters for that section must be wrapped in curly braces.

# /usr/bin/vpp unix { interactive cli-listen 127.0.0.1:5002 }
<startup diagnostic messages>
    _______    _        _   _____  ___ 
 __/ __/ _ \  (_)__    | | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /____(_)_/\___/   |___/_/  /_/    

vpp# <start-typing>

When providing only one such parameter the braces are optional. For example, the following command argument, unix interactive does not need braces:

# /usr/bin/vpp unix interactive

The command line can be presented as a single string or as several; anything given on the command line is concatenated with spaces into a single string before parsing.

VPP applications must be able to locate their own executable images. The simplest way to ensure this will work is to invoke a VPP application by giving its absolute path; for example: /usr/bin/vpp <options>. At startup, VPP applications parse through their own ELF-sections [primarily] to make lists of init, configuration, and exit handlers.

When developing with VPP, in gdb it's often sufficient to start an application like this:

# (gdb) run unix interactive

Configuration file

It is also possible to supply parameters in a startup configuration file the path of which is provided to the VPP application on its command line. The format of the configuration file is a simple text file with the same content as the command line but with the benefit of being able to use newlines to make the content easier to read.

The configuration file is commonly stored at /etc/vpp/startup.conf.

Here is an example of the configuration file:

unix {
  nodaemon
  /var/log/vpp/vpp.log
  full-coredump
  cli-listen localhost:5002
}

api-trace {
  on
}

dpdk {
  dev 0000:03:00.0
}

VPP is then instructed to load this file with the -c option:

# /usr/bin/vpp -c /etc/vpp/startup.conf

Note: In VPP 18.04, the default log file location was moved from "/tmp/vpp.log" to "/var/log/vpp/vpp.log". The VPP code is indifferent to the file location. However, if SELinux is enabled, then the new location is required for the file to be properly labelled. Check your local startup.conf file for the log file location on your system.

Configuration parameters

This is not an exhaustive list of parameters available. Readers who find information is missing or inaccurate are encouraged to add to this wiki page!

You can find argument parsers in the source code by searching for instances of the VLIB_CONFIG_FUNCTION or VLIB_EARLY_CONFIG_FUNCTION macros. Their invocation (foo_config, "foo") will cause the function foo_config to receive all parameters given in a parameter block named "foo", for example: "foo { arg1 arg2 arg3 ... }".

unix { ... }

tuntap { ... }

The "tuntap" driver configures a point-to-point interface between the vpp engine and the local Linux kernel stack. This allows e.g. users to ssh to the host / VM / container via vpp "revenue" interfaces. It's marginally useful, and is currently disabled by default. To [dynamically] create TAP interfaces - the preferred scheme - see the "tap_connect" binary API

Here's a typical multiple parameter invocation:

 tuntap { ethernet have-normal-interface name vpp1 }

api-trace { ... }

The ability to trace, dump, and replay control-plane API traces makes all the difference in the world when trying to understand what the control-plane has tried to ask the forwarding-plane to do.

Typically, one simply enables the API message trace scheme:

api-trace { on }

api-segment { ... }

These values control various aspects of the binary API interface to VPP.

cpu { ... }

Command-line CPU configuration controls the creation of named thread types, and the cpu affinity thereof. As of this writing, the cpu configuration function supports these parameters:

In some cases, it may be necessary to place thread instances manually:

Note that the "main" thread always occupies the lowest core-id specified in the DPDK [process-level] coremask.

Here's a full-bore manual placement example:

/cisco/bin/vpe  unix interactive tuntap disable cpu { main-thread-io coremask-workers 18 coremask-stats 4 } dpdk {coremask 1e}

# taskset -a -p <vpe-pid>
pid 16251's current affinity mask: 2   # main thread
pid 16288's current affinity mask: ffffff # DPDK interrupt thread (not bound to a core)
pid 16289's current affinity mask: 4 # stats thread
pid 16290's current affinity mask: 8 # worker thread 0
pid 16291's current affinity mask: 10 # worker thread 1

dpdk { ... }

Command line DPDK configuration controls a number of parameters, including device whitelisting, the number of CPUs available for launching dpdk-eal-controlled threads, the number of I/O buffers, and the process affinity mask.

In addition, the DPDK configuration function attempts to support all of the DPDK EAL configuration parameters.

Popular options include:

vdev eth_bond0,mode=2,slave=0000:0f:00.0,slave=0000:11:00.0,xmit_policy=l34
vdev eth_bond1,mode=2,slave=0000:10:00.0,slave=0000:12:00.0,xmit_policy=l34

All of the DPDK EAL options should be available. See .../open-repo/vnet/vnet/devices/dpdk/dpdk.h, look at the set of "foreach_eal_XXX" macros.

l2tp { ... }

ip6-l2tpv3 configuration controls the method used to locate a specific ip6-l2tpv3 tunnel. The following settings are mutually exclusive

Refer to .../open-repo/vnet/vnet/devices/dpdk/{dpdk.h, init.c} for more details.

oam { ... }

Oam configuration controls the (ip4-icmp) interval, and number of misses allowed before reporting an oam target down to any registered listener.

heapsize { ... }

Heapsize configuration controls the size of the main heap. The heap size is configured very early in the boot sequence, before loading plug-ins or doing much of anything else.

plugin_path { ... }

Plugin_path configuration controls the set of directories searched for vlib plugins. Supply a colon-separated list of (absolute) directory names:

cj { ... }

The cj thread-safe circular log buffer scheme is occasionally useful when chasing bugs. Calls to it should not be checked in. See .../vlib/vlib/unix/cj.c.

vhost-user { ... }

Vhost-user configuration parameters control the vhost-user driver.

l2learn { ... }

Configures the number of L2 (MAC) addresses in the L2 FIB at any one time. Defaults to 1M entries.

socksvr { ... }

Configure the socket server for the binary API. (See .../vlibmemory/socket_api.c)

statseg { ... }

Configure the shared memory stats segment. (See .../vpp/stats/stat_segment.c)