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 BCB62A2EEB for ; Mon, 7 Oct 2019 20:05:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9C9721C0D3; Mon, 7 Oct 2019 20:05:02 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 401FE1C0D0 for ; Mon, 7 Oct 2019 20:05:01 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 72BDD21CC3; Mon, 7 Oct 2019 14:05:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 07 Oct 2019 14:05:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=KeNxrcSQ+/pJ4F96bbDQjbgSLIeM8HY6ww78WTnqZQA=; b=l9rQ7qqFYvJv JlfNf8HneiZTw5fUdpNV+E6ZGoyMWj0ks8qEXjTtQ53QdFh4hk4TOaLBfLVdGoRR s3tCbX29I31gPg6YOB5nQdx1JxsSLuG65BNT7mpoimnDGCHpjQNDtScwOxb/pGid QUNehTqU8vol9PQAqGWLMzyIl6vTYJs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=KeNxrcSQ+/pJ4F96bbDQjbgSLIeM8HY6ww78WTnqZ QA=; b=j9kfrKJATJm6hN8Pe3VMV3rzpngeLPVsTpVwAKiOu2bSeYaACkL+NJAns D4hOpgcBcIJymIiU04aoBbmK5ApjjFvJ7eQIbsbUyQrO4sEhyJTEQVBGsJlZAQLj eD48Sfe+aS3adJkSrqCbXPf8JgBn+X6JpDmyY0uNgSwkMMODaHTmXzbm+c9WNcHs c/gJocnaKodXT6Otf3CECT6Vzb167G/9WYaxFhHRS3a28jlpv0kK+QJI5w299rPJ 2VxNTJm1flZdJ0T2j8JJ2k2YN3rNHWDjmIxlNV4I+HhhLBFazJV2rzBVe2G6y9T8 r/qOPanR/POVw8NTTHd6UoOI82iLA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheejgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhenucfkphepjeejrddufeegrddvtdefrddukeeg necurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvg htnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A5DAFD6005B; Mon, 7 Oct 2019 14:04:58 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: "Ananyev, Konstantin" , Jerin Jacob , dpdk-dev , Honnappa Nagarahalli , Gavin Hu Date: Mon, 07 Oct 2019 20:04:57 +0200 Message-ID: <2692726.gUGBZ5dN0q@xps> In-Reply-To: References: <20190903105938.33231-1-jerinj@marvell.com> <4310069.WdzTAdBlsv@xps> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support 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" 07/10/2019 15:00, Jerin Jacob: > On Mon, 7 Oct, 2019, 6:03 PM Thomas Monjalon wrote: > > 04/10/2019 17:39, Jerin Jacob: > > > On Thu, Oct 3, 2019 at 8:35 PM Ananyev, Konstantin wrote: > > > > > On Thu, Oct 3, 2019 at 6:21 PM Thomas Monjalon wrote: > > > > > > 03/09/2019 12:59, jerinj@marvell.com: > > > > > > > Added eBPF arm64 JIT support to improve the eBPF > > > > > > > program performance on arm64. > > > > > > > > > > > > > > lib/librte_bpf/bpf_jit_arm64.c > > > > > > > | 1451 ++++++++++++++++++++++++ > > > > > > > > > > > > I am concerned about duplicating the BPF JIT effort in DPDK and= Linux. > > > > > > Could we try to pull the Linux JIT? > > > > > > Is the license the only issue? > > > > > > > > > > That's one issue. > > > > > > > > > > > After a quick discussion, it seems the Linux authors are OK to > > > > > > arrange their JIT code for sharing with userspace projects. > > > > > > > > > > I did a clean room implementation considering some optimization f= or > > > > > DPDK etc(Like if stack is not used then don't push stack etc) > > > > > and wherever Linux can be improved, I have submitted the patch al= so > > > > > to Linux as well.(Some more pending as well) > > > > > https://github.com/torvalds/linux/commit/504792e07a44844f24e9d799= 13e4a2f8373cd332 > > > > > > > > > > And Linux has a framework for instruction generation for debugging > > > > > etc. So We can not copy and paste the code from Linux as is. > > > > > > > > > > My view to keep a different code base optimize for DPDK use cases= and > > > > > library requirements(for example, tail call is not supported in D= PDK). > > > > > For arm64/x86 case the code is done so it is not worth sync with > > > > > Linux. For new architecture, it can be if possible. > > > > > > > > > > Konstantin, > > > > > Your thoughts? > > > > > > > > > > > > > My thought would be that if we have JIT eBPF compiler already in DP= DK > > > > for one arch (x86) there is absolutely no reason why we shouldn't > > > > allow it for different arch (arm). > > > > About having a common code-base with Linux eBPF JITs implementation= - > > > > I think it is a very good idea, > > > > but I don=E2=80=99t' think it could be achieved without significant= effort. > > > > DPDK and Linux JIT code-generators differ quite a bit. > > > > So my suggestion - let's go ahead and integrate Jerin patch into 19= =2E11, > > > > meanwhile start talking with linux guys how common JIT code-base co= uld > > > > be achieved. > > > > > > I agree with Konstantin here. > > > > > > Thomas, > > > > > > Just confirm the following: > > > > > > While we continue to have 'advanced' discussion on avoiding code > > > duplication etc and it will take a couple of months to converge > > > (if at all it happens) > > > Just to be clear, I assume, you are OK to merge this code for 19.11 > > > (If no more technical comment on the patch). > > > > > > I am only afraid of, our typical last-minute surprise pattern and > > > followed by back and forth open ended discussions. > > > > > > i.e > > > > > > # Code submitted before the proposal window > > > # Gets ACK from Maintainer > > > # New non-technical concerns start just before RC1 > > > > I hope you are not against discussing the real good questions, > > even if they come a month after the first submission. >=20 > I am not against discussing the technical data about the 'patch' and revi= ew > it. If there is a review with respect to content of the patch it is very > good, I am happy to address it. Stuff like I don't have any control ( > changing the licence) etc, I have am not comfortable to take in last > minute. I have already shared the eBPF ARM64 JIT support in roadmap a mon= th > ago before implementing it. No question asked that time. Spend a almost > month to add support for it and It is not a simple C code. Now I am not > comfortable in asking the fundamental questions like why this eBPF it self > is required and code duplication ( code was duplicated when x86 support > has been added) and therefore stall the patch at this point of time, where > this library and x86 support added a year back. I really don't like this reaction. =46irst, I never said this discussion was blocking the patch. Second, why am I the only one asking such obvious questions as not duplicating work? > > I don't care merging such patch in 19.11, > > but I would have preferred such questions were open > > when introducing this new library (for x86). You Jerin and Konstantin should have answered these questions a long time ago before starting such development. Is it so hard to require a bit of thoughts before starting something new? > Konstantin added enough data on ml this when this library gets added on > reply to different users. Really? which data? > > About your urge of having this code merged, > > please can you explain what is your usage? >=20 > As an ARM64 maintainter, I would like to fix any disparity in terms of t= he > features with respect to x86 and I have been doing for last 3 years. If > some one using eBPF on x86, I want to make sure it run in similar > "performance" on arm64 on architecture perspective. So we are debating about a library which is probably not used by anybody. That's not how I plan to spend my time on DPDK. Sorry Jerin, I really like working with you, but I think you forward too much pressure here, instead of quietly discussing the future of DPDK. Please forget the deadline (we will agree on merging anyway) and let's restart from the beginning by answering simple questions: =2D what are the use cases of BPF in DPDK? =2D how much we'll benefit from sharing code with Linux? =2D what can we lose in a single JIT implementation?