2017-11-25 04:21:35 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2004-08-24 04:21:21 +08:00
|
|
|
|
|
|
|
|
#define TCA_BUF_MAX (64*1024)
|
2018-01-12 13:13:16 +08:00
|
|
|
#define MSG_IOV_MAX 128
|
2004-08-24 04:21:21 +08:00
|
|
|
|
2005-03-15 03:34:12 +08:00
|
|
|
extern struct rtnl_handle rth;
|
tc: built-in eBPF exec proxy
This work follows upon commit 6256f8c9e45f ("tc, bpf: finalize eBPF
support for cls and act front-end") and takes up the idea proposed by
Hannes Frederic Sowa to spawn a shell (or any other command) that holds
generated eBPF map file descriptors.
File descriptors, based on their id, are being fetched from the same
unix domain socket as demonstrated in the bpf_agent, the shell spawned
via execvpe(2) and the map fds passed over the environment, and thus
are made available to applications in the fashion of std{in,out,err}
for read/write access, for example in case of iproute2's examples/bpf/:
# env | grep BPF
BPF_NUM_MAPS=3
BPF_MAP1=6 <- BPF_MAP_ID_QUEUE (id 1)
BPF_MAP0=5 <- BPF_MAP_ID_PROTO (id 0)
BPF_MAP2=7 <- BPF_MAP_ID_DROPS (id 2)
# ls -la /proc/self/fd
[...]
lrwx------. 1 root root 64 Apr 14 16:46 0 -> /dev/pts/4
lrwx------. 1 root root 64 Apr 14 16:46 1 -> /dev/pts/4
lrwx------. 1 root root 64 Apr 14 16:46 2 -> /dev/pts/4
[...]
lrwx------. 1 root root 64 Apr 14 16:46 5 -> anon_inode:bpf-map
lrwx------. 1 root root 64 Apr 14 16:46 6 -> anon_inode:bpf-map
lrwx------. 1 root root 64 Apr 14 16:46 7 -> anon_inode:bpf-map
The advantage (as opposed to the direct/native usage) is that now the
shell is map fd owner and applications can terminate and easily reattach
to descriptors w/o any kernel changes. Moreover, multiple applications
can easily read/write eBPF maps simultaneously.
To further allow users for experimenting with that, next step is to add
a small helper that can get along with simple data types, so that also
shell scripts can make use of bpf syscall, f.e to read/write into maps.
Generally, this allows for prepopulating maps, or any runtime altering
which could influence eBPF program behaviour (f.e. different run-time
classifications, skb modifications, ...), dumping of statistics, etc.
Reference: http://thread.gmane.org/gmane.linux.network/357471/focus=357860
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
2015-04-17 03:20:06 +08:00
|
|
|
|
2018-08-21 07:01:31 +08:00
|
|
|
int do_qdisc(int argc, char **argv);
|
|
|
|
|
int do_class(int argc, char **argv);
|
|
|
|
|
int do_filter(int argc, char **argv, void *buf, size_t buflen);
|
|
|
|
|
int do_chain(int argc, char **argv, void *buf, size_t buflen);
|
|
|
|
|
int do_action(int argc, char **argv, void *buf, size_t buflen);
|
|
|
|
|
int do_tcmonitor(int argc, char **argv);
|
|
|
|
|
int do_exec(int argc, char **argv);
|
tc: built-in eBPF exec proxy
This work follows upon commit 6256f8c9e45f ("tc, bpf: finalize eBPF
support for cls and act front-end") and takes up the idea proposed by
Hannes Frederic Sowa to spawn a shell (or any other command) that holds
generated eBPF map file descriptors.
File descriptors, based on their id, are being fetched from the same
unix domain socket as demonstrated in the bpf_agent, the shell spawned
via execvpe(2) and the map fds passed over the environment, and thus
are made available to applications in the fashion of std{in,out,err}
for read/write access, for example in case of iproute2's examples/bpf/:
# env | grep BPF
BPF_NUM_MAPS=3
BPF_MAP1=6 <- BPF_MAP_ID_QUEUE (id 1)
BPF_MAP0=5 <- BPF_MAP_ID_PROTO (id 0)
BPF_MAP2=7 <- BPF_MAP_ID_DROPS (id 2)
# ls -la /proc/self/fd
[...]
lrwx------. 1 root root 64 Apr 14 16:46 0 -> /dev/pts/4
lrwx------. 1 root root 64 Apr 14 16:46 1 -> /dev/pts/4
lrwx------. 1 root root 64 Apr 14 16:46 2 -> /dev/pts/4
[...]
lrwx------. 1 root root 64 Apr 14 16:46 5 -> anon_inode:bpf-map
lrwx------. 1 root root 64 Apr 14 16:46 6 -> anon_inode:bpf-map
lrwx------. 1 root root 64 Apr 14 16:46 7 -> anon_inode:bpf-map
The advantage (as opposed to the direct/native usage) is that now the
shell is map fd owner and applications can terminate and easily reattach
to descriptors w/o any kernel changes. Moreover, multiple applications
can easily read/write eBPF maps simultaneously.
To further allow users for experimenting with that, next step is to add
a small helper that can get along with simple data types, so that also
shell scripts can make use of bpf syscall, f.e to read/write into maps.
Generally, this allows for prepopulating maps, or any runtime altering
which could influence eBPF program behaviour (f.e. different run-time
classifications, skb modifications, ...), dumping of statistics, etc.
Reference: http://thread.gmane.org/gmane.linux.network/357471/focus=357860
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
2015-04-17 03:20:06 +08:00
|
|
|
|
2018-10-20 04:42:36 +08:00
|
|
|
int print_action(struct nlmsghdr *n, void *arg);
|
|
|
|
|
int print_filter(struct nlmsghdr *n, void *arg);
|
|
|
|
|
int print_qdisc(struct nlmsghdr *n, void *arg);
|
|
|
|
|
int print_class(struct nlmsghdr *n, void *arg);
|
2018-08-21 07:01:31 +08:00
|
|
|
void print_size_table(FILE *fp, const char *prefix, struct rtattr *rta);
|
2004-04-16 04:56:59 +08:00
|
|
|
|
2005-03-15 06:19:16 +08:00
|
|
|
struct tc_estimator;
|
2018-08-21 07:01:31 +08:00
|
|
|
int parse_estimator(int *p_argc, char ***p_argv, struct tc_estimator *est);
|
2008-07-25 21:19:09 +08:00
|
|
|
|
|
|
|
|
struct tc_sizespec;
|
2018-08-21 07:01:31 +08:00
|
|
|
int parse_size_table(int *p_argc, char ***p_argv, struct tc_sizespec *s);
|
|
|
|
|
int check_size_table_opts(struct tc_sizespec *s);
|
2014-12-26 08:10:06 +08:00
|
|
|
|
|
|
|
|
extern int show_graph;
|
2015-03-04 00:41:18 +08:00
|
|
|
extern bool use_names;
|
