Date   

Re: unknown func 13

O Mahony, Billy <billy.o.mahony@...>
 

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;

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.

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

Thanks again,

Billy.

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

On 03/03/2016 10:01 PM, Brenden Blanco wrote:
On Thu, Mar 3, 2016 at 11:31 AM, Daniel Borkmann
<daniel@...>
wrote:

On 03/03/2016 08:19 PM, Brenden Blanco via iovisor-dev wrote:
[...]

On Thu, Mar 3, 2016 at 5:52 AM, O Mahony, Billy
<billy.o.mahony@...
[...]

#add a filter to accept all eth frame. Attach the bpf action?
functions
to the filter?

#I have no idea what the classid, target and keys parameters mean!

ip.tc("add-filter", "u32", ifindex_eth1, ":1", parent="ffff:",

action=[action_eth1],

protocol=protocols.ETH_P_ALL, classid=1,

target=0x10002, keys=['0x0/0x0+0'])

ip.tc("add-filter", "u32", ifindex_eth3, ":1", parent="ffff:",

action=[action_eth3],

protocol=protocols.ETH_P_ALL, classid=1,

target=0x10002, keys=['0x0/0x0+0'])

Yeah, it's a bit of black magic. it's basically creating a
match-all rule (match 0 bytes and offset 0 == true), with the
matching action being the bpf program. The classid and target aren't
really meaningful with just one action and filter, so it's ok to ignore for
now.

The clsact qdisc added in 4.5 by Daniel Borkmann is a much better
abstraction for this, and I'll try to upstream some pyroute2 code to
support this.
Plus you may also want to try out cls_bpf with da (direct-action) mode.
That will save you the u32 match all classifier config and is faster.
Speaking of which, I just opened
https://github.com/svinota/pyroute2/pull/223 to add support in
pyroute2 upstream. The docstring in that pull request shows an example
usage, which I'll also add to a testcase in bcc once it merges upstream.

I've done similar additions for go in
https://github.com/vishvananda/netlink/pull/94, if go is your thing.
That's awesome, thanks Brenden!


Re: unknown func 13

Brenden Blanco <bblanco@...>
 

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.


Re: unknown func 13

O Mahony, Billy <billy.o.mahony@...>
 

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.

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.


Re: unknown func 13

Brenden Blanco <bblanco@...>
 

On Mon, Mar 7, 2016 at 10:39 AM, O Mahony, Billy
<billy.o.mahony@...> wrote:
Hi Brendan,

Hurrah! I have packets traversing my interfaces via eBPF.
Nice!

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.
That seems contrary to my own expectations. TC is closer to the metal
than SOCKET_FILTER, the ingress qdisc should already be lightweight
(lockless for example). The optimizations mentioned earlier in this
thread are adding icing to the cake. Besides that, the SOCKET_FILTER
program type doesn't allow modification or actions, only capture, so
bpf_redirect() wouldn't be available to you there.

Are there any examples for that?
tests/python/test_stat1.py uses a BPF.SOCKET_FILTER program.

Billy.


Re: unknown func 13

Daniel Borkmann
 

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?)?

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


Re: unknown func 13

Brenden Blanco <bblanco@...>
 

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


Re: unknown func 13

O Mahony, Billy <billy.o.mahony@...>
 

-----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


ONS

O Mahony, Billy <billy.o.mahony@...>
 

Hi All,

I see Pere Monclus is giving a talk at ONS next week. Just wondering if anyone is planning to attend?

And if there is any breakout BOF session planned for all things ioVisor/eBPF.

I will be there myself all week as part of the OPNFV hackfest.

Regards,
/Billy


Re: ONS

Alexei Starovoitov
 

On Tue, Mar 8, 2016 at 7:10 AM, O Mahony, Billy via iovisor-dev
<iovisor-dev@...> wrote:
Hi All,

I see Pere Monclus is giving a talk at ONS next week. Just wondering if anyone is planning to attend?

And if there is any breakout BOF session planned for all things ioVisor/eBPF.

I will be there myself all week as part of the OPNFV hackfest.
I'll be at NSDI 16-18 (which is in the same building). Would be great
to sync up.
The kernel meetup is on Mar 16 as well.


Re: ONS

Brenden Blanco <bblanco@...>
 

On Tue, Mar 8, 2016 at 10:56 AM, Alexei Starovoitov via iovisor-dev
<iovisor-dev@...> wrote:
On Tue, Mar 8, 2016 at 7:10 AM, O Mahony, Billy via iovisor-dev
<iovisor-dev@...> wrote:
Hi All,

