From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: pull-request: bpf-next 2017-12-18 Date: Mon, 18 Dec 2017 22:28:30 -0800 Message-ID: <20171219062828.r6xadsdenfn2v5i2@ast-mbp> References: <20171218003307.10014-1-daniel@iogearbox.net> <20171218.105153.395572657387757515.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: daniel@iogearbox.net, ast@kernel.org, netdev@vger.kernel.org To: David Miller Return-path: Received: from mail-pl0-f42.google.com ([209.85.160.42]:39931 "EHLO mail-pl0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933780AbdLSG2e (ORCPT ); Tue, 19 Dec 2017 01:28:34 -0500 Received: by mail-pl0-f42.google.com with SMTP id bi12so6408451plb.6 for ; Mon, 18 Dec 2017 22:28:34 -0800 (PST) Content-Disposition: inline In-Reply-To: <20171218.105153.395572657387757515.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, Dec 18, 2017 at 10:51:53AM -0500, David Miller wrote: > From: Daniel Borkmann > Date: Mon, 18 Dec 2017 01:33:07 +0100 > > > The following pull-request contains BPF updates for your *net-next* tree. > > > > The main changes are: > > > > 1) Allow arbitrary function calls from one BPF function to another BPF function. > > As of today when writing BPF programs, __always_inline had to be used in > > the BPF C programs for all functions, unnecessarily causing LLVM to inflate > > code size. Handle this more naturally with support for BPF to BPF calls > > such that this __always_inline restriction can be overcome. As a result, > > it allows for better optimized code and finally enables to introduce core > > BPF libraries in the future that can be reused out of different projects. > > x86 and arm64 JIT support was added as well, from Alexei. > > Exciting... but now there's a lot of JIT work to do. I've looked at sparc64. It should be simpler than arm64. First reaction was that it would need dumb version of emit_loadimm64() (similar to arm's emit_addr_mov_i64), but not, since it's not used in emit_call. I can take a stab at it, but cannot test. The most time consuming part is to setup the latest llvm on the system to compile *_noinline.c tests. Note to self, I really need to make test_verifier run the tests.