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 9C5ADA2EEB for ; Mon, 7 Oct 2019 15:02:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BFB1C1C1B1; Mon, 7 Oct 2019 15:02:07 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 0FD331C1AE for ; Mon, 7 Oct 2019 15:02:07 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id u8so28279851iom.5 for ; Mon, 07 Oct 2019 06:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i1ftoTK+5fllMIpLMaUQ3o9p1vjVWFHm6q0MJONwLdU=; b=qLIt7/+b5PofYo2uK+EZ91xw5Qklv6b4/c8v/I1e7dZ/nwyfeSVl9ETFwgym8gn0Di cwORaG5a9Ylous0UMQd8DGnZ0xOVnLI5XUg7AUr327CvrAMU3T6VcT28kpi/bfCV0vRH BjexbnW9CUpX7Fr3P7hg3NZIFceisl0/HlO/U6kmo7wD5/xIJO6mPaBdlNzEVt3A4Hax +EkCmJxzM/bOXnil7tzUELOiU4Xx9fd0EwLebYU7cFxxFPbzSh/qg329nk/G4TlLbggb 7Y5nCeZGPfwobcMS7Y4S8dvuTAlTjmSxaTbpT60LxyZ2DBixsjC8sObG3J2CiHLneGee aEjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i1ftoTK+5fllMIpLMaUQ3o9p1vjVWFHm6q0MJONwLdU=; b=mHPALPDXoQVGFRa1pOjDKPswFHPz/ZV189Hv3tPbI1VCXjuKG+ufPHaWURf3tPnN/m lXL2NLiySUxxaRKgp6sHeQcGG3prfyk5YPUECa9LjTUhjMsQGRK2yVXwLjGbcKx8/dHh HhRgP4NIiamocf8giHCAehUNQh1BZwKQMUpl8FkuEu7qDfRfoHaBxoIeCRegywDclo/g 3y4wo43U/6wdMn/DUf0ZwWJR3x0QKF4Go4ujVX35qIwCwmcFisIiXFbsBmcjWnSrBnOu IL+2cvh/fU8joEeLNppROBbfbWAJ7JsudFzG2BMDUWttG31qeLgCgMiWXme6dYR4JRlk UkUQ== X-Gm-Message-State: APjAAAU8o+tmvoIfErYsNakLNEJ8BW/xlAFAZ+SgNVw3GoirtgQ1nIEu dtgI9Nv39OI4868/irxuw5XwXTQ6AUhhHYrjxF8= X-Google-Smtp-Source: APXvYqw5hFQz18BqB2KVwzOxolfJojos+Z0RO1zgGi3saRWzcxCEAEIxr5wVsYdmL9lybn/Tkx0NxtMwgwSZIPZBKPM= X-Received: by 2002:a02:7797:: with SMTP id g145mr26791253jac.60.1570453326108; Mon, 07 Oct 2019 06:02:06 -0700 (PDT) MIME-Version: 1.0 References: <20190903105938.33231-1-jerinj@marvell.com> <2601191342CEEE43887BDE71AB9772580191970A12@irsmsx105.ger.corp.intel.com> <4310069.WdzTAdBlsv@xps> In-Reply-To: <4310069.WdzTAdBlsv@xps> From: Jerin Jacob Date: Mon, 7 Oct 2019 18:30:55 +0530 Message-ID: To: Thomas Monjalon Cc: "Ananyev, Konstantin" , Jerin Jacob , dpdk-dev , Honnappa Nagarahalli , Gavin Hu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" 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: > > > > > > 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 > 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 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/504792e07a44844f24e9d79913e4a2f8= 373cd332 > > > > > > > > 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 a= nd > > > > 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 e= ffort. > > > DPDK and Linux JIT code-generators differ quite a bit. > > > So my suggestion - let's go ahead and integrate Jerin patch into 19.1= 1, > > > meanwhile start talking with linux guys how common JIT code-base coul= d > 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. > I am not against discussing the technical data about the 'patch' and review 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 month 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 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). > Konstantin added enough data on ml this when this library gets added on reply to different users. > About your urge of having this code merged, > please can you explain what is your usage? > As an ARM64 maintainter, I would like to fix any disparity in terms of the 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. > >