On Mon, 7 Oct, 2019, 11:35 PM Thomas Monjalon, <tho...@monjalon.net> 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, jer...@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/504792e07a44844f24e9d79913e4a2f8373cd332 > > > > > > > > > > > > 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’t' 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.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 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 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? > >