I see Pere Monclus is giving a talk at ONS next week. Just wondering if anyone is planning to attend?

And if there is any breakout BOF session planned for all things ioVisor/eBPF.

I will be there myself all week as part of the OPNFV hackfest.
I'll be at NSDI 16-18 (which is in the same building). Would be great
to sync up.
The kernel meetup is on Mar 16 as well.
I won't be at either conference, but the PLUMgrid office is right
across the street. We could potentially have something here.


Re: ONS

O Mahony, Billy <billy.o.mahony@...>
 

That's great, guys.

I'll ping you next week and we can make a concrete plan then.

Cheers,
Billy.

-----Original Message-----
From: Brenden Blanco [mailto:bblanco@...]
Sent: Tuesday, March 8, 2016 7:02 PM
To: Alexei Starovoitov <alexei.starovoitov@...>
Cc: O Mahony, Billy <billy.o.mahony@...>; iovisor-
dev@...
Subject: Re: [iovisor-dev] ONS

On Tue, Mar 8, 2016 at 10:56 AM, Alexei Starovoitov via iovisor-dev <iovisor-
dev@...> wrote:
On Tue, Mar 8, 2016 at 7:10 AM, O Mahony, Billy via iovisor-dev
<iovisor-dev@...> wrote:
Hi All,

I see Pere Monclus is giving a talk at ONS next week. Just wondering if
anyone is planning to attend?

And if there is any breakout BOF session planned for all things
ioVisor/eBPF.

I will be there myself all week as part of the OPNFV hackfest.
I'll be at NSDI 16-18 (which is in the same building). Would be great
to sync up.
The kernel meetup is on Mar 16 as well.
I won't be at either conference, but the PLUMgrid office is right across the
street. We could potentially have something here.


Re: ONS

Keith Burns <alagalah@...>
 

Anyone going to the devops networking session on Monday? Same bldg diff event.

On Mar 8, 2016 11:02 AM, "Brenden Blanco via iovisor-dev" <iovisor-dev@...> wrote:

On Tue, Mar 8, 2016 at 10:56 AM, Alexei Starovoitov via iovisor-dev
<iovisor-dev@...> wrote:
> On Tue, Mar 8, 2016 at 7:10 AM, O Mahony, Billy via iovisor-dev
> <iovisor-dev@...> wrote:
>> Hi All,
>>
>> I see Pere Monclus is giving a talk at ONS next week. Just wondering if anyone is planning to attend?
>>
>> And if there is any breakout BOF session planned for all things ioVisor/eBPF.
>>
>> I will be there myself all week as part of the OPNFV hackfest.
>
> I'll be at NSDI 16-18 (which is in the same building). Would be great
> to sync up.
> The kernel meetup is on Mar 16 as well.

I won't be at either conference, but the PLUMgrid office is right
across the street. We could potentially have something here.
_______________________________________________
iovisor-dev mailing list
iovisor-dev@...
https://lists.iovisor.org/mailman/listinfo/iovisor-dev


rescheduled: IO Visor TSC and Dev Members Call

Brenden Blanco <bblanco@...>
 

Hi,

This week there is a series of conferences (NSDI, ONS) taking place that overlap with the scheduled call. Therefore, I would like to push this call out by one week.

Thanks,
Brenden


Canceled Event: IOvisor TSC & Dev Members call @ Wed Mar 16, 2016 11am - 12pm (pmonclus@plumgrid.com)

Pere Monclus
 

This event has been canceled and removed from your calendar.

IOvisor TSC & Dev Members call

Hi,

Please feel free to join us today at 11am PST (1900 UTC) for another round of IOVisor developer updates and discussions.

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2016&month=2&day=3&hour=19&min=0&sec=0&p1=886

The meeting is open to join:

JOIN WEBEX MEETING
https://plumgrid.webex.com/plumgrid/j.php?MTID=m67436ba0408d6bad48acd69138c03aea
Meeting number: 283 885 640
Meeting password: iovisor


JOIN BY PHONE
+1-415-655-0003 US TOLL
Access code: 283 885 640

Global call-in numbers:
https://plumgrid.webex.com/plumgrid/globalcallin.php?serviceType=MC&ED=44474908&tollFree=0

Can't join the meeting? Contact support here:
https://plumgrid.webex.com/plumgrid/mc


IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.


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

