DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples
Date: Tue, 13 Mar 2018 18:14:06 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772589E28F57F@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <20180313140155.GC564@jerin>



> >
> > 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.

That would be ideal.
I made a snippet just to avoid compiler errors for bpf target.
Will try to address it in next version.

> 
> > 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?

Yes, will do.

> 
> > + * -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?

Makes sense, will update in v2.
Konstantin

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

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08  1:29 [dpdk-dev] [RFC PATCH 0/5] add framework to load and execute BPF code Konstantin Ananyev
2018-03-08  1:29 ` [dpdk-dev] [RFC PATCH 1/5] bpf: add BPF loading and execution framework Konstantin Ananyev
2018-03-08  1:29 ` [dpdk-dev] [RFC PATCH 2/5] bpf: add JIT compilation for x86_64 ISA Konstantin Ananyev
2018-03-08  1:30 ` [dpdk-dev] [RFC PATCH 3/5] bpf: introduce basic RX/TX BPF filters Konstantin Ananyev
2018-03-08  1:30 ` [dpdk-dev] [RFC PATCH 4/5] testpmd: new commands to load/unload " Konstantin Ananyev
2018-03-08  1:30 ` [dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples Konstantin Ananyev
2018-03-13 14:01   ` Jerin Jacob
2018-03-13 18:14     ` Ananyev, Konstantin [this message]
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=2601191342CEEE43887BDE71AB9772589E28F57F@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.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).