Hi, I would suggest something like tests/cc/test_brb.py or
tests/cc/test_brb2.py. The brb stands for bridge-router-bridge, with a
router implemented in a linux namespace in both versions. brb has the
bridge implemented in bpf, while brb2 has the bridge implemented as a
namespace, so you can compare and contrast.

On Thu, Nov 12, 2015 at 1:57 AM, O Mahony, Billy via iovisor-dev
<iovisor-dev@...> wrote:

Hi Alexei,

Thanks. I suspected something surprising like that going on!

I'd like to build a toy router with eBPF just to route some frames between interfaces.

So ideally I'd like to attach my eBPF program to frame ingress on a device, parse it and egress it on another device.

What's the best example to deep-dive into - I was thinking tc_neighbor_sharing?

/Billy.

-----Original Message-----
From: Alexei Starovoitov [mailto:alexei.starovoitov@...]
Sent: Wednesday, November 11, 2015 11:51 PM
To: O Mahony, Billy <billy.o.mahony@...>
Cc: Brenden Blanco <bblanco@...>; Daniel Borkmann
<daniel@...>; iovisor-dev@...
Subject: Re: [iovisor-dev] bpf_trace_printk

On Wed, Nov 11, 2015 at 3:14 PM, O Mahony, Billy via iovisor-dev <iovisor-
dev@...> wrote:

But thereafter when I ping either of the assigned addresses I don't see any

further invocations of the log message. I was expecting it to be called for
each eth frame received by the either of the interfaces.

if you're actually doing 'ping IPaddr' of veth interface, it doesn't actually go
into that veth.
If 'ip -s link show veth0' doesn't show stats incrementing it means that
packets are not seen by the device, so won't be seen by qdisc and won't be
seen by bpf either.

_______________________________________________
iovisor-dev mailing list
iovisor-dev@...
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Hi Alexei,

Thanks. I suspected something surprising like that going on!

I'd like to build a toy router with eBPF just to route some frames between interfaces.

So ideally I'd like to attach my eBPF program to frame ingress on a device, parse it and egress it on another device.

What's the best example to deep-dive into - I was thinking tc_neighbor_sharing?

/Billy.

On Wed, Nov 11, 2015 at 3:14 PM, O Mahony, Billy via iovisor-dev
<iovisor-dev@...> wrote:

But thereafter when I ping either of the assigned addresses I don't see any further invocations of the log message. I was expecting it to be called for each eth frame received by the either of the interfaces.

if you're actually doing 'ping IPaddr' of veth interface,
it doesn't actually go into that veth.
If 'ip -s link show veth0' doesn't show stats incrementing
it means that packets are not seen by the device,
so won't be seen by qdisc and won't be seen by bpf either.

On 11/12/2015 12:14 AM, O Mahony, Billy wrote:
...

One thing I notice is that immediately after I assign ip addrs to the endpoints of the veth pair I see several log messages:

<idle>-0 [000] .Ns. 73082.699758: : meep
ksoftirqd/0-3 [000] ..s. 73082.699828: : meep
<idle>-0 [000] ..s. 73082.960638: : meep
kworker/0:2-4011 [000] ..s. 73083.146783: : meep
kworker/0:2-4011 [000] ..s1 73083.346750: : meep
<idle>-0 [000] ..s. 73083.368876: : meep
kworker/0:2-4011 [000] ..s. 73084.146130: : meep
kworker/0:2-4011 [000] ..s. 73084.146238: : meep

But thereafter when I ping either of the assigned addresses I don't see any further invocations of the log message. I was expecting it to be called for each eth frame received by the either of the interfaces.

Ahh, they're not being moved into different netns'es in your
given setup, right? So, maybe try ping with -I on the peer?

Hi Daniel & Brendan,

Cool. Thanks for the help!

One thing I notice is that immediately after I assign ip addrs to the endpoints of the veth pair I see several log messages:

<idle>-0 [000] .Ns. 73082.699758: : meep
ksoftirqd/0-3 [000] ..s. 73082.699828: : meep
<idle>-0 [000] ..s. 73082.960638: : meep
kworker/0:2-4011 [000] ..s. 73083.146783: : meep
kworker/0:2-4011 [000] ..s1 73083.346750: : meep
<idle>-0 [000] ..s. 73083.368876: : meep
kworker/0:2-4011 [000] ..s. 73084.146130: : meep
kworker/0:2-4011 [000] ..s. 73084.146238: : meep

But thereafter when I ping either of the assigned addresses I don't see any further invocations of the log message. I was expecting it to be called for each eth frame received by the either of the interfaces.

Billy.

Hi,

The output goes into /sys/kernel/debug/tracing/trace_pipe (or elswhere
depending where you mount debugfs). If you look at the hello_world.py
example, it uses a helper in the BPF class, trace_print(), which does
a continuous read from the trace_pipe for you.

