[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170809.142600.872268659837843440.davem@davemloft.net>
Date: Wed, 09 Aug 2017 14:26:00 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: daniel@...earbox.net
Cc: ast@...com, holzheu@...ux.vnet.ibm.com,
naveen.n.rao@...ux.vnet.ibm.com, jakub.kicinski@...ronome.com,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/9] bpf: add BPF_J{LT,LE,SLT,SLE} instructions
From: Daniel Borkmann <daniel@...earbox.net>
Date: Wed, 09 Aug 2017 22:32:34 +0200
> For the case of cilium, we are not in control of the kernel, by
> the way, we run a few probes that are small BPF insns snippets
> that test the kernel for presence of certain features (e.g. helper,
> verifier, maps) and enable/disable them accordingly later in the
> code generation. On the user space side, we're indeed a bit more
> flexible and have no such restriction.
>
> Plan is for LLVM as one of the frontends that generate byte code
> (ply, for example, can probe the kernel directly for its code
> generation) to have i) a target specific option to offer a
> possibility to explicitly enable the extension by the user (as we
> have with -m target specific extensions today for various cpu
> insns), and ii) have the kernel check for presence of the extensions
> and enable it transparently when the user selects more aggressive
> options such as -march=native in a bpf target context, so we can
> select the underlying features transparently. I should have made
> that more clear earlier, sorry about that.
I think this explanation needs to be in either your header posting
or the commit message of patch #1.
Thanks :)
Powered by blists - more mailing lists