BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
C++ Python Lua C CMake Yacc Other
Latest commit b79b589 Jan 22, 2017 @4ast 4ast committed on GitHub Merge pull request #913 from iovisor/python23_percpu
Fix python2/3 incompatible percpu helpers
Failed to load latest commit information.
SPECS Eliminate rpmlint errors and allow bcc srpm to build on Fedora koji b… ( Nov 28, 2016
cmake cmake: Add dependency to LibELF Apr 20, 2016
debian Prepare debian changelog for v0.2.0 tag Sep 9, 2016
docs add print_linear_hist() for linear histograms Dec 14, 2016
examples Example of using USDT Dec 16, 2016
images update tools pic (#787) Oct 27, 2016
man [memleak] add parameter for specifying object to load malloc/free from Jan 20, 2017
scripts Add clang-format file, tweak style-check.sh Apr 19, 2016
snapcraft snapcraft.yaml: fix typo in ttysnoop wrapper Jan 5, 2017
src Support for hotplug cpu cases in percpu array sizing Jan 21, 2017
tests Skip percpu testing on unsupported kernels Jan 21, 2017
tools [memleak] add parameter for specifying object to load malloc/free from Jan 20, 2017
.clang-format Update .clang-format configs Nov 24, 2016
.dockerignore Add multiple build support styles Jul 7, 2015
.gitignore minor readme enhancements Feb 21, 2016
CMakeLists.txt Determine kernel dirs at runtime (fix #743) Nov 29, 2016
CONTRIBUTING-SCRIPTS.md add output notes to doc (#765) Oct 18, 2016
COPYRIGHT.txt Create COPYRIGHT.txt Jun 5, 2015
Dockerfile.debian Build debian packages in docker containers Jul 12, 2016
Dockerfile.ubuntu Add proper debian build support Aug 26, 2015
FAQ.txt Add proper debian build support Aug 26, 2015
INSTALL.md Add installation instructions for Gentoo (#785) Oct 25, 2016
LICENSE.txt Create LICENSE.txt Jun 5, 2015
QUICKSTART.md add Quick Start Guide for bcc docker Dec 1, 2016
README.md add cpuunclaimed Dec 21, 2016


BCC Logo

BPF Compiler Collection (BCC)

BCC is a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and examples. It makes use of extended BPF (Berkeley Packet Filters), formally known as eBPF, a new feature that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1 and above.

eBPF was described by Ingo Molnár as:

One of the more interesting features in this cycle is the ability to attach eBPF programs (user-defined, sandboxed bytecode executed by the kernel) to kprobes. This allows user-defined instrumentation on a live kernel image that can never crash, hang or interfere with the kernel negatively.

BCC makes BPF programs easier to write, with kernel instrumentation in C (and includes a C wrapper around LLVM), and front-ends in Python and lua. It is suited for many tasks, including performance analysis and network traffic control.


This example traces a disk I/O kernel function, and populates an in-kernel power-of-2 histogram of the I/O size. For efficiency, only the histogram summary is returned to user-level.

# ./bitehist.py 
Tracing... Hit Ctrl-C to end.
     kbytes          : count     distribution
       0 -> 1        : 3        |                                      |
       2 -> 3        : 0        |                                      |
       4 -> 7        : 211      |**********                            |
       8 -> 15       : 0        |                                      |
      16 -> 31       : 0        |                                      |
      32 -> 63       : 0        |                                      |
      64 -> 127      : 1        |                                      |
     128 -> 255      : 800      |**************************************|

The above output shows a bimodal distribution, where the largest mode of 800 I/O was between 128 and 255 Kbytes in size.

See the source: bitehist.py. What this traces, what this stores, and how the data is presented, can be entirely customized. This shows only some of many possible capabilities.


See INSTALL.md for installation steps on your platform.


See FAQ.txt for the most common troubleshoot questions.


Some of these are single files that contain both C and Python, others have a pair of .c and .py files, and some are directories of files.







BPF guarantees that the programs loaded into the kernel cannot crash, and cannot run forever, but yet BPF is general purpose enough to perform many arbitrary types of computation. Currently, it is possible to write a program in C that will compile into a valid BPF program, yet it is vastly easier to write a C program that will compile into invalid BPF (C is like that). The user won't know until trying to run the program whether it was valid or not.

With a BPF-specific frontend, one should be able to write in a language and receive feedback from the compiler on the validity as it pertains to a BPF backend. This toolkit aims to provide a frontend that can only create valid BPF programs while still harnessing its full flexibility.

Furthermore, current integrations with BPF have a kludgy workflow, sometimes involving compiling directly in a linux kernel source tree. This toolchain aims to minimize the time that a developer spends getting BPF compiled, and instead focus on the applications that can be written and the problems that can be solved with BPF.

The features of this toolkit include:

  • End-to-end BPF workflow in a shared library
    • A modified C language for BPF backends
    • Integration with llvm-bpf backend for JIT
    • Dynamic (un)loading of JITed programs
    • Support for BPF kernel hooks: socket filters, tc classifiers, tc actions, and kprobes
  • Bindings for Python
  • Examples for socket filters, tc classifiers, and kprobes
  • Self-contained tools for tracing a running system

In the future, more bindings besides python will likely be supported. Feel free to add support for the language of your choice and send a pull request!



At Red Hat Summit 2015, BCC was presented as part of a session on BPF. A multi-host vxlan environment is simulated and a BPF program used to monitor one of the physical interfaces. The BPF program keeps statistics on the inner and outer IP addresses traversing the interface, and the userspace component turns those statistics into a graph showing the traffic distribution at multiple granularities. See the code here.



Already pumped up to commit some code? Here are some resources to join the discussions in the IOVisor community and see what you want to work on.