When
Wed Mar 16, 2016 11am – 12pm Pacific Time
Where
webex updated (map)
Video call
https://plus.google.com/hangouts/_/plumgrid.com/iovisor
Calendar
pmonclus@...
Who
Pere Monclus - organizer
Alexei Starovoitov
iovisor-dev@...
krb@...
yunsong.lu@...
Ed Doe
Affan Ahmed Syed
Bhushan Kanekar
bkanekar@...
John Zannos
aclark@...
Brenden Blanco
jianwen.pi@...
prem@...
mbudiu@...
developer@...
Prasun Kapoor
uri.elzur@...
mc3124@...
wardd@...
Neela Jacques
David Duffey
john fastabend
Rich Lane
Shehzad Ismail
Sushil Singh
christopher.price@...

Invitation from Google Calendar

You are receiving this courtesy email at the account iovisor-dev@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Canceled Event: IOvisor TSC & Dev Members call @ Wed Mar 16, 2016 11am - 12pm (pmonclus@plumgrid.com)

Pere Monclus
 

This event has been canceled and removed from your calendar.

IOvisor TSC & Dev Members call

Hi,

Please feel free to join us today at 11am PST (1900 UTC) for another round of IOVisor developer updates and discussions.

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2016&month=2&day=3&hour=19&min=0&sec=0&p1=886

The meeting is open to join:

JOIN WEBEX MEETING
https://plumgrid.webex.com/plumgrid/j.php?MTID=m67436ba0408d6bad48acd69138c03aea
Meeting number: 283 885 640
Meeting password: iovisor


JOIN BY PHONE
+1-415-655-0003 US TOLL
Access code: 283 885 640

Global call-in numbers:
https://plumgrid.webex.com/plumgrid/globalcallin.php?serviceType=MC&ED=44474908&tollFree=0

Can't join the meeting? Contact support here:
https://plumgrid.webex.com/plumgrid/mc


IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.


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

When
Wed Mar 16, 2016 11am – 12pm Pacific Time
Where
webex updated (map)
Video call
https://plus.google.com/hangouts/_/plumgrid.com/iovisor
Calendar
pmonclus@...
Who
Pere Monclus - organizer
Alexei Starovoitov
iovisor-dev@...
krb@...
yunsong.lu@...
Ed Doe
Affan Ahmed Syed
Bhushan Kanekar
bkanekar@...
John Zannos
aclark@...
Brenden Blanco
jianwen.pi@...
prem@...
mbudiu@...
developer@...
Prasun Kapoor
uri.elzur@...
mc3124@...
wardd@...
Neela Jacques
David Duffey
john fastabend
Rich Lane
Shehzad Ismail
Sushil Singh
christopher.price@...

Invitation from Google Calendar

You are receiving this courtesy email at the account developer@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Question about IO Visor Tunnel monitor

이준기 <jkleethemonarch@...>
 

To IO Visor devs,

 

Hello, I’m Jungi Lee, student who is studying about OpenStack Cloud.

I’m operating multi-site OpenStack cloud and I thought that I need to monitor the connection between sites.

So I tried to find a way to monitor vxlan tunnels which are created and held by OpenStack neutron,