You could add a similar b.trace_print() in place of time.sleep(60), or
open a separate shell and do `cat
/sys/kernel/debug/tracing/trace_pipe`.

Thanks,
Brenden

On Wed, Nov 11, 2015 at 9:41 AM, O Mahony, Billy via iovisor-dev
<iovisor-dev@...> wrote:

Hi,

Where should I see o/p from bpf_trace_printk() ?

I've added bpf_trace_printk to examples/simple_tc. And also a long sleep after the veth pair is setup.

It compiles without complaint. After I start the simple_tc I add ip addrs to the veth pair with ifconfig. And ping the assigned addresses which works. But I don't see any o/p in dmesg for example.

Below are the changes to simple_tc.py along with the filter itself which had to go into it's own .c file in order to compile once the trace was added.

Regards,
Billy.



billy@ubuntu:~/iovisor/bcc/examples$ git diff
diff --git a/examples/simple_tc.py b/examples/simple_tc.py
index 4dd8aa5..01843b3 100755
--- a/examples/simple_tc.py
+++ b/examples/simple_tc.py
@@ -4,6 +4,7 @@

from bcc import BPF
from pyroute2 import IPRoute
+import time

ipr = IPRoute()

@@ -14,7 +15,7 @@ int hello(struct __sk_buff *skb) {
"""

try:
- b = BPF(text=text, debug=0)
+ b = BPF(src_file="simple_tc.c", debug=0)
fn = b.load_func("hello", BPF.SCHED_CLS)
ipr.link_create(ifname="t1a", kind="veth", peer="t1b")
idx = ipr.link_lookup(ifname="t1a")[0]
@@ -25,6 +26,7 @@ try:
ipr.tc("add", "sfq", idx, "1:")
ipr.tc("add-filter", "bpf", idx, ":1", fd=fn.fd,
name=fn.name, parent="1:", action="ok", classid=1)
+ time.sleep(60)
finally:
if "idx" in locals(): ipr.link_remove(idx)
print("BPF tc functionality - SCHED_CLS: OK")
billy@ubuntu:~/iovisor/bcc/examples$



billy@ubuntu:~/iovisor/bcc$ cat examples/simple_tc.c
#include <uapi/linux/ptrace.h>
#include <linux/blkdev.h>

int hello(struct __sk_buff *skb) {
bpf_trace_printk("meep\n");
return 1;
}
_______________________________________________
iovisor-dev mailing list
iovisor-dev@...
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

On 11/11/2015 06:41 PM, O Mahony, Billy via iovisor-dev wrote:

Hi,

Where should I see o/p from bpf_trace_printk() ?

Depends where you have tracefs mounted, f.e.

cat /sys/kernel/debug/tracing/trace_pipe

Cheers,
Daniel

Hi,

Where should I see o/p from bpf_trace_printk() ?

I've added bpf_trace_printk to examples/simple_tc. And also a long sleep after the veth pair is setup.

It compiles without complaint. After I start the simple_tc I add ip addrs to the veth pair with ifconfig. And ping the assigned addresses which works. But I don't see any o/p in dmesg for example.

Below are the changes to simple_tc.py along with the filter itself which had to go into it's own .c file in order to compile once the trace was added.

Regards,
Billy.



billy@ubuntu:~/iovisor/bcc/examples$ git diff
diff --git a/examples/simple_tc.py b/examples/simple_tc.py
index 4dd8aa5..01843b3 100755
--- a/examples/simple_tc.py
+++ b/examples/simple_tc.py
@@ -4,6 +4,7 @@

from bcc import BPF
from pyroute2 import IPRoute
+import time

ipr = IPRoute()

@@ -14,7 +15,7 @@ int hello(struct __sk_buff *skb) {
"""

try:
- b = BPF(text=text, debug=0)
+ b = BPF(src_file="simple_tc.c", debug=0)
fn = b.load_func("hello", BPF.SCHED_CLS)
ipr.link_create(ifname="t1a", kind="veth", peer="t1b")
idx = ipr.link_lookup(ifname="t1a")[0]
@@ -25,6 +26,7 @@ try:
ipr.tc("add", "sfq", idx, "1:")
ipr.tc("add-filter", "bpf", idx, ":1", fd=fn.fd,
name=fn.name, parent="1:", action="ok", classid=1)
+ time.sleep(60)
finally:
if "idx" in locals(): ipr.link_remove(idx)
print("BPF tc functionality - SCHED_CLS: OK")
billy@ubuntu:~/iovisor/bcc/examples$



billy@ubuntu:~/iovisor/bcc$ cat examples/simple_tc.c
#include <uapi/linux/ptrace.h>
#include <linux/blkdev.h>

int hello(struct __sk_buff *skb) {
bpf_trace_printk("meep\n");
return 1;
}