On Mon, 7 Oct, 2019, 6:03 PM Thomas Monjalon, <tho...@monjalon.net> wrote:
> 04/10/2019 17:39, Jerin Jacob: > > On Thu, Oct 3, 2019 at 8:35 PM Ananyev, Konstantin > > <konstantin.anan...@intel.com> wrote: > > > > > > Hi everyone, > > > > > > > > > > > On Thu, Oct 3, 2019 at 6:21 PM Thomas Monjalon <tho...@monjalon.net> > 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 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. > >
