From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: pull-request: bpf-next 2017-12-18 Date: Wed, 20 Dec 2017 16:16:44 -0500 (EST) Message-ID: <20171220.161644.274941609957500499.davem@davemloft.net> References: <20171218003307.10014-1-daniel@iogearbox.net> <20171218.105153.395572657387757515.davem@davemloft.net> <20171219062828.r6xadsdenfn2v5i2@ast-mbp> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: daniel@iogearbox.net, ast@kernel.org, netdev@vger.kernel.org To: alexei.starovoitov@gmail.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:44284 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756280AbdLTVQy (ORCPT ); Wed, 20 Dec 2017 16:16:54 -0500 In-Reply-To: <20171219062828.r6xadsdenfn2v5i2@ast-mbp> Sender: netdev-owner@vger.kernel.org List-ID: From: Alexei Starovoitov Date: Mon, 18 Dec 2017 22:28:30 -0800 > 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. I think I understand how this new stuff works, I'll take a stab at doing the sparc64 JIT bits.