From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by dpdk.org (Postfix) with ESMTP id 81F685F22
for <dev@dpdk.org>; Tue, 13 Mar 2018 18:24:45 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga008.fm.intel.com ([10.253.24.58])
by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
13 Mar 2018 10:24:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.47,465,1515484800"; d="scan'208";a="24181849"
Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155])
by fmsmga008.fm.intel.com with ESMTP; 13 Mar 2018 10:24:42 -0700
Received: from irsmsx105.ger.corp.intel.com ([169.254.7.221]) by
IRSMSX102.ger.corp.intel.com ([169.254.2.10]) with mapi id 14.03.0319.002;
Tue, 13 Mar 2018 17:24:41 +0000
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
CC: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH v1 0/5] add framework to load and execute
BPF code
Thread-Index: AQHTt8W2+yJ/L3MNsE+9zyb6KeSlIqPOJ5iAgABHqOA=
Date: Tue, 13 Mar 2018 17:24:40 +0000
Message-ID: <2601191342CEEE43887BDE71AB9772589E28F501@irsmsx105.ger.corp.intel.com>
References: <1520613725-9176-1-git-send-email-konstantin.ananyev@intel.com>
<20180313130240.GA31588@jerin>
In-Reply-To: <20180313130240.GA31588@jerin>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjQ5NmQwN2UtMjU4Yy00NDk3LTljZTMtZWVhMjVjNDJlZDI0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkxcL055dERiYWJqMmN4cEdlYzVXUnpIMm44bHVGWmdjaXJJRXRma3ZMSTRJPSJ9
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] [PATCH v1 0/5] add framework to load and execute BPF
code
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2018 17:24:46 -0000
Hi Jerin,
>=20
> Hi Konstantin,
>=20
> >
> > BPF is used quite intensively inside Linux (and BSD) kernels
> > for various different purposes and proved to be extremely useful.
> >
> > BPF inside DPDK might also be used in a lot of places
> > for a lot of similar things.
> > As an example to:
> > - packet filtering/tracing (aka tcpdump)
> > - packet classification
> > - statistics collection
> > - HW/PMD live-system debugging/prototyping - trace HW descriptors,
> > internal PMD SW state, etc.
> > ...
> >
> > All of that in a dynamic, user-defined and extensible manner.
> >
> > So these series introduce new library - librte_bpf.
> > librte_bpf provides API to load and execute BPF bytecode within
> > user-space dpdk app.
> > It supports basic set of features from eBPF spec.
> > Also it introduces basic framework to load/unload BPF-based filters
> > on eth devices (right now via SW RX/TX callbacks).
>=20
> It is an interesting feature.
> I am yet to catch up on your implementation details.
> Meanwhile, I have tried to run non JIT version on arm64.
> I had some compilation issue with 4.9 kernel with gcc 5.3 toolchain.
> Following patch fixes that.
>=20
> Just wondering what we will do with FreeBSD, May it better to
> kill the dependency of linux/filter.h and different kernel versions
> by making bpf_impl.h self sufficient. Just a thought.
Good point, have pretty much same thought:
we already have some rudimentary bpf-related include:
drivers/net/tap/tap_bpf.h
which is uder dual(bsd and gpl) license.
Might be we can move it to lib/librte_net/bpf (or so)
and extend to contain all necessary bpf related stuff.
Then could be used by both TAP PMD and librte_bpf
and might be something else in future.
Konstantin
>=20
> diff --git a/lib/librte_bpf/bpf_impl.h b/lib/librte_bpf/bpf_impl.h
> index f094170..e500e26 100644
> --- a/lib/librte_bpf/bpf_impl.h
> +++ b/lib/librte_bpf/bpf_impl.h
> @@ -13,6 +13,26 @@
> extern "C" {
> #endif
>=20
> +#ifndef BPF_JLT
> +#define BPF_JLT 0xa0 /* LT is unsigned, '<' */
> +#endif
> +
> +#ifndef BPF_JLE
> +#define BPF_JLE 0xb0 /* LE is unsigned, '<=3D' */
> +#endif
> +
> +#ifndef BPF_JSLT
> +#define BPF_JSLT 0xc0 /* SLT is signed, '<' */
> +#endif
> +
> +#ifndef BPF_JSLE
> +#define BPF_JSLE 0xd0 /* SLE is signed, '<=3D' */
> +#endif
> +
> +#ifndef EM_BPF
> +#define EM_BPF 247 /* Linux BPF - in-kernel virtual machine
> */
> +#endif
> +