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 the
Hi Edward,
On 06/27/2017 02:53 PM, Edward Cree wrote:
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 uni
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 processed insns that
> verifier has to go thr
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 processe
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 di
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 co
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 everything on a test server that gets reimaged every night to
run our nightly tests...).
then you'r
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 everything on a test server that gets reimaged e
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 everything
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 two
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, wi
On 07/06/2017 08:27 PM, Edward Cree wrote:
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-
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 i
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
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
15 matches
Mail list logo
