I did an experiment with one of our internal bpf programs.
The program has 1563 insns.
Without Edward's patch:
processed 13634 insns, stack depth 160
With Edward's patch:
processed 15807 insns, stack depth 160
So the number of processed insns regressed by roughly 16%.
Did anybody do any similar
On 07/07/2017 02:50 PM, Edward Cree wrote:
On 07/07/17 10:14, Daniel Borkmann wrote:
But this means the bpf_lxc_* cases increase quite significantly,
arguably one of them is pretty close already, but the other one not
so much, meaning while 142k would shoot over the 128k target quite a
bit, the
On 07/07/17 10:14, Daniel Borkmann wrote:
> But this means the bpf_lxc_* cases increase quite significantly,
> arguably one of them is pretty close already, but the other one not
> so much, meaning while 142k would shoot over the 128k target quite a
> bit, the 95k is quite close to the point that
On 04/07/17 23:28, Daniel Borkmann wrote:
> Have you tried with cilium's BPF code? The kernel selftests are quite small,
> so not really pushing processed insns too far. I can send you a BPF obj file
> if that's easier for testing.
Results from the next (in-progress) version of the patch series,
On 04/07/17 20:22, Edward Cree wrote:
> I don't know why test_l4lb has to process _fewer_ insns with my patches;
> if anything I'm worrying that I may be incorrectly pruning branches.
> (I've spotted a possible bug in that I'm not looking at 'id' which,
> although it doesn't have to match, if
On 07/04/2017 09:22 PM, Edward Cree wrote:
On 30/06/17 19:15, Alexei Starovoitov wrote:
On 6/30/17 9:44 AM, Edward Cree wrote:
I haven't measured the test_progs ones, because I *still* haven't gotten
around to actually setting up a BPF toolchain (it doesn't help that I'm
building
On 28/06/17 22:37, Alexei Starovoitov wrote:
> Increasing the limit is must have, since pruning suffered so much.
> Going from 53k to 76k is pretty substantial.
> What is the % increase for tests in selftests/ ?
When I tried to measure the test_verifier tests, they changed hardly at
all, only a
On Wed, Jun 28, 2017 at 10:38:02PM +0200, Daniel Borkmann wrote:
> On 06/28/2017 04:11 PM, Edward Cree wrote:
> > On 28/06/17 14:50, Daniel Borkmann wrote:
> > > Hi Edward,
> > >
> > > Did you also have a chance in the meantime to look at reducing complexity
> > > along with your unification? I
On 06/28/2017 04:11 PM, Edward Cree wrote:
On 28/06/17 14:50, Daniel Borkmann wrote:
Hi Edward,
Did you also have a chance in the meantime to look at reducing complexity
along with your unification? I did run the cilium test suite with your
latest set from here and current # worst case
This series simplifies alignment tracking, generalises bounds tracking and
fixes some bounds-tracking bugs in the BPF verifier. Pointer arithmetic on
packet pointers, stack pointers, map value pointers and context pointers has
been unified, and bounds on these pointers are only checked when
10 matches
Mail list logo
