Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752102AbdGGMuy (ORCPT ); Fri, 7 Jul 2017 08:50:54 -0400 Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:37787 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750938AbdGGMuw (ORCPT ); Fri, 7 Jul 2017 08:50:52 -0400 Subject: Re: [PATCH v3 net-next 00/12] bpf: rewrite value tracking in verifier To: Daniel Borkmann , Alexei Starovoitov , Alexei Starovoitov 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> <595F50F3.2030008@iogearbox.net> CC: , , , iovisor-dev From: Edward Cree Message-ID: Date: Fri, 7 Jul 2017 13:50:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <595F50F3.2030008@iogearbox.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.45] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23180.003 X-TM-AS-Result: No--4.705700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1499431851-NOwyhgccNsZw Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 871 Lines: 16 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 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. Note that the numbers in my table are the _sum_ of all the progs in the object file, not the #insns for a single program. (Hence the awk invocation in my pipeline.) For instance in bpf_lxc_opt_-DUNKNOWN.o on net-next there were (iirc) a couple of 30k progs and then some smaller ones, not a single 93k prog. -Ed