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 F06C4A2EEB for ; Mon, 7 Oct 2019 14:33:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 869FF1C1BC; Mon, 7 Oct 2019 14:33:37 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 214CB1BF57 for ; Mon, 7 Oct 2019 14:33:36 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 73BA521AFB; Mon, 7 Oct 2019 08:33:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 07 Oct 2019 08:33:35 -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=6t60ggHL5iulM8b0EYQh+XMHd0zUnAfDebS+CumjcBo=; b=l0/GemxKMe13 guAs+2z4vKX1moiiR4hnHOt1RwQowZ/oG2WvBcg+0RNhw4RpB0HXJ9Z/+GMJQe5F cvwuHU3LrdfANWqqMUjK/bBF2MgkQYwNzYYhagf7UfllfG1r5WElgFUMrG2gab+y oHD1NpfeWC1mE2MlzZPd8WB3MGpEOg8= 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=6t60ggHL5iulM8b0EYQh+XMHd0zUnAfDebS+Cumjc Bo=; b=X2vxYI7SQlVk9GsjSOEwXvJ/7CeqwGXQspt0vE3c8Ma2FlSSBIA0VZw7v KXmrZQWBCnZGeCZAS2j6CtqW2JLntarCFBfX1bVGbGJC5oufk/lNzRvx3MLwcQhW VwShu4bFhSrMkwDSVQFoXa6XeD45QcsF218mXtHStmYuFesmIrRN1XOCiz3DSln6 cTqJ6i5aE+f2u8AyUnEFVbtuxKC57FsEx65Dkm+7/5tdz9Cvv3APORCBxvG088pB RNb2AWMmZRBjtHknBj67EekLYXOBKAdtthSQ92lhX3zhCH0SvVTk0N9rmKJ/7QIu OzVS+kqpuS3lxapHSgHrqHkXfbURw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheejgdegtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepghhithhhuhgsrdgtohhmnecukfhppeejjedrudefgedrvddtfedrudekgeen ucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth enucevlhhushhtvghrufhiiigvpedt 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 DF7FA80060; Mon, 7 Oct 2019 08:33:33 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: "Ananyev, Konstantin" , Jerin Jacob , dpdk-dev , Honnappa Nagarahalli , Gavin Hu Date: Mon, 07 Oct 2019 14:33:32 +0200 Message-ID: <4310069.WdzTAdBlsv@xps> In-Reply-To: References: <20190903105938.33231-1-jerinj@marvell.com> <2601191342CEEE43887BDE71AB9772580191970A12@irsmsx105.ger.corp.intel.com> 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" 04/10/2019 17:39, Jerin Jacob: > On Thu, Oct 3, 2019 at 8:35 PM Ananyev, Konstantin > wrote: > > > > Hi everyone, > > > > > > > > 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 performa= nce > > > > > on arm64. > > > > > > > > > > lib/librte_bpf/bpf_jit_arm64.c | 1451 ++++++++++++++++++= ++++++ > > > > > > > > I am concerned about duplicating the BPF JIT effort in DPDK and Lin= ux. > > > > 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 arra= nge > > > > their JIT code for sharing with userspace projects. > > > > > > I did a clean room implementation considering some optimization for > > > 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 also to > > > Linux as well.(Some more pending as well) > > > > > > https://github.com/torvalds/linux/commit/504792e07a44844f24e9d79913e4= a2f8373cd332 > > > > > > 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 DPDK). > > > 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 DPDK > > 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 eff= ort. > > DPDK and Linux JIT code-generators differ quite a bit. > > So my suggestion - let's go ahead and integrate Jerin patch into 19.11, > > meanwhile start talking with linux guys how common JIT code-base could = be achieved. >=20 > I agree with Konstantin here. >=20 > Thomas, >=20 > Just confirm the following: >=20 > While we continue to have 'advanced' discussion on avoiding code duplicat= ion etc > and it will take a couple of months to converge(if at all it happens) >=20 > Just to be clear, I assume, you are OK to merge this code for 19.11(If > no more technical comment on the patch). >=20 > I am only afraid of, our typical last-minute surprise pattern and > followed by back and forth open ended discussions. >=20 > i.e >=20 > # 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. 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). About your urge of having this code merged, please can you explain what is your usage?