act_bpf update

PATCH In review Daniel Borkmann 4 participants 12 messages Mar 20, 2015

Subsystems (6)

Networking Network drivers BPF BPF core +2 more subsystems

lore

Share & tools

lore

Daniel Borkmann

author maintainer

2015-03-20 14:11 UTC #0 lore raw

cover act_bpf update

This set adds native eBPF support also to act_bpf and thus covers tc with eBPF in the classifier *and* action part.

A link to iproute2 preview has been provided in patch 2 and the code will be pushed out after Stephen has processed the classifier part and helper bits for tc.

This set depends on ced585c83b27 ("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"), so a net into net-next merge would be required first. Hope that's fine by you, Dave. ;)

Thanks a lot!

Daniel Borkmann (2):
ebpf: add sched_act_type and map it to sk_filter's verifier ops
act_bpf: add initial eBPF support for actions

 include/net/tc_act/tc_bpf.h        |   6 +-
 include/uapi/linux/bpf.h           |   1 +
 include/uapi/linux/tc_act/tc_bpf.h |   2 +
 kernel/bpf/verifier.c              |   1 +
 net/core/filter.c                  |   6 +
 net/sched/act_bpf.c                | 295 ++++++++++++++++++++++++++-----------
 6 files changed, 228 insertions(+), 83 deletions(-)

Signature · 1 line

1.9.3

Daniel Borkmann

author maintainer

2015-03-20 14:11 UTC #4 lore raw

PATCH 2/2 act_bpf: add initial eBPF support for actions

This work extends the "classic" BPF programmable tc action by extending its scope also to native eBPF code!

Together with commit e2e9b6541dd4 ("cls_bpf: add initial eBPF support for programmable classifiers") this adds the facility to implement fully flexible classifier and actions for tc that can be implemented in a C subset in user space, "safely" loaded into the kernel, and being run in native speed when JITed.

Also, since eBPF maps can be shared between eBPF programs, it offers the possibility that cls_bpf and act_bpf can share data 1) between themselves and 2) between user space applications. That means that, f.e. customized runtime statistics can be collected in user space, but also more importantly classifier and action behaviour could be altered based on map input from the user space application.

For the remaining details on the workflow and integration, see the cls_bpf commit e2e9b6541dd4. Preliminary iproute2 part can be found under [1].

[1] http://git.breakpoint.cc/cgit/dborkman/iproute2.git/log/?h=ebpf-act

Signed-off-by Daniel Borkmann <[email protected]>

Cc Jamal Hadi Salim <[email protected]>

Cc Jiri Pirko <[email protected]>

---
 include/net/tc_act/tc_bpf.h        |   6 +-
 include/uapi/linux/tc_act/tc_bpf.h |   2 +
 net/sched/act_bpf.c                | 295 ++++++++++++++++++++++++++-----------
 3 files changed, 220 insertions(+), 83 deletions(-)

include/net/tc_act/tc_bpf.h +5 -1

index 86a070f..a152e98 100644
@@ -16,8 +16,12 @@
 struct tcf_bpf {
 	struct tcf_common	common;
 	struct bpf_prog		*filter;
+	union {
+		u32		bpf_fd;
+		u16		bpf_num_ops;
+	};
 	struct sock_filter	*bpf_ops;
-	u16			bpf_num_ops;
+	const char		*bpf_name;
 };
 #define to_bpf(a) \
 	container_of(a->priv, struct tcf_bpf, common)

include/uapi/linux/tc_act/tc_bpf.h +2 -0

index 5288bd77..07f17cc 100644
@@ -24,6 +24,8 @@ enum {
 	TCA_ACT_BPF_PARMS,
 	TCA_ACT_BPF_OPS_LEN,
 	TCA_ACT_BPF_OPS,
+	TCA_ACT_BPF_FD,
+	TCA_ACT_BPF_NAME,
 	__TCA_ACT_BPF_MAX,
 };
 #define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)

net/sched/act_bpf.c +213 ~~-82~~

395 lines not on this page · raw message

Signature · 1 line

1.9.3

Daniel Borkmann

author maintainer

2015-03-20 14:11 UTC #1 lore raw

PATCH 1/2 ebpf: add sched_act_type and map it to sk_filter's verifier ops

In reply to Daniel Borkmann

In order to prepare eBPF support for tc action, we need to add sched_act_type, so that the eBPF verifier is aware of what helper function act_bpf may use, that it can load skb data and read out currently available skb fields.

This is bascially analogous to 96be4325f443 ("ebpf: add sched_cls_type and map it to sk_filter's verifier ops").

BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT need to be separate since both will have a different set of functionality in future (classifier vs action), thus we won't run into ABI troubles when the point in time comes to diverge functionality from the classifier.

