From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B6984A10DA for ; Wed, 31 Jul 2019 09:26:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0529C1BE97; Wed, 31 Jul 2019 09:26:32 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id AB9C81BE7E for ; Wed, 31 Jul 2019 09:26:30 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2019 00:26:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,329,1559545200"; d="scan'208";a="372004552" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga006.fm.intel.com with ESMTP; 31 Jul 2019 00:26:28 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX102.ger.corp.intel.com ([169.254.2.59]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 08:26:27 +0100 From: "Ananyev, Konstantin" To: Thomas Monjalon CC: "dev@dpdk.org" , "olivier.matz@6wind.com" Thread-Topic: [dpdk-stable] [PATCH] examples/bpf: fix compilation issue Thread-Index: AQHVRsBMl0YRp+okoUyFPNallSvlK6bjYP2AgADuQ1A= Date: Wed, 31 Jul 2019 07:26:26 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580168A5FDA7@irsmsx105.ger.corp.intel.com> References: <20190730101927.1665-1-konstantin.ananyev@intel.com> <10104652.MOWmfaWtsW@xps> In-Reply-To: <10104652.MOWmfaWtsW@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGJkYTU4YTAtYTVkNy00NGZlLWIwNGItOWZjZTYwNDkxODRiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZFc1ZHp2TGZnaXJOTlhLTUhwQW5xQmdzNGR2UHp3bmVvVVNzcTl0bG1qbk9zS2lhZFlVTUl1cXp3XC85V29XN1MifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] examples/bpf: fix compilation issue 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Tuesday, July 30, 2019 6:53 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org; olivier.matz@6wind.com > Subject: Re: [dpdk-stable] [PATCH] examples/bpf: fix compilation issue >=20 > 30/07/2019 12:19, Konstantin Ananyev: > > Example BPF programs t1.c, t2.c, t3.c in folder examples/bpf are > > failing to compile with latest dpdk.org master. > > The reason is changes in some core DPDK header files, that causes > > now inclusion of x86 specific headers. > > To overcome the issue, minimize inclusion of DPDK header files > > into BPF source code. > > > > Bugzilla ID: 321 > > > > Fixes: 9dfc06c26a8b ("test/bpf: add samples") > > Cc: stable@dpdk.org > > > > Reported-by: Michel Machado > > Suggested-by: Michel Machado > > Signed-off-by: Konstantin Ananyev > > --- > > examples/bpf/mbuf.h | 24 ++++++++++++++++++++++-- > > 1 file changed, 22 insertions(+), 2 deletions(-) >=20 > I think that's really a bad idea to have this file. > The BPF applications are supposed to update their own copy of mbuf? Right now, yes (same as KNI). > Please could you try to include rte_mbuf.h > instead of duplicating the mbuf layout? I don't think it is possible without some rework on rte_mbuf.h itself. I thought about that, but for that we'll probably need to put just=20 struct rte_mbuf definition into a separate file (rte_mbuf_core.h or so)=09 and might be some related definitions into rte_common.h or so. Then re_mbuf.h will include rte_mbuf_core.h while bpf (and might be KNI?) can include just rte_mbuf_core.h without any extra arch specific headers. Another alternative probably to define bpf as a separate arch (though don't know how big effort it will be). I planned to try something like that, but then totally forgot. And now it is too late, we are at RC4 already .=20 Konstantin