|
Recommended LLVM version for bcc 0.7.0
Hi,
Is there a particular version of LLVM that is recommended to use with
bcc 0.7.0?
Thanks,
Tom
Hi,
Is there a particular version of LLVM that is recommended to use with
bcc 0.7.0?
Thanks,
Tom
|
By
Tom Stellard
·
#1529
·
|
|
reminder: IO Visor TSC/Dev Meeting
Please join us tomorrow for our bi-weekly call. As usual, this meeting is
open to everybody and completely optional.
You might be interested to join if:
You want to know what is going on in BPF
Please join us tomorrow for our bi-weekly call. As usual, this meeting is
open to everybody and completely optional.
You might be interested to join if:
You want to know what is going on in BPF
|
By
Brenden Blanco
·
#1528
·
|
|
Unexpectedly high latencies are showed by self-written script (bpf_ktime_get_ns issue?)
Hi, everyone!
I've written a small script using bcc python lib for qemu block io latency tracing.
I attach two uprobes to block_acct_start and block_acct_done.
On some servers i can see unexpectedly
Hi, everyone!
I've written a small script using bcc python lib for qemu block io latency tracing.
I attach two uprobes to block_acct_start and block_acct_done.
On some servers i can see unexpectedly
|
By
Aleksei Zakharov
·
#1527
·
|
|
Re: eBPF TC for adjusting the packet length
You may check helper bpf_skb_change_tail(), which could serve your purpose.
You may check helper bpf_skb_change_tail(), which could serve your purpose.
|
By
Yonghong Song
·
#1526
·
|
|
eBPF TC for adjusting the packet length
Hi,
Can anyone suggest a way to adjust the packet length(for example to strip off the payload and have only headers) using eBPF TC program?
Thanks,
Kanthi
Hi,
Can anyone suggest a way to adjust the packet length(for example to strip off the payload and have only headers) using eBPF TC program?
Thanks,
Kanthi
|
By
Kanthi P <Pavuluri.kanthi@...>
·
#1525
·
|
|
Re: [RFC 0/2] tools: Add shmsnoop/sofdsnoop tools
Tools look excellent, thanks! When you're ready, could you submit as a
github bcc PR? thanks,
Brendan
Tools look excellent, thanks! When you're ready, could you submit as a
github bcc PR? thanks,
Brendan
|
By
Brendan Gregg
·
#1524
·
|
|
Re: Plans for libbpf packaging for distros?
Jakub Kicinski <jakub.kicinski@...> wrote:
That is an interesting use case.
I myself is also guilty[1] of copying the libbpf code from the kernel
and placing it on github to make my
Jakub Kicinski <jakub.kicinski@...> wrote:
That is an interesting use case.
I myself is also guilty[1] of copying the libbpf code from the kernel
and placing it on github to make my
|
By
Jesper Dangaard Brouer
·
#1523
·
|
|
Re: [PATCH] BPF: helpers: New helper bpf_get_current_pidns_info to obtain namespace data from current task.
Hi,
I have modified this patch following suggestion on bpf-next, let me know if
this looks ok. I'm working on testing it on bpf-next current (4.20) but I'm
getting -EINVAL in bpf_load when
Hi,
I have modified this patch following suggestion on bpf-next, let me know if
this looks ok. I'm working on testing it on bpf-next current (4.20) but I'm
getting -EINVAL in bpf_load when
|
By
neirac
·
#1522
·
|
|
Re: Plans for libbpf packaging for distros?
I think we're all on the same page.
Just to reiterate few points:
The source of truth of libbpf is in the kernel tree.
github/libbpf is a mirror of kernel sources plus few headers that
neceesary for
I think we're all on the same page.
Just to reiterate few points:
The source of truth of libbpf is in the kernel tree.
github/libbpf is a mirror of kernel sources plus few headers that
neceesary for
|
By
Alexei Starovoitov
·
#1521
·
|
|
Re: Plans for libbpf packaging for distros?
To my understanding it's useful in two ways:
- some less fortunate distros (Debian) reportedly need a kernel build
to package bpftool, and for libbpf the same would have to happen.
At least
To my understanding it's useful in two ways:
- some less fortunate distros (Debian) reportedly need a kernel build
to package bpftool, and for libbpf the same would have to happen.
At least
|
By
Jakub Kicinski
·
#1520
·
|
|
Re: Plans for libbpf packaging for distros?
Arnaldo Carvalho de Melo <acme@...> wrote:
And you basically also ship a version of libbpf in this tarball:
$ tar tvf ~/download/perf-4.19.0.tar.xz | grep lib/bpf
drwxrwxr-x root/root
Arnaldo Carvalho de Melo <acme@...> wrote:
And you basically also ship a version of libbpf in this tarball:
$ tar tvf ~/download/perf-4.19.0.tar.xz | grep lib/bpf
drwxrwxr-x root/root
|
By
Jesper Dangaard Brouer
·
#1519
·
|
|
[RFC/PATCH 2/2] tools: Add sofdsnoop to spy on fds passed through socket
The sofdsnoop traces FDs passed through unix sockets.
# ./sofdsnoop
ACTION TID COMM SOCKET FD NAME
SEND 2576 Web Content 24:socket:[39763]
The sofdsnoop traces FDs passed through unix sockets.
# ./sofdsnoop
ACTION TID COMM SOCKET FD NAME
SEND 2576 Web Content 24:socket:[39763]
|
By
Jiri Olsa
·
#1518
·
|
|
[RFC/PATCH 1/2] tools: Add shmsnoop to spy on shm* syscalls
Adding shmsnoop tool to trace System V shared memory
syscalls: shmget, shmat, shmdt, shmctl
# ./shmsnoop.py
PID COMM SYS RET ARGs
19813 server SHMGET
Adding shmsnoop tool to trace System V shared memory
syscalls: shmget, shmat, shmdt, shmctl
# ./shmsnoop.py
PID COMM SYS RET ARGs
19813 server SHMGET
|
By
Jiri Olsa
·
#1517
·
|
|
[RFC 0/2] tools: Add shmsnoop/sofdsnoop tools
hi,
this is RFC patchset on 2 tools that our customer wants
and perhaps would like to see them upstream.
The sofdsnoop traces FDs passed through unix sockets:
# ./sofdsnoop
ACTION TID COMM
hi,
this is RFC patchset on 2 tools that our customer wants
and perhaps would like to see them upstream.
The sofdsnoop traces FDs passed through unix sockets:
# ./sofdsnoop
ACTION TID COMM
|
By
Jiri Olsa
·
#1516
·
|
|
Plans for libbpf packaging for distros?
Hi Jakub, Laura and Jiri Olsa (Cc others),
Subj: iovisor-dev] minutes: IO Visor TSC/Dev Meeting
(To: iovisor-dev <iovisor-dev@...>)
I noticed from the iovisor-dev minutes that you have
Hi Jakub, Laura and Jiri Olsa (Cc others),
Subj: iovisor-dev] minutes: IO Visor TSC/Dev Meeting
(To: iovisor-dev <iovisor-dev@...>)
I noticed from the iovisor-dev minutes that you have
|
By
Jesper Dangaard Brouer
·
#1515
·
|
|
minutes: IO Visor TSC/Dev Meeting
Hi All,
Thanks for joining in to the discussion today. Below are my notes from
the call. Hope everyone is looking forward to good discussions at the
LPC BPF track in Vancouver in two weeks! Since
Hi All,
Thanks for joining in to the discussion today. Below are my notes from
the call. Hope everyone is looking forward to good discussions at the
LPC BPF track in Vancouver in two weeks! Since
|
By
Brenden Blanco
·
#1514
·
|
|
Re: Loader complexity
Not Go in the Go runtime :)
Not Go in the Go runtime :)
|
By
Dan Siemon
·
#1513
·
|
|
Re: Loader complexity
please define 'unsafe'
By
Alexei Starovoitov
·
#1512
·
|
|
Re: Loader complexity
Correct. No BTF, I mostly had bpf calls going but didn't finish it
because we don't need it right now.
I understand the situation but this makes me a bit sad. I wrote the
loader originally to avoid
Correct. No BTF, I mostly had bpf calls going but didn't finish it
because we don't need it right now.
I understand the situation but this makes me a bit sad. I wrote the
loader originally to avoid
|
By
Dan Siemon
·
#1511
·
|
|
Re: Loader complexity
reasonably simple? ;)
I suspect it doesn't support bpf-to-bpf calls and BTF, right?
These were major additions that folks with custom loader
will be missing.
A lot more stuff to come with BTF,
reasonably simple? ;)
I suspect it doesn't support bpf-to-bpf calls and BTF, right?
These were major additions that folks with custom loader
will be missing.
A lot more stuff to come with BTF,
|
By
Alexei Starovoitov
·
#1510
·
|