From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id C70154D27 for ; Tue, 13 Mar 2018 19:14:10 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2018 11:14:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,466,1515484800"; d="scan'208";a="37876851" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by fmsmga001.fm.intel.com with ESMTP; 13 Mar 2018 11:14:08 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX109.ger.corp.intel.com (163.33.3.23) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 13 Mar 2018 18:14:07 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.221]) by irsmsx112.ger.corp.intel.com ([169.254.1.242]) with mapi id 14.03.0319.002; Tue, 13 Mar 2018 18:14:07 +0000 From: "Ananyev, Konstantin" To: Jerin Jacob CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples Thread-Index: AQHTtn1It00ZaBqkW0GLUm3bRLBo1qPOOrYAgABEv4A= Date: Tue, 13 Mar 2018 18:14:06 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772589E28F57F@irsmsx105.ger.corp.intel.com> References: <1520472602-1483-1-git-send-email-konstantin.ananyev@intel.com> <1520472602-1483-6-git-send-email-konstantin.ananyev@intel.com> <20180313140155.GC564@jerin> In-Reply-To: <20180313140155.GC564@jerin> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTk0ODYzZWQtOWM3Ny00ZWExLTllN2EtYjhhNzRlMTU1MmJjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFHaEtYd1NRa1dueitDTUwzMFNsQ280bXJ2TnQ2QjUwNUxVbk1VWGJCUkk9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 5/5] test: add few eBPF samples X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 18:14:11 -0000 > > > > Add few simple eBPF programs as an example. > > > > Signed-off-by: Konstantin Ananyev > > 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 > > +#include > > +#include >=20 > 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. >=20 > > 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=3D64 -I${RTE_SDK}/${RTE_TARGET}/inc= lude \ >=20 > Does not look like, this application is accessing any DPDK stuff, If so, > Should we remove -DRTE_CACHE_LINE_SIZE=3D64 -I${RTE_SDK}/${RTE_TARGET}/in= clude? Yes, will do. >=20 > > + * -target bpf -c t1.c > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +uint64_t > > +entry(void *pkt) > > +{ > > + struct ether_header *ether_header =3D (void *)pkt; > > + > > + if (ether_header->ether_type !=3D __builtin_bswap16(0x0800)) > > + return 0; > > + > > + struct iphdr *iphdr =3D (void *)(ether_header + 1); > > + if (iphdr->protocol !=3D 17 || (iphdr->frag_off & 0x1ffff) !=3D 0 || > > + iphdr->daddr !=3D __builtin_bswap32(0x1020304)) > > + return 0; > > + > > + int hlen =3D iphdr->ihl * 4; > > + struct udphdr *udphdr =3D (void *)iphdr + hlen; > > + > > + if (udphdr->dest !=3D __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=3D... -I${RTE_SDK}/${RTE_TARGET}/in= clude \ > > + * -target bpf -Wno-int-to-void-pointer-cast -c t2.c > > + */ > > + > > +#include > > +#include > > +#include "mbuf.h" >=20 > 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