-----Original Message-----
From: Brenden Blanco [mailto:bblanco@...]
Sent: Monday, March 7, 2016 7:19 PM
To: Daniel Borkmann <daniel@...>
Cc: O Mahony, Billy <billy.o.mahony@...>; iovisor-
dev@...
Subject: Re: [iovisor-dev] unknown func 13

On Mon, Mar 7, 2016 at 10:56 AM, Daniel Borkmann <daniel@...>
wrote:

On 03/07/2016 07:39 PM, O Mahony, Billy via iovisor-dev wrote:

Hi Brendan,

Hurrah! I have packets traversing my interfaces via eBPF.

Thanks for all your help.

As I said at one of the iovisor calls I planned to run some basic
throughput tests and share the results with you guys. I got some
*very* rudimentary figures this afternoon. Though before posting
them I'd like to ensure I'm running a reasonably performant setup.

So currently I am running an eBPF action hanging off a u32 filter on
the ingress qdisc. Looking at the slide "Hooking in to the Linux
network stack (RX)" from bpf_network_examples_2015aug20.pdf it
suggests that I could also attach my eBPF program via a TAP device which

would avoid the TC overhead.

If in terms of tc "overhead" you mean first going through this fake
u32 match-all classifier, then, as suggested, you can simply use
cls_bpf with direct action mode. Check out the
bpf_netdev_conference_2016Feb12.pdf presentation in bpf-docs repo, for
example. I presume bcc might support that as well (or soon, depending
on the pull reqs?)?

Both the pyroute2 and go netlink pull requests have merged, so both clsact
and direct-action mode are supported as far as bcc is concerned. Billy
mentioned that he wanted to stay on 4.4 kernel for now, so that is the only
missing piece.

[[BO'M]] Now that I have something working I feel much happier about compiling a new kernel. I'll checkout the examples and docs you recommend.

Thanks, Daniel & Brendan.

Cheers,
Daniel

Are there any examples for that?

Billy.

-----Original Message-----
From: Brenden Blanco [mailto:bblanco@...]
Sent: Friday, March 4, 2016 10:09 PM
To: O Mahony, Billy <billy.o.mahony@...>
Cc: Daniel Borkmann <daniel@...>;
iovisor-dev@...
Subject: Re: [iovisor-dev] unknown func 13

On Fri, Mar 4, 2016 at 10:01 AM, O Mahony, Billy
<billy.o.mahony@...>
wrote:

Hi Daniel, Brendan,

Thanks for the tips. Unless what I'm trying to do just won't work
I'll stick

with kernel 4.4 and the ingress qdisc for now.

So I changed my bpf programs to look like this:
6 int eth1_ic(struct __sk_buff *skb) {
7 bpf_trace_printk ("eth1_ic\n");
8 bpf_redirect(5, 0);
9 return TC_ACT_REDIRECT;

That's fine, it'll still work.

However, I still don’t see packets being received by the traffic
generator I

have attached to eht1 and eth3.

If I also run BPF.trace_print in a separate console (actually
hello_world.py) I

can see the trace statements but not at anything like the rate that
I configured the traffic generator to generate packets
(100pkts/sec). Also if I vary the rate of traffic ingress on the
eth1/3 the ratio of the corresponding trace lines does not change -
so not sure what is going on there.

Probably arp is failing, your generator is probably doing nothing
because it can't resolve the other side.

avahi-daemon-1006 [031] ..s. 10942.915221: : eth1_ic
avahi-daemon-1006 [031] ..s. 10943.100833: : eth1_ic
avahi-daemon-1006 [031] ..s. 10943.182141: : eth3_ic
avahi-daemon-1006 [031] ..s. 10943.801170: : eth1_ic
avahi-daemon-1006 [031] ..s. 10944.375068: : eth3_ic
avahi-daemon-1006 [031] ..s. 10944.560597: : eth3_ic

BTW my tc filter output looks like so:

$ tc filter show dev eth3 parent ffff:
filter protocol all pref 49152 u32
filter protocol all pref 49152 u32 fh 800: ht divisor 1 filter
protocol all pref 49152 u32 fh 800::1 order 1 key ht 800 bkt 0
flowid
1:2
match 00000000/00000000 at 0
action order 1: gact action pass
random type none pass val 0
index 10 ref 1 bind 1

Is your iproute2 up to date? This usually misses showing the bpf
program since it doesn't understand the flags. If you can build
iproute2 from source, preferably from the net-next branch, you will
see more useful information. I would also include "tc -s" in the
output so you can see drops/passes.

If you are in fact using the latest iproute2, then the above filters
are wrong. It should look more like this:

filter protocol all pref 49152 u32
filter protocol all pref 49152 u32 fh 800: ht divisor 1 filter
protocol all pref
49152 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid 1:2
match 00000000/00000000 at 0
action order 1: bpf on_packet default-action pass
index 1 ref 1 bind 1 installed 0 sec used 0 sec
Action statistics:
Sent 112 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

Thanks again,

Billy.

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