As someone who has worked in the Telco/NFV industry for well over 10 years now, I can confidently say this is a breath of fresh air. Don’t get me wrong, DPDK-based tools are great, but setting up Cisco TRex or even basic TestPMD requires a lot of specialized knowledge. Indeed, in the era of LLMs, the barrier to entry is much lower, but hardware requirements remain regardless of whether an AI agent handles the implementation for you.
For anybody looking for XDP-supported drivers/NICs -> https://github.com/iovisor/bcc/blob/master/docs/kernel-versi...
In Wireblast a 100 Gbps packet generator in Go using AF_XDPiovisor
bcc
C2016–2026
iovisor / bcc
bcc
BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
64Distinct people
78Mentions
0Explicit recommenders
22.7KGitHub stars
What to know before exploring
What it is
BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
GitHub
Where it is used
The last source check was inconclusive. This does not establish whether a product uses it.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bpftrace/bpftrace · linked in 5 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year78 dated mentions
Observed mentions: 2016-02-03 15:03:57 UTC to 2026-08-10 08:04:42 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 16 | 6 | 10 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 13 | 4 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
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.
Screenshot
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.
^C
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.
Installing
See INSTALL.md for installation steps on your platform.
FAQ
See FAQ.txt for the most common troubleshoot questions.
Reference guide
See docs/reference_guide.md for the reference guide to the bcc and bcc/BPF APIs.
Contents
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.
Tracing
Examples
examples/tracing/bitehist.py: Block I/O size histogram. Examples.
examples/tracing/disksnoop.py: Trace block device I/O latency. Examples.
examples/hello_world.py: Prints "Hello, World!" for new processes.
examples/tracing/mysqld_query.py: Trace MySQL server queries using USDT probes. Examples.
examples/tracing/nodejs_http_server.py: Trace Node.js HTTP server requests using USDT probes. Examples.
examples/tracing/stacksnoop: Trace a kernel function and print all kernel stack traces. Examples.
tools/statsnoop: Trace stat() syscalls. Examples.
examples/tracing/task_switch.py: Count task switches with from and to PIDs.
examples/tracing/tcpv4connect.py: Trace TCP IPv4 active connections. Examples.
examples/tracing/trace_fields.py: Simple example of printing fields from traced events.
examples/tracing/undump.py: Dump UNIX socket packets. Examples
examples/tracing/urandomread.py: A kernel tracepoint example, which traces random:urandom_read. Examples.
examples/tracing/vfsreadlat.py examples/tracing/vfsreadlat.c: VFS read latency distribution. Examples.
examples/tracing/kvm_hypercall.py: Conditional static kernel tracepoints for KVM entry, exit and hypercall Examples.
Tools
tools/argdist: Display function parameter values as a histogram or frequency count. Examples.
tools/bashreadline: Print entered bash commands system wide. Examples.
tools/bpflist: Display processes with active BPF programs and maps. Examples.
tools/capable: Trace security capability checks. Examples.
tools/compactsnoop: Trace compact zone events with PID and latency. Examples.
tools/criticalstat: Trace and report long atomic critical sections in the kernel. Examples
tools/deadlock: Detect potential deadlocks on a running process. Examples.
tools/drsnoop: Trace direct reclaim events with PID and latency. Examples.
tools/funccount: Count kernel function calls. Examples.
tools/inject: Targeted error injection with call chain and predicates Examples.
tools/klockstat: Traces kernel mutex lock events and display locks statistics. Examples.
tools/opensnoop: Trace open() syscalls. Examples.
tools/readahead: Show performance of read-ahead cache Examples.
tools/reset-trace: Reset the state of tracing. Maintenance tool only. Examples.
tools/stackcount: Count kernel function calls and their stack traces. Examples.
tools/syncsnoop: Trace sync() syscall. Examples.
tools/threadsnoop: List new thread creation. Examples.
tools/tplist: Display kernel tracepoints or USDT probes and their formats. Examples.
tools/trace: Trace arbitrary functions, with filters. Examples.
tools/ttysnoop: Watch live output from a tty or pts device. Examples.
tools/ucalls: Summarize method calls or Linux syscalls in high-level languages. Examples.
tools/uflow: Print a method flow graph in high-level languages. Examples.
tools/ugc: Trace garbage collection events in high-level languages. Examples.
tools/uobjnew: Summarize object allocation events by object type and number of bytes allocated. Examples.
tools/ustat: Collect events such as GCs, thread creations, object allocations, exceptions and more in high-level languages. Examples.
tools/uthreads: Trace thread creation events in Java and raw pthreads. Examples.
Memory and Process Tools
tools/execsnoop: Trace new processes via exec() syscalls. Examples.
tools/exitsnoop: Trace process termination (exit and fatal signals). Examples.
tools/killsnoop: Trace signals issued by the kill() syscall. Examples.
tools/kvmexit: Display the exit_reason and its statistics of each vm exit. Examples.
tools/
Read the full README on GitHubWhat Hacker News says
78 sourcesI believe this is a case of convergent invention – the idea of pushing DWARF/.eh_frame unwinding into eBPF seems to have occurred to several people around the same time. For example, there's a working implementation discussed as early as March 2021: https://github.com/iovisor/bcc/issues/1234#issuecomment-7875...
In OpenTelemetry profiles enters public alphaXDP, and the eBPF ecosystem in general, is quite neat. However, a word of caution:
* The BPF verifier's DX is not great yet. If it finds problems with your BPF code it will spit our a rather inscrutable set of error messages that often requires a good understanding of the verifier internals (e.g the register nomenclature) to debug
* For the same source code, the code generated by the verifier can change across compiler versions in a breaking way, e.g. because the new compiler version implemented an optimization that broke the verifier (see https://github.com/iovisor/bcc/issues/4612)
* Checksum updating requires extra care. I believe you can only do incremental updates, not just because of better perf as the post suggests but also because the verifier does not allow BPF programs to operate on unbounded buffers (so checksumming a whole pack
Read the rest
et of unknown size is tricky / cumbersome). This mostly works but you have to be careful with packets that were generated with csum offload, don't have a valid checksum and whose csum can't be incrementally updated.
As the blog post points out, the kernel networking stack does a lot of work that we don't generally think about. Once you start taking things into your own hands you don't have the luxury of ignorance anymore (think not just ARP but also MTU, routing, RP filtering etc.), something any user of userspace networking frameworks like DPDK will tell you.
My general recommendation is to stick with the kernel unless you have a very good justification for chasing better performance and if you do use eBPF save yourself some trouble and try to limit yourself to readonly operations, if your use case allows.
Also, if you are trying to debug packet drops, newer kernels have started logging this information that you can track using bpftrace which gives you better diagnostics.
Example script (might have to adjust based on kernel version):
bpftrace -e '
kprobe:kfree_skb_reason {
$skb = (struct sk_buff *)arg0;
$ipheader = ((struct iphdr *) ($skb->head + $skb->network_header));
printf("reason :%d %s -> %s\n", arg1, ntop($ipheader->saddr), ntop($ipheader->daddr));
}'
np. there's a diagram, "Linux bcc/BPF tracing tools" [-1] in the bcc readme [0] that's also in [1] which explains ebpf and bcc and bpftrace.
filetop, dirtop, and vfsstat use bpf to trace the VFS layer. [4]
[-1] "Linux bcc/BPF tracing tools" https://www.brendangregg.com/BPF/bcc_tracing_tools_early2019...
[0] iovisor/bcc:
https://github.com/iovisor/bcc
[1] "Linux Extended BPF (eBPF) Tracing Tools", Dtrace book: https://www.brendangregg.com/ebpf.html
If running an AI agent in a container --- with devcontainers and e.g. vscode,
Good container policy prevents granting a container the CAP_SYS_ADMIN capability; the least-privileges thing to do is to grant limited capabilities to the container like CAP_BPF and (CAP_PERFMON, CAP_NET_RAW, CAP_SYS_PTRACE) [,3].
[3] https://medium.com/@techdevguides/using-bpftrace-with-limite...
[4] bpfcc-tools manp
Read the rest
ages: https://manpages.debian.org/unstable/bpfcc-tools/index.html
though ripgrep wins, vscode fails at monitoring large workspaces due to inotify limits too; so some way to parse fs events from bcc and libdtrace with python would be great
prompt 1: Create a python project named idk dbpftrace with a pyproject.toml and a README and sphinx /docs, with bcc and python-dtrace as dependencies to, then in dbpftrace/,
parse pid and descendents' fs syscall events from bcc (ebpf) or python-dtrace (dtrace), depending on which os we're running
Edit:
Prompt 1B: Create a Go package named dbpftrace with a README and docs,
parse pid and descendents' fs syscall events from bpftrace or dtrace stdout, depending on which os we're running
that's really cool. to gain traction i would start with reimplementing all the tools from https://github.com/iovisor/bcc/tree/master/libbpf-tools in PythonBPF.
In PythonBPF – Writing eBPF Programs in Pure PythonIt is quite simple to use eBPF with uprobes to hook library calls, for example: https://github.com/iovisor/bcc/blob/master/tools/sslsniff.py
The downside is this doesn't work with anything not using OpenSSL, there are projects like https://github.com/gojue/ecapture which have interceptors for many common libraries, but the downside is that needs different code for each library.
I think providing a TLS certificate is fine for the use cases of the tool; most tools won't be doing certificate pinning, but ecapture does support Android where this is more likely.
In Httptap: View HTTP/HTTPS requests made by any Linux programeBPF has entered the chat: https://github.com/iovisor/bcc
https://www.youtube.com/watch?v=Wb_vD3XZYOA
In Intentrace: Strace for EveryoneBcc: Powerful BPF-Based Linux IO Analysis and Monitoring Tools
1 points · Open discussionSimilar tools already available in many distros:
https://github.com/bpftrace/bpftrace/blob/master/tools/sslsn...
https://github.com/iovisor/bcc/blob/master/tools/sslsniff.py
https://embracethered.com/blog/posts/2021/offensive-bpf-snif...
On Ubuntu for example I can just "sudo apt install bpfcc-tools", then run "sudo sslsniff-bpfcc" and see curl TLS traffic right away.
In Capturing Linux SSL/TLS plaintext without a CA certificate using eBPFYeah, I already see limitations, the last one was yesterday when I installed earlier Ubuntu versions to see how far back this can go - and even Ubuntu 22.04 didn't work out of the box, ended up with some BCC/kernel header mismatch issue [1] although the kernel itself supported it. A workaround was to download & compile the latest BCC yourself, but I don't want to go there as the customers/systems I work on wouldn't go there anyway.
But libbpf with CO-RE will solve these issues as I understand, so as long as the kernel supports what you need, the CO-RE binary will work.
This raises another issue for me though, it's not easy, but easier, for enterprises to download and run a single python + single C source file (with <500 code lines to review) than a compiled CO-RE binary, but my long term plan/hope is that I (we) get the RedHats and AWSes
Read the rest
of this world to just provide the eventual mature release as a standard package.
[1] https://github.com/iovisor/bcc/issues/3993
There's a bunch of examples over at https://github.com/iovisor/bcc
In Show HN: Xcapture-BPF – like Linux top, but with Xray visionNice - I normally use [bash-readline](https://github.com/iovisor/bcc/blob/master/tools/bashreadlin...) when coworking/co-inhabiting a server or training someone.
In Linux: Easy Keylogger with eBPF (2018)One of the big wins is not so much “build and run your own stuff” but there are very nice low-cost (in terms of compute) performance utilities built on eBPF
https://github.com/iovisor/bcc
There are so many utilities in that list; there’s a diagram midway down the readme which tries to help show their uses. bcc-tools should be available in any distro.
Also, Brendan Gregg does a ton of performance stuff that is worth knowing about if you check out his other work. Not eBPF only. Flame graphs are useful.
In eBPF DocumentaryUsing eBPF based tools (like bcc) to debug the issues
https://github.com/iovisor/bcc
In Bpftop: Streamlining eBPF performance optimizationFor execsnoop, people running systems with DTrace can find the same:
* https://github.com/jorgev/dtrace-scripts/blob/master/execsno...
On macOS Monterey+ you'll probably have to install the Kernel Debug Kit per:
* https://developer.apple.com/forums/thread/692444
The Linux variant was written Brendan Gregg (who previous did a lot of work on Solaris, where DTrace was created):
* https://github.com/brendangregg/perf-tools/blob/master/execs...
* https://github.com/iovisor/bcc/blob/master/tools/execsnoop.p...
In Hidden gems of moreutilsShowing the 15 most recent of 78 sources. Enable JavaScript to search and browse every indexed mention.