From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751099AbdGGJOm (ORCPT ); Fri, 7 Jul 2017 05:14:42 -0400 Received: from www62.your-server.de ([213.133.104.62]:43877 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbdGGJOk (ORCPT ); Fri, 7 Jul 2017 05:14:40 -0400 Message-ID: <595F50F3.2030008@iogearbox.net> Date: Fri, 07 Jul 2017 11:14:27 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Edward Cree , Alexei Starovoitov , Alexei Starovoitov CC: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, iovisor-dev Subject: Re: [PATCH v3 net-next 00/12] bpf: rewrite value tracking in verifier References: <5953B436.6030506@iogearbox.net> <788035e1-1974-b48e-3008-d294194a8b05@solarflare.com> <595413AA.40502@iogearbox.net> <20170628213701.32krfuipzngsmt4k@ast-mbp> <91267d15-652a-16d9-4ee9-42958bd842aa@solarflare.com> <5fa61129-fa82-1607-3363-dfad86aecf1e@solarflare.com> <595C1685.4060209@iogearbox.net> <54b95191-697d-6b15-ec39-438c85e08adc@solarflare.com> In-Reply-To: <54b95191-697d-6b15-ec39-438c85e08adc@solarflare.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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-progress) version of the patch series, with the > 'id' bugfix I mentioned in my other mail, and rebased onto an updated > net-next (0e72582). Numbers collected with: > # tc filter add dev lo egress bpf da obj /path/to/bpf_object.o sec $section verb 2>&1 | grep "processed" | awk -e 'BEGIN { N = 0; }' -e '{ N += $2; }' -e 'END { print N; }' > > Program net-next short full > bpf_lb_opt_-DLB_L3.o 4707 5872 6515 > bpf_lb_opt_-DLB_L4.o 7662 8652 8976 > bpf_lb_opt_-DUNKNOWN.o 727 2972 2960 > bpf_lxc_opt_-DDROP_ALL.o 57725 85750 95412 > bpf_lxc_opt_-DUNKNOWN.o 93676 134043 141706 > bpf_netdev.o 14702 24665 24251 > bpf_overlay.o 7303 10939 10999 > > Conclusion: the ptr&const and full-range min/max tracking make little > difference (10% increase at most, sometimes a decrease); most of the > increase comes from the basic "replace imm and aux_off/align with tnums" > patch. Okay, thanks for the analysis, Edward. > So based on what Alexei was saying earlier, it sounds like the answer for > now is to up the limit (say to a round 128k), get this series merged, > then start work on pruning optimisation so we can hopefully bring that > limit back down again later. Sound reasonable? 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 it wouldn't take much, say, few different optimizations from compiler, to hit the limit as well eventually, something like 156k for the time being would seem a more adequate raise perhaps that needs to be evaluated carefully given the situation. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann via iovisor-dev Subject: Re: [PATCH v3 net-next 00/12] bpf: rewrite value tracking in verifier Date: Fri, 07 Jul 2017 11:14:27 +0200 Message-ID: <595F50F3.2030008@iogearbox.net> References: <5953B436.6030506@iogearbox.net> <788035e1-1974-b48e-3008-d294194a8b05@solarflare.com> <595413AA.40502@iogearbox.net> <20170628213701.32krfuipzngsmt4k@ast-mbp> <91267d15-652a-16d9-4ee9-42958bd842aa@solarflare.com> <5fa61129-fa82-1607-3363-dfad86aecf1e@solarflare.com> <595C1685.4060209@iogearbox.net> <54b95191-697d-6b15-ec39-438c85e08adc@solarflare.com> Reply-To: Daniel Borkmann Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iovisor-dev , davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Edward Cree , Alexei Starovoitov , Alexei Starovoitov Return-path: In-Reply-To: <54b95191-697d-6b15-ec39-438c85e08adc-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iovisor-dev-bounces-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org Errors-To: iovisor-dev-bounces-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org List-Id: netdev.vger.kernel.org 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-progress) version of the patch series, with the > 'id' bugfix I mentioned in my other mail, and rebased onto an updated > net-next (0e72582). Numbers collected with: > # tc filter add dev lo egress bpf da obj /path/to/bpf_object.o sec $section verb 2>&1 | grep "processed" | awk -e 'BEGIN { N = 0; }' -e '{ N += $2; }' -e 'END { print N; }' > > Program net-next short full > bpf_lb_opt_-DLB_L3.o 4707 5872 6515 > bpf_lb_opt_-DLB_L4.o 7662 8652 8976 > bpf_lb_opt_-DUNKNOWN.o 727 2972 2960 > bpf_lxc_opt_-DDROP_ALL.o 57725 85750 95412 > bpf_lxc_opt_-DUNKNOWN.o 93676 134043 141706 > bpf_netdev.o 14702 24665 24251 > bpf_overlay.o 7303 10939 10999 > > Conclusion: the ptr&const and full-range min/max tracking make little > difference (10% increase at most, sometimes a decrease); most of the > increase comes from the basic "replace imm and aux_off/align with tnums" > patch. Okay, thanks for the analysis, Edward. > So based on what Alexei was saying earlier, it sounds like the answer for > now is to up the limit (say to a round 128k), get this series merged, > then start work on pruning optimisation so we can hopefully bring that > limit back down again later. Sound reasonable? 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 it wouldn't take much, say, few different optimizations from compiler, to hit the limit as well eventually, something like 156k for the time being would seem a more adequate raise perhaps that needs to be evaluated carefully given the situation.