From: Yonghong Song <yhs@fb.com>
To: Hangbin Liu <liuhangbin@gmail.com>, <bpf@vger.kernel.org>
Cc: netdev@vger.kernel.org, "Daniel Borkmann" <daniel@iogearbox.net>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
"John Fastabend" <john.fastabend@gmail.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>
Subject: Re: [PATCHv6 bpf-next] samples/bpf: add xdp program on egress for xdp_redirect_map
Date: Thu, 14 Jan 2021 13:01:28 -0800 [thread overview]
Message-ID: <4d9b5846-bd08-09b4-53a2-3cb02a9a1eee@fb.com> (raw)
In-Reply-To: <20210114142732.2595651-1-liuhangbin@gmail.com>
On 1/14/21 6:27 AM, Hangbin Liu wrote:
> This patch add a xdp program on egress to show that we can modify
> the packet on egress. In this sample we will set the pkt's src
> mac to egress's mac address. The xdp_prog will be attached when
> -X option supplied.
>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>
> ---
> v6: no code update, only rebase the code on latest bpf-next
>
> v5:
> a) close fd when err out in get_mac_addr()
> b) exit program when both -S and -X supplied.
>
> v4:
> a) Update get_mac_addr socket create
> b) Load dummy prog regardless of 2nd xdp prog on egress
>
> v3:
> a) modify the src mac address based on egress mac
>
> v2:
> a) use pkt counter instead of IP ttl modification on egress program
> b) make the egress program selectable by option -X
> ---
> samples/bpf/xdp_redirect_map_kern.c | 75 ++++++++++++++--
> samples/bpf/xdp_redirect_map_user.c | 135 +++++++++++++++++++++++-----
> 2 files changed, 184 insertions(+), 26 deletions(-)
>
> diff --git a/samples/bpf/xdp_redirect_map_kern.c b/samples/bpf/xdp_redirect_map_kern.c
> index 6489352ab7a4..8b8e73d25ad6 100644
> --- a/samples/bpf/xdp_redirect_map_kern.c
> +++ b/samples/bpf/xdp_redirect_map_kern.c
> @@ -19,12 +19,22 @@
> #include <linux/ipv6.h>
> #include <bpf/bpf_helpers.h>
>
> +/* The 2nd xdp prog on egress does not support skb mode, so we define two
> + * maps, tx_port_general and tx_port_native.
> + */
> struct {
> __uint(type, BPF_MAP_TYPE_DEVMAP);
> __uint(key_size, sizeof(int));
> __uint(value_size, sizeof(int));
> __uint(max_entries, 100);
> -} tx_port SEC(".maps");
> +} tx_port_general SEC(".maps");
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_DEVMAP);
> + __uint(key_size, sizeof(int));
> + __uint(value_size, sizeof(struct bpf_devmap_val));
> + __uint(max_entries, 100);
> +} tx_port_native SEC(".maps");
>
> /* Count RX packets, as XDP bpf_prog doesn't get direct TX-success
> * feedback. Redirect TX errors can be caught via a tracepoint.
> @@ -36,6 +46,14 @@ struct {
> __uint(max_entries, 1);
> } rxcnt SEC(".maps");
>
> +/* map to stroe egress interface mac address */
s/stroe/store
> +struct {
> + __uint(type, BPF_MAP_TYPE_ARRAY);
> + __type(key, u32);
> + __type(value, __be64);
> + __uint(max_entries, 1);
> +} tx_mac SEC(".maps");
> +
> static void swap_src_dst_mac(void *data)
> {
> unsigned short *p = data;
> @@ -52,17 +70,16 @@ static void swap_src_dst_mac(void *data)
> p[5] = dst[2];
> }
>
[...]
> int main(int argc, char **argv)
> {
> struct bpf_prog_load_attr prog_load_attr = {
> - .prog_type = BPF_PROG_TYPE_XDP,
> + .prog_type = BPF_PROG_TYPE_UNSPEC,
> };
> - struct bpf_program *prog, *dummy_prog;
> + struct bpf_program *prog, *dummy_prog, *devmap_prog;
> + int devmap_prog_fd_0 = -1, devmap_prog_fd_1 = -1;
The default value is -1 here. I remembered there was a discussion
about the default value here, does default value 0 work here?
> + int prog_fd, dummy_prog_fd;
> + int tx_port_map_fd, tx_mac_map_fd;
> + struct bpf_devmap_val devmap_val;
> struct bpf_prog_info info = {};
> __u32 info_len = sizeof(info);
> - int prog_fd, dummy_prog_fd;
> - const char *optstr = "FSN";
> + const char *optstr = "FSNX";
> struct bpf_object *obj;
> int ret, opt, key = 0;
> char filename[256];
> - int tx_port_map_fd;
>
> while ((opt = getopt(argc, argv, optstr)) != -1) {
> switch (opt) {
> @@ -120,14 +154,21 @@ int main(int argc, char **argv)
> case 'F':
> xdp_flags &= ~XDP_FLAGS_UPDATE_IF_NOEXIST;
> break;
> + case 'X':
> + xdp_devmap_attached = true;
> + break;
> default:
> usage(basename(argv[0]));
> return 1;
> }
> }
>
> - if (!(xdp_flags & XDP_FLAGS_SKB_MODE))
> + if (!(xdp_flags & XDP_FLAGS_SKB_MODE)) {
> xdp_flags |= XDP_FLAGS_DRV_MODE;
> + } else if (xdp_devmap_attached) {
> + printf("Load xdp program on egress with SKB mode not supported yet\n");
> + return 1;
> + }
>
> if (optind == argc) {
> printf("usage: %s <IFNAME|IFINDEX>_IN <IFNAME|IFINDEX>_OUT\n", argv[0]);
> @@ -150,24 +191,28 @@ int main(int argc, char **argv)
> if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd))
> return 1;
>
> - prog = bpf_program__next(NULL, obj);
> - dummy_prog = bpf_program__next(prog, obj);
> - if (!prog || !dummy_prog) {
> - printf("finding a prog in obj file failed\n");
> - return 1;
> + if (xdp_flags & XDP_FLAGS_SKB_MODE) {
> + prog = bpf_object__find_program_by_title(obj, "xdp_redirect_general");
libbpf supports each section having multiple programs, so
bpf_object__find_program_by_title() is not recommended.
Could you change to bpf_object__find_program_by_name()?
> + tx_port_map_fd = bpf_object__find_map_fd_by_name(obj, "tx_port_general");
> + } else {
> + prog = bpf_object__find_program_by_title(obj, "xdp_redirect_native");
> + tx_port_map_fd = bpf_object__find_map_fd_by_name(obj, "tx_port_native");
> + }
> + dummy_prog = bpf_object__find_program_by_title(obj, "xdp_redirect_dummy");
> + if (!prog || dummy_prog < 0 || tx_port_map_fd < 0) {
> + printf("finding prog/tx_port_map in obj file failed\n");
> + goto out;
> }
> - /* bpf_prog_load_xattr gives us the pointer to first prog's fd,
> - * so we're missing only the fd for dummy prog
> - */
> + prog_fd = bpf_program__fd(prog);
> dummy_prog_fd = bpf_program__fd(dummy_prog);
> - if (prog_fd < 0 || dummy_prog_fd < 0) {
> + if (prog_fd < 0 || dummy_prog_fd < 0 || tx_port_map_fd < 0) {
> printf("bpf_prog_load_xattr: %s\n", strerror(errno));
> return 1;
> }
>
> - tx_port_map_fd = bpf_object__find_map_fd_by_name(obj, "tx_port");
> + tx_mac_map_fd = bpf_object__find_map_fd_by_name(obj, "tx_mac");
> rxcnt_map_fd = bpf_object__find_map_fd_by_name(obj, "rxcnt");
> - if (tx_port_map_fd < 0 || rxcnt_map_fd < 0) {
> + if (tx_mac_map_fd < 0 || rxcnt_map_fd < 0) {
> printf("bpf_object__find_map_fd_by_name failed\n");
> return 1;
> }
[...]
next prev parent reply other threads:[~2021-01-14 21:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 12:46 [PATCH bpf-next] samples/bpf: add xdp_redirect_map with xdp_prog support Hangbin Liu
2020-11-10 14:25 ` Jesper Dangaard Brouer
2020-11-10 15:24 ` Maciej Fijalkowski
2020-11-11 1:12 ` Hangbin Liu
2020-11-26 8:43 ` [PATCHv2 bpf-next] samples/bpf: add xdp program on egress for xdp_redirect_map Hangbin Liu
2020-11-26 10:51 ` Jesper Dangaard Brouer
2020-11-26 14:19 ` Hangbin Liu
2020-11-27 6:31 ` Yonghong Song
2020-11-30 7:51 ` Hangbin Liu
2020-11-30 9:32 ` Jesper Dangaard Brouer
2020-11-30 13:10 ` Hangbin Liu
2020-11-30 15:12 ` Jesper Dangaard Brouer
2020-11-30 16:07 ` Toke Høiland-Jørgensen
2020-12-08 8:18 ` [PATCHv3 " Hangbin Liu
2020-12-08 10:39 ` Jesper Dangaard Brouer
2020-12-08 11:11 ` Hangbin Liu
2020-12-08 12:01 ` [PATCHv4 " Hangbin Liu
2020-12-11 0:15 ` Daniel Borkmann
2020-12-11 2:40 ` [PATCHv5 " Hangbin Liu
2021-01-14 14:27 ` [PATCHv6 " Hangbin Liu
2021-01-14 21:01 ` Yonghong Song [this message]
2021-01-15 4:17 ` Hangbin Liu
2021-01-15 6:24 ` [PATCHv7 " Hangbin Liu
2021-01-15 16:57 ` Yonghong Song
2021-01-18 22:46 ` Daniel Borkmann
2021-01-19 3:12 ` [PATCHv8 " Hangbin Liu
2021-01-19 14:51 ` Jesper Dangaard Brouer
2021-01-20 4:16 ` Hangbin Liu
2021-01-21 13:06 ` [PATCHv9 " Hangbin Liu
2021-01-21 15:05 ` Jesper Dangaard Brouer
2021-01-22 2:50 ` [PATCHv10 " Hangbin Liu
2021-01-22 10:32 ` Jesper Dangaard Brouer
2021-01-22 23:30 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d9b5846-bd08-09b4-53a2-3cb02a9a1eee@fb.com \
--to=yhs@fb.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).