[dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples
Jerin Jacob
jerin.jacob at caviumnetworks.com
Tue Mar 13 15:01:56 CET 2018
-----Original Message-----
> Date: Thu, 8 Mar 2018 01:30:02 +0000
> From: Konstantin Ananyev <konstantin.ananyev at intel.com>
> To: dev at dpdk.org
> CC: Konstantin Ananyev <konstantin.ananyev at intel.com>
> Subject: [dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples
> X-Mailer: git-send-email 1.7.0.7
>
> Add few simple eBPF programs as an example.
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
> diff --git a/test/bpf/mbuf.h b/test/bpf/mbuf.h
> new file mode 100644
> index 000000000..aeef6339d
> --- /dev/null
> +++ b/test/bpf/mbuf.h
> @@ -0,0 +1,556 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2010-2014 Intel Corporation.
> + * Copyright 2014 6WIND S.A.
> + */
> +
> +/*
> + * Snipper from dpdk.org rte_mbuf.h.
> + * used to provide BPF programs information about rte_mbuf layout.
> + */
> +
> +#ifndef _MBUF_H_
> +#define _MBUF_H_
> +
> +#include <stdint.h>
> +#include <rte_common.h>
> +#include <rte_memory.h>
Is it worth to keep an copy of mbuf for standalone purpose?
Since clang is already supported, I think, if someone need mbuf then
they can include DPDK headers. Just thinking in maintainability
perspective.
> diff --git a/test/bpf/t1.c b/test/bpf/t1.c
> new file mode 100644
> index 000000000..e587d5e5b
> --- /dev/null
> +++ b/test/bpf/t1.c
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2018 Intel Corporation
> + */
> +
> +/*
> + * eBPF program sample.
> + * Accepts pointer to first segment packet data as an input parameter.
> + * analog of tcpdump -s 1 -d 'dst 1.2.3.4 && udp && dst port 5000'
> + * (000) ldh [12]
> + * (001) jeq #0x800 jt 2 jf 12
> + * (002) ld [30]
> + * (003) jeq #0x1020304 jt 4 jf 12
> + * (004) ldb [23]
> + * (005) jeq #0x11 jt 6 jf 12
> + * (006) ldh [20]
> + * (007) jset #0x1fff jt 12 jf 8
> + * (008) ldxb 4*([14]&0xf)
> + * (009) ldh [x + 16]
> + * (010) jeq #0x1388 jt 11 jf 12
> + * (011) ret #1
> + * (012) ret #0
> + *
> + * To compile:
> + * clang -O2 -DRTE_CACHE_LINE_SIZE=64 -I${RTE_SDK}/${RTE_TARGET}/include \
Does not look like, this application is accessing any DPDK stuff, If so,
Should we remove -DRTE_CACHE_LINE_SIZE=64 -I${RTE_SDK}/${RTE_TARGET}/include?
> + * -target bpf -c t1.c
> + */
> +
> +#include <stdint.h>
> +#include <net/ethernet.h>
> +#include <netinet/ip.h>
> +#include <netinet/udp.h>
> +
> +uint64_t
> +entry(void *pkt)
> +{
> + struct ether_header *ether_header = (void *)pkt;
> +
> + if (ether_header->ether_type != __builtin_bswap16(0x0800))
> + return 0;
> +
> + struct iphdr *iphdr = (void *)(ether_header + 1);
> + if (iphdr->protocol != 17 || (iphdr->frag_off & 0x1ffff) != 0 ||
> + iphdr->daddr != __builtin_bswap32(0x1020304))
> + return 0;
> +
> + int hlen = iphdr->ihl * 4;
> + struct udphdr *udphdr = (void *)iphdr + hlen;
> +
> + if (udphdr->dest != __builtin_bswap16(5000))
> + return 0;
> +
> + return 1;
> +}
> +
> diff --git a/test/bpf/t2.c b/test/bpf/t2.c
> new file mode 100644
> index 000000000..6228609c5
> --- /dev/null
> +++ b/test/bpf/t2.c
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2018 Intel Corporation
> + */
> +
> +/*
> + * eBPF program sample.
> + * Accepts pointer to struct rte_mbuf as an input parameter.
> + * cleanup mbuf's vlan_tci and all related RX flags
> + * (PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED).
> + * Doesn't touch contents of packet data.
> + * To compile:
> + * clang -O2 -DRTE_CACHE_LINE_SIZE=... -I${RTE_SDK}/${RTE_TARGET}/include \
> + * -target bpf -Wno-int-to-void-pointer-cast -c t2.c
> + */
> +
> +#include <stdint.h>
> +#include <stddef.h>
> +#include "mbuf.h"
Can we take Cache line size from rte_config.h which anyway included in
mbuf.h through rte_memory.h?
> +
> +uint64_t
> +entry(void *pkt)
> +{
> + struct rte_mbuf *mb;
> +
> + mb = pkt;
> + mb->vlan_tci = 0;
> + mb->ol_flags &= ~(PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED);
> +
> + return 1;
> +}
> +
> --
> 2.13.6
>
More information about the dev
mailing list