[dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support

[Thomas Monjalon]

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 at 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.
First, I never said this discussion was blocking the patch.
Second, why am I the only one asking such obvious questions
as not duplicating work?

> > 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?

> Konstantin added enough data on ml this when this library gets added on
> reply to different users.

Really? which data?

> > 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.

Sorry Jerin, I really like working with you,
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)
and let's restart from the beginning by answering simple questions:
- what are the use cases of BPF in DPDK?
- how much we'll benefit from sharing code with Linux?
- what can we lose in a single JIT implementation?