All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Konstantin Ananyev <konstantin.ananyev@intel.com>
Cc: dev@dpdk.org
Subject: Re: [RFC PATCH 5/5] test: add few eBPF samples
Date: Tue, 13 Mar 2018 19:31:56 +0530	[thread overview]
Message-ID: <20180313140155.GC564@jerin> (raw)
In-Reply-To: <1520472602-1483-6-git-send-email-konstantin.ananyev@intel.com>

-----Original Message-----
> Date: Thu, 8 Mar 2018 01:30:02 +0000
> From: Konstantin Ananyev <konstantin.ananyev@intel.com>
> To: dev@dpdk.org
> CC: Konstantin Ananyev <konstantin.ananyev@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@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
> 

  reply	other threads:[~2018-03-13 14:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08  1:29 [RFC PATCH 0/5] add framework to load and execute BPF code Konstantin Ananyev
2018-03-08  1:29 ` [RFC PATCH 1/5] bpf: add BPF loading and execution framework Konstantin Ananyev
2018-03-08  1:29 ` [RFC PATCH 2/5] bpf: add JIT compilation for x86_64 ISA Konstantin Ananyev
2018-03-08  1:30 ` [RFC PATCH 3/5] bpf: introduce basic RX/TX BPF filters Konstantin Ananyev
2018-03-08  1:30 ` [RFC PATCH 4/5] testpmd: new commands to load/unload " Konstantin Ananyev
2018-03-08  1:30 ` [RFC PATCH 5/5] test: add few eBPF samples Konstantin Ananyev
2018-03-13 14:01   ` Jerin Jacob [this message]
2018-03-13 18:14     ` Ananyev, Konstantin
2018-03-30 17:42       ` Ananyev, Konstantin
2018-04-02 22:26         ` Jerin Jacob

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=20180313140155.GC564@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.