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 DC3CDA2EEB for ; Mon, 7 Oct 2019 21:32:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 316A51C0B1; Mon, 7 Oct 2019 21:32:05 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 01B151C0AF for ; Mon, 7 Oct 2019 21:32:03 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id n197so31183611iod.9 for ; Mon, 07 Oct 2019 12:32:03 -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=+q2HMwNMCoYEE5qsusYUwVAC4O8cPBvGL0I1D+UHsjo=; b=qaH7RSHGS4rIyR1lo3OlOGVTJPefJWtY1qAPjRhSKZJ06FtkuGzVfiAtw6f8z8LB7N X7C9GRdEYtfOMMjQUKaHiNHunuXXBFbefSA/6psH0c2ywfMlzRz8Fqk3J0qgz69gWgtE zD61Yb5hJAuMD0G3LhLH6m/L2ZG1ivvr4fNVr8lA/Z9mah5YBxSS0FLleNjFHUWUOrPe 8e6gaFjJIJFRCqx+QLHOV7z6PHLEjEHH11rm4DNuaNZNNRXTkygUeVZQV2/n99Dgsrpz zABSQ6WFEdqmrgMIlMUk/DNm/j+7iYLguZN4x/J5Ykjh0hQdWF+24zRowbqUyCZF2UMM Atog== 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=+q2HMwNMCoYEE5qsusYUwVAC4O8cPBvGL0I1D+UHsjo=; b=rYYYitChjk6Pfu4yUq/Y8/VyGlhi2qNdVpsTZnQfYi9jCHJ9132i6mBqIPQ6GH0jBt hS4XqoNZ7lJCWEuPMHrm2eJlb0SGgF5z+dvA0K2ExkzpQ+q25bMXPmH7IpcJ1OWBlh/p 66gDbjyE/04MRu3M+ybzgXt0PMcYmrcTS0QrebRyDE5R+/Rl55Hj/SnqNCS3WOJScxaA QnKsRLEQp4vZyTvua8rYXkLV1Ka60Zyofhz8qvhCnmIKMBtjMNVIQof5sm2+n9OOqRBc 8ttMxlTdVBpPZ7oIsmcut5CFbpy99DIje+1bDpi0RgqlJSqjoBVcCUML5Osez+zPtCE+ 4qSQ== X-Gm-Message-State: APjAAAVuWMWsTf1WO+MEKvRthWWf36rDF5gMsN6IJBCG69w8ESYeZLho k4+2aJc5GZ9+f6bPbMjbsafcQaP26pVbUyXj0xs= X-Google-Smtp-Source: APXvYqxNURgekvLPujKLuZfHdct7e3zLwbz0AcOqWDHtwq3L0VK9BN6Tp5s1l5ZyMBljDdYzjGjR4bNXu+RFP+erIm4= X-Received: by 2002:a92:1598:: with SMTP id 24mr29863581ilv.60.1570476722990; Mon, 07 Oct 2019 12:32:02 -0700 (PDT) MIME-Version: 1.0 References: <20190903105938.33231-1-jerinj@marvell.com> <4310069.WdzTAdBlsv@xps> <2692726.gUGBZ5dN0q@xps> In-Reply-To: <2692726.gUGBZ5dN0q@xps> From: Jerin Jacob Date: Tue, 8 Oct 2019 00:59:47 +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, 11:35 PM Thomas Monjalon, wrote: > 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 t= o > > > > > > > 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 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 wit= h > > > > > > 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 significa= nt effort. > > > > > 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. > > > > > > > > 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 ver= y > > 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 suppor= t > > 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. > If it hurts you in some way then I am sorry about that. First, I never said this discussion was blocking the patch. > You said you have concern with this patch. Sorry, I am not sure how to interpret that and if I don't jump in it will be stalled for sure. That's my experience. Sorry if you dis agree. Second, why am I the only one asking such obvious questions > as not duplicating work? > Some things it does not converge at all. Especially relicecing some code from linux. There are a lot developers(even me) are involved in that code base. Why would everyone agree? The list would include a recent RISCV JIT contributer from gmail.com as example. Duplication the semantics some times gives the morecontrol. We already did that for rte_flow, rcu etc. I have mentioned the performance reason as well for JIT in the other thread. > > > > 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? > For me, I don't see any better approach to have user space eBPF to support all OS in DPDK. > > Konstantin added enough data on ml this when this library gets added on > > reply to different users. > > Really? which data? > I am talking about the discussion with niterome developer.I don't have exact email thread, probably Konstantin may have > > > > 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. > > 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. > How do anyone know that the library is not used by anyone in community if it is part of dpdk.org and a customer asked does arm64 has JIT support too. If something needs to be dynamically controlled then eBPF can be used, couple of use cases # packet filtering # debugging # function call tracing # There are some Lua JIT based dataplane implementations. Which can be replaced with eBPF with JIT. > > > Sorry Jerin, I really like working with you, > Mee too. 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) > Ok. and let's restart from the beginning by answering simple questions: > - what are the use cases of BPF in DPDK? > I meantioned what I know, - how much we'll benefit from sharing code with Linux? > I have mentioned some of the performance constraint in the other thread. Moreover I don't believe it is not easy task for Linux eBPF to run as userspace and I not sure who is going to do that - what can we lose in a single JIT implementation? > Sorry, I didn't understood this question? > >