I found IO Visor BCC’s example code, “Tunnel monitor”. (https://github.com/iovisor/bcc/tree/master/examples/networking/tunnel_monitor)


I set up the IO Visor BCC environment and tested with uploaded tunnel monitor codes successfully.

Then I tried to change the codes with my OpenStack vxlan tunnel settings to capture and show the status of vxlan tunnels, but it doesn’t work.

None of vxlan tunnels are showed by node.js based web page.

For this reason, I want to get some help if there are anyone who is using IO Visor to monitor a status of vxlan tunnels with OpenStack cloud.

Thank you for your reading.

 

Best wishes,

Jungi Lee


Re: rescheduled: IO Visor TSC and Dev Members Call

Brenden Blanco <bblanco@...>
 

Unfortunately, this email was erroneously sitting in my outbox since yesterday. If people are able to join on short notice and have a topic to discuss, please join in, otherwise we will have this next week as regularly scheduled.

----------------------------

Hi,

Let's catch up on IO Visor activities: please join us tomorrow! Last meeting was devoted to XDP, so this week it would be good to spend some time talking about the various tracing changes that are being worked on.

Here's the webex info:

IOVisor TSC/Dev Meeting
Wednesday, March 23, 2016
11:00 am  |  Pacific Daylight Time (San Francisco, GMT-07:00)  |  1 hr
 
Join WebEx meeting
Meeting number:805 694 421
Meeting password:iovisor
 
Join by phone
+1-415-655-0003 US TOLL
Access code: 805 694 421
Global call-in numbers
 
Add this meeting to your calendar. (Cannot add from mobile devices.)


On Mon, Mar 14, 2016 at 7:07 PM, Brenden Blanco <bblanco@...> wrote:
Hi,

This week there is a series of conferences (NSDI, ONS) taking place that overlap with the scheduled call. Therefore, I would like to push this call out by one week.

Thanks,
Brenden


Re: Question about IO Visor Tunnel monitor

Brenden Blanco <bblanco@...>
 

Hello Jungi Lee,

To my knowledge, you are the only person to adapt that code to OpenStack, though there is no reason that it should not work. The first place to start would be to modify the monitor.py file to dump the entries in the stats table to stdout instead of to the file. That will give visibility into whether the table is updating or not. The code in main.py and simulation.py should not be used at all, since they just exist to set up the vxlan device for the test environment. Just monitor.py and monitor.c are needed.

If you care to share a snippet of the modified monitor.py, and any output that running that file gives, maybe we could help further.

Cheers,
Brenden

On Tue, Mar 22, 2016 at 11:07 PM, "이준기" <iovisor-dev@...> wrote:

To IO Visor devs,

 

Hello, I’m Jungi Lee, student who is studying about OpenStack Cloud.

I’m operating multi-site OpenStack cloud and I thought that I need to monitor the connection between sites.

So I tried to find a way to monitor vxlan tunnels which are created and held by OpenStack neutron,

I found IO Visor BCC’s example code, “Tunnel monitor”. (https://github.com/iovisor/bcc/tree/master/examples/networking/tunnel_monitor)


I set up the IO Visor BCC environment and tested with uploaded tunnel monitor codes successfully.

Then I tried to change the codes with my OpenStack vxlan tunnel settings to capture and show the status of vxlan tunnels, but it doesn’t work.

None of vxlan tunnels are showed by node.js based web page.

For this reason, I want to get some help if there are anyone who is using IO Visor to monitor a status of vxlan tunnels with OpenStack cloud.

Thank you for your reading.

 

Best wishes,

Jungi Lee


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



reminder: IO Visor TSC and Dev Members Call

Brenden Blanco <bblanco@...>
 

Hi All,

Please join us for our bi-weekly call. This meeting is open to
everybody and completely optional.

Topics for this week:
1. Discuss ongoing work around tracing:
- tracepoints update
- USDT
2. New binding development
- Lua!
3. Documentation
4. Open /issues


http://www.timeanddate.com/worldclock/meetingdetails.html?year=2016&month=3&day=30&hour=19&min=0&sec=0&p1=886

The meeting is open to join:

JOIN WEBEX MEETING
https://plumgrid.webex.com/plumgrid/j.php?MTID=m67436ba0408d6bad48acd69138c03aea
Meeting number: 283 885 640
Meeting password: iovisor


JOIN BY PHONE
+1-415-655-0003 US TOLL
Access code: 283 885 640

Global call-in numbers:
https://plumgrid.webex.com/plumgrid/globalcallin.php?serviceType=MC&ED=44474908&tollFree=0


Re: reminder: IO Visor TSC and Dev Members Call

Brenden Blanco <bblanco@...>
 

FYI, I've gotten two comments already...this is in fact planned for
tomorrow, the wording of the email suggested it might be happening
today.

Sorry for the confusion.

On Tue, Mar 29, 2016 at 10:50 AM, Brenden Blanco <bblanco@...> wrote:
Hi All,

Please join us for our bi-weekly call. This meeting is open to
everybody and completely optional.

Topics for this week:
1. Discuss ongoing work around tracing:
- tracepoints update
- USDT
2. New binding development
- Lua!
3. Documentation
4. Open /issues


http://www.timeanddate.com/worldclock/meetingdetails.html?year=2016&month=3&day=30&hour=19&min=0&sec=0&p1=886

The meeting is open to join:

JOIN WEBEX MEETING
https://plumgrid.webex.com/plumgrid/j.php?MTID=m67436ba0408d6bad48acd69138c03aea
Meeting number: 283 885 640
Meeting password: iovisor


JOIN BY PHONE
+1-415-655-0003 US TOLL
Access code: 283 885 640

Global call-in numbers:
https://plumgrid.webex.com/plumgrid/globalcallin.php?serviceType=MC&ED=44474908&tollFree=0

101 - 120 of 2021