The future plan for act_bpf would be that it will be able to write into skb->data and alter selected fields mirrored in struct __sk_buff.

For an initial support, it's sufficient to map it to sk_filter_ops.

Signed-off-by Daniel Borkmann <[email protected]>

Cc Jiri Pirko <[email protected]>

---
 include/uapi/linux/bpf.h | 1 +
 kernel/bpf/verifier.c    | 1 +
 net/core/filter.c        | 6 ++++++
 3 files changed, 8 insertions(+)

include/uapi/linux/bpf.h +1 -0

index 1623047..3dd314a 100644
@@ -119,6 +119,7 @@ enum bpf_prog_type {
 	BPF_PROG_TYPE_UNSPEC,
 	BPF_PROG_TYPE_SOCKET_FILTER,
 	BPF_PROG_TYPE_SCHED_CLS,
+	BPF_PROG_TYPE_SCHED_ACT,
 };
 
 #define BPF_PSEUDO_MAP_FD	1

kernel/bpf/verifier.c +1 -0

index c22ebd3..0e714f7 100644
@@ -1180,6 +1180,7 @@ static bool may_access_skb(enum bpf_prog_type type)
 	switch (type) {
 	case BPF_PROG_TYPE_SOCKET_FILTER:
 	case BPF_PROG_TYPE_SCHED_CLS:
+	case BPF_PROG_TYPE_SCHED_ACT:
 		return true;
 	default:
 		return false;

net/core/filter.c +6 -0

index b95ae7f..3bc6482 100644
@@ -1264,10 +1264,16 @@ static struct bpf_prog_type_list sched_cls_type __read_mostly = {
 	.type = BPF_PROG_TYPE_SCHED_CLS,
 };
 
+static struct bpf_prog_type_list sched_act_type __read_mostly = {
+	.ops = &sk_filter_ops,
+	.type = BPF_PROG_TYPE_SCHED_ACT,
+};
+
 static int __init register_sk_filter_ops(void)
 {
 	bpf_register_prog_type(&sk_filter_type);
 	bpf_register_prog_type(&sched_cls_type);
+	bpf_register_prog_type(&sched_act_type);
 
 	return 0;
 }

Signature · 1 line

1.9.3

Jiri Pirko

maintainer Reviewed-by on v1 1/2

2015-03-20 14:21 UTC #2 lore raw

Re: [PATCH net-next 1/2] ebpf: add sched_act_type and map it to sk_filter's verifier ops

Quoted 14 lines · Fri, Mar 20, 2015 at 03:11:11PM CET, [email protected] wrote:

In order to prepare eBPF support for tc action, we need to add sched_act_type, so that the eBPF verifier is aware of what helper function act_bpf may use, that it can load skb data and read out currently available skb fields.
This is bascially analogous to 96be4325f443 ("ebpf: add sched_cls_type and map it to sk_filter's verifier ops").
BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT need to be separate since both will have a different set of functionality in future (classifier vs action), thus we won't run into ABI troubles when the point in time comes to diverge functionality from the classifier.

Quoted 7 lines

The future plan for act_bpf would be that it will be able to write into skb->data and alter selected fields mirrored in struct __sk_buff.
For an initial support, it's sufficient to map it to sk_filter_ops.
Signed-off-by Daniel Borkmann <[email protected]>
Cc Jiri Pirko <[email protected]>

Reviewed-by Jiri Pirko <[email protected]>

Jiri Pirko

maintainer Acked-by on v1 2/2

2015-03-20 14:30 UTC #5 lore raw

Re: [PATCH net-next 2/2] act_bpf: add initial eBPF support for actions

In reply to Daniel Borkmann

Quoted 16 lines · Fri, Mar 20, 2015 at 03:11:12PM CET, [email protected] wrote:

This work extends the "classic" BPF programmable tc action by extending its scope also to native eBPF code!
Together with commit e2e9b6541dd4 ("cls_bpf: add initial eBPF support for programmable classifiers") this adds the facility to implement fully flexible classifier and actions for tc that can be implemented in a C subset in user space, "safely" loaded into the kernel, and being run in native speed when JITed.
Also, since eBPF maps can be shared between eBPF programs, it offers the possibility that cls_bpf and act_bpf can share data 1) between themselves and 2) between user space applications. That means that, f.e. customized runtime statistics can be collected in user space, but also more importantly classifier and action behaviour could be altered based on map input from the user space application.

Quoted 8 lines

For the remaining details on the workflow and integration, see the cls_bpf commit e2e9b6541dd4. Preliminary iproute2 part can be found under [1].
[1] http://git.breakpoint.cc/cgit/dborkman/iproute2.git/log/?h=ebpf-act
Signed-off-by Daniel Borkmann <[email protected]>
Cc Jamal Hadi Salim <[email protected]>
Cc Jiri Pirko <[email protected]>

Would be easier to review without the variable renames.

But still, I like this a lot! Thanks!

Acked-by Jiri Pirko <[email protected]>

David Miller

maintainer

2015-03-20 20:22 UTC #7 lore raw

In reply to Daniel Borkmann

From: Daniel Borkmann <[email protected]>
Date: Fri, 20 Mar 2015 15:11:10 +0100

Quoted 7 lines

This set adds native eBPF support also to act_bpf and thus covers tc with eBPF in the classifier *and* action part.
A link to iproute2 preview has been provided in patch 2 and the code will be pushed out after Stephen has processed the classifier part and helper bits for tc.

Quoted 5 lines

This set depends on ced585c83b27 ("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"), so a net into net-next merge would be required first. Hope that's fine by you, Dave. ;)
Thanks a lot!

Even with that commit, which is in net-next now, this series does not apply without rejects.

Please respin.

Daniel Borkmann

author maintainer

2015-03-20 21:10 UTC #8 lore raw

Hi Dave,

Quoted 14 lines · David Miller

From: Daniel Borkmann <[email protected]>
Date: Fri, 20 Mar 2015 15:11:10 +0100
Quoted 11 lines
This set adds native eBPF support also to act_bpf and thus covers tc with eBPF in the classifier *and* action part.
A link to iproute2 preview has been provided in patch 2 and the code will be pushed out after Stephen has processed the classifier part and helper bits for tc.
This set depends on ced585c83b27 ("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"), so a net into net-next merge would be required first. Hope that's fine by you, Dave. ;)

Quoted 6 lines

Quoted 1 line
Thanks a lot!
Even with that commit, which is in net-next now, this series does not apply without rejects.
Please respin.

So my HEAD is at latest net-next commit b4c11cb437fdb34b ("Merge branch 'amd-xgbe-next'"):

  $ git cherry-pick ced585c83b27deca427c606a34dd3eaa6b96d82b
  [ebpf-act 1b8dfa9] act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome
   1 file changed, 28 insertions(+), 8 deletions(-)
  $ git am 0001-ebpf-add-sched_act_type-and-map-it-to-sk_filter-s-ve.patch
  Applying: ebpf: add sched_act_type and map it to sk_filter's verifier ops
  $ git am 0002-act_bpf-add-initial-eBPF-support-for-actions.patch
  Applying: act_bpf: add initial eBPF support for actions
  $

The dependency mentioned in the cover letter is on net commit ced585c83b27 ("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"). On my side that applies fine, hm.

Thanks,
Daniel

Alexei Starovoitov

Acked-by on v1 1/2

2015-03-20 21:12 UTC #3 lore raw

Re: [PATCH net-next 1/2] ebpf: add sched_act_type and map it to sk_filter's verifier ops

In reply to Daniel Borkmann

Quoted 14 lines · Daniel Borkmann

In order to prepare eBPF support for tc action, we need to add sched_act_type, so that the eBPF verifier is aware of what helper function act_bpf may use, that it can load skb data and read out currently available skb fields.
This is bascially analogous to 96be4325f443 ("ebpf: add sched_cls_type and map it to sk_filter's verifier ops").
BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT need to be separate since both will have a different set of functionality in future (classifier vs action), thus we won't run into ABI troubles when the point in time comes to diverge functionality from the classifier.

Quoted 7 lines

The future plan for act_bpf would be that it will be able to write into skb->data and alter selected fields mirrored in struct __sk_buff.
For an initial support, it's sufficient to map it to sk_filter_ops.
Signed-off-by Daniel Borkmann <[email protected]>
Cc Jiri Pirko <[email protected]>

Acked-by Alexei Starovoitov <[email protected]>

Alexei Starovoitov

Acked-by on v1 2/2

2015-03-20 21:21 UTC #6 lore raw

Re: [PATCH net-next 2/2] act_bpf: add initial eBPF support for actions

In reply to Daniel Borkmann

Quoted 16 lines · Daniel Borkmann

This work extends the "classic" BPF programmable tc action by extending its scope also to native eBPF code!
Together with commit e2e9b6541dd4 ("cls_bpf: add initial eBPF support for programmable classifiers") this adds the facility to implement fully flexible classifier and actions for tc that can be implemented in a C subset in user space, "safely" loaded into the kernel, and being run in native speed when JITed.
Also, since eBPF maps can be shared between eBPF programs, it offers the possibility that cls_bpf and act_bpf can share data 1) between themselves and 2) between user space applications. That means that, f.e. customized runtime statistics can be collected in user space, but also more importantly classifier and action behaviour could be altered based on map input from the user space application.

Quoted 8 lines

For the remaining details on the workflow and integration, see the cls_bpf commit e2e9b6541dd4. Preliminary iproute2 part can be found under [1].
   [1] http://git.breakpoint.cc/cgit/dborkman/iproute2.git/log/?h=ebpf-act
Signed-off-by Daniel Borkmann <[email protected]>
Cc Jamal Hadi Salim <[email protected]>
Cc Jiri Pirko <[email protected]>

Acked-by Alexei Starovoitov <[email protected]>

Alexei Starovoitov

2015-03-20 21:26 UTC #9 lore raw

In reply to Daniel Borkmann

Quoted 27 lines · Daniel Borkmann

Quoted 6 lines
Quoted 6 lines
This set depends on ced585c83b27 ("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"), so a net into net-next merge would be required first. Hope that's fine by you, Dave. ;)
Quoted 6 lines
Quoted 1 line
Thanks a lot!
Even with that commit, which is in net-next now, this series does not apply without rejects.
Please respin.
So my HEAD is at latest net-next commit b4c11cb437fdb34b ("Merge branch 'amd-xgbe-next'"):
   $ git cherry-pick ced585c83b27deca427c606a34dd3eaa6b96d82b
   [ebpf-act 1b8dfa9] act_bpf: allow non-default TC_ACT opcodes as BPF
exec outcome
    1 file changed, 28 insertions(+), 8 deletions(-)
   $ git am 0001-ebpf-add-sched_act_type-and-map-it-to-sk_filter-s-ve.patch
   Applying: ebpf: add sched_act_type and map it to sk_filter's verifier
ops
   $ git am 0002-act_bpf-add-initial-eBPF-support-for-actions.patch
   Applying: act_bpf: add initial eBPF support for actions
   $

Quoted 3 lines

The dependency mentioned in the cover letter is on net commit ced585c83b27 ("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"). On my side that applies fine, hm.

I don't think 'net' has been merged into 'net-next' yet. Or may be merged, but not pushed...

David Miller

maintainer

2015-03-20 22:21 UTC #10 lore raw

In reply to Daniel Borkmann

From: Daniel Borkmann <[email protected]>
Date: Fri, 20 Mar 2015 22:10:36 +0100

Quoted 16 lines

So my HEAD is at latest net-next commit b4c11cb437fdb34b ("Merge branch
'amd-xgbe-next'"):

  $ git cherry-pick ced585c83b27deca427c606a34dd3eaa6b96d82b
  [ebpf-act 1b8dfa9] act_bpf: allow non-default TC_ACT opcodes as BPF
  exec outcome
   1 file changed, 28 insertions(+), 8 deletions(-)
  $ git am
  0001-ebpf-add-sched_act_type-and-map-it-to-sk_filter-s-ve.patch
  Applying: ebpf: add sched_act_type and map it to sk_filter's verifier
  ops
  $ git am 0002-act_bpf-add-initial-eBPF-support-for-actions.patch
  Applying: act_bpf: add initial eBPF support for actions
  $

Quoted 5 lines

The dependency mentioned in the cover letter is on net commit ced585c83b27
("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"). On my
side that applies fine, hm.

Sorry, my bad, I'll sort this out.

Daniel Borkmann

author maintainer

2015-03-20 22:45 UTC #11 lore raw

Quoted 19 lines · David Miller

From: Daniel Borkmann <[email protected]>
Date: Fri, 20 Mar 2015 22:10:36 +0100

Quoted 16 lines

So my HEAD is at latest net-next commit b4c11cb437fdb34b ("Merge branch
'amd-xgbe-next'"):

   $ git cherry-pick ced585c83b27deca427c606a34dd3eaa6b96d82b
   [ebpf-act 1b8dfa9] act_bpf: allow non-default TC_ACT opcodes as BPF
   exec outcome
    1 file changed, 28 insertions(+), 8 deletions(-)
   $ git am
   0001-ebpf-add-sched_act_type-and-map-it-to-sk_filter-s-ve.patch
   Applying: ebpf: add sched_act_type and map it to sk_filter's verifier
   ops
   $ git am 0002-act_bpf-add-initial-eBPF-support-for-actions.patch
   Applying: act_bpf: add initial eBPF support for actions
   $

Quoted 7 lines

Quoted 5 lines
The dependency mentioned in the cover letter is on net commit ced585c83b27
("act_bpf: allow non-default TC_ACT opcodes as BPF exec outcome"). On my
side that applies fine, hm.
Sorry, my bad, I'll sort this out.

Ok, thanks a lot David.