Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422640AbbEUQkz (ORCPT ); Thu, 21 May 2015 12:40:55 -0400 Received: from mail-ig0-f179.google.com ([209.85.213.179]:33002 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754247AbbEUQkw (ORCPT ); Thu, 21 May 2015 12:40:52 -0400 Message-ID: <555E0A93.2020803@plumgrid.com> Date: Thu, 21 May 2015 09:40:51 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Lutomirski CC: "David S. Miller" , Ingo Molnar , Daniel Borkmann , Michael Holzheu , Zi Shen Lim , Linux API , Network Development , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH net-next 1/4] bpf: allow bpf programs to tail-call other bpf programs References: <1432079946-9878-1-git-send-email-ast@plumgrid.com> <1432079946-9878-2-git-send-email-ast@plumgrid.com> <555BD2E4.5050608@plumgrid.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1932 Lines: 39 On 5/21/15 9:20 AM, Andy Lutomirski wrote: > > What I mean is: why do we need the interface to be "look up this index > in an array and just to what it references" as a single atomic > instruction? Can't we break it down into first "look up this index in > an array" and then "do this tail call"? I've actually considered to do this split and do first part as map lookup and 2nd as 'tail call to this ptr' insn, but it turned out to be painful: verifier gets more complicated, ctx pointer needs to kept somewhere, JITs need to special case two things instead of one. Also I couldn't see a use case for exposing program pointer to the program itself. I've explored this path only because it felt more traditional 'goto *ptr' like, but adding new PTR_TO_PROG type to verifier looked wasteful. > I don't see why everything needs to be a map. I mentioned the reasons to use map abstraction in the commit log: "- jump table is implemented as BPF_MAP_TYPE_PROG_ARRAY to reuse 'map' abstraction, its user space API and all of verifier logic. It's in the existing arraymap.c file, since several functions are shared with regular array map." The other alternative would be to add new thing just for jump table, but it means extending syscall commands and propagating the callchain through several files plus adding all new interfaces to user space. I think 'map' abstraction fits very well. We have 'array' map which is one-to-one to normal C array. This is just different type of array that stores prog_fds. When in C you're creating 'void *jmptable[] = { &&label1, &&label2};' it is still an array. So here you have special type PROG_ARRAY for it to make verifier recognize it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/