From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:39938 "EHLO
        Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1753043AbeCFSDT (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 6 Mar 2018 13:03:19 -0500
Date: Tue, 6 Mar 2018 19:03:09 +0100
From: Florian Westphal <fw@strlen.de>
To: Edward Cree <ecree@solarflare.com>
Cc: Florian Westphal <fw@strlen.de>,
        Daniel Borkmann <daniel@iogearbox.net>, netdev@vger.kernel.org,
        ast@kernel.org, pablo@netfilter.org
Subject: Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate
 layer
Message-ID: <20180306180309.GB20009@breakpoint.cc>
References: <20180304194044.26751-1-fw@strlen.de>
 <6173affc-3bcd-8041-cf05-20f5578e37ee@iogearbox.net>
 <20180306164229.GA20009@breakpoint.cc>
 <4bf36b07-6c7f-bada-54d4-88a17f32355b@solarflare.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4bf36b07-6c7f-bada-54d4-88a17f32355b@solarflare.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Edward Cree <ecree@solarflare.com> wrote:
> On 06/03/18 16:42, Florian Westphal wrote:
> > I would also add 'highlevel' objects that are themselves translated into
> > basic operations.  Most obvious example
> > are 'fetch 4 bytes x bytes into transport header'.
> >
> > Frontend should not need to bother with ipv4 details, such as ip
> > options.  Instead IMR should take care of this and generate the needed
> > instructions to fetch iph->ihl and figure out the correct transport
> > header offset.
> Presumably then for this the IMR regs will cease to have any connection to
> �BPF regs and will simply be (SSA?) r0, r1, ... as far as needed (not
> �limited to 10 regs like BPF)?� Then register allocation all happens in
> �the IMR->BPF conversion (even for things 64 bits or smaller).
> 
> I wonder how sophisticated we should be about register allocation; whether
> �we should go the whole hog with graph-colouring algorithms or linear
> �scan, or just do something na�ve like an LRU.
> 
> Relatedly, should we spill values to the stack when we run out of
> �registers, or should we just rely on being able to rematerialise them
> �from parsing the packet again?

I don't know.  I suspect we should go for naive algorithm only,
but I would defer such decision to Alexei/Daniel.

f.e. i don't know if using llvm is a good idea or not, I did not
intend to turn proposed imr into full blown compiler in any case,
I only want to avoid code duplication for iptables/nftables -> ebpf
translator.