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.

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