From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80DD9C3A589 for ; Thu, 15 Aug 2019 14:02:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 49AB120644 for ; Thu, 15 Aug 2019 14:02:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="gxhbNS60" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732559AbfHOOCH (ORCPT ); Thu, 15 Aug 2019 10:02:07 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:46994 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732267AbfHOOCG (ORCPT ); Thu, 15 Aug 2019 10:02:06 -0400 Received: by mail-wr1-f68.google.com with SMTP id z1so2282555wru.13 for ; Thu, 15 Aug 2019 07:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FQNOABTbL/8jEK8m2LW+8rEri3jE9Z/p5qumYKibyAc=; b=gxhbNS60/UQT9y6In7OTwU0njZk32RyJuqAiwvZG28GdWrAjlsxbNGT/Rww3uELuG0 VjzJ5EznBejLB6Ubg1QX2hNndcLGYhRIB3YvpMyjoizAjIsgkkjGXqRd+6Z8GDAEo9/6 +t8XPt0KAWWHg5OnGSsOBmuLWusgDQqgkhfBD7VTJIt+JJ46uqK/6b/1ZJszWH+8p0S2 uVb17OI2DY7uP7otSNqStdvADamrgjXFxE4Yxpc0LJG1xpK9+60FfVozWTqofVO2bC0g ZHpPDKwT81EhFZ+oCtaTveaNS7cSuJGLINJkxfh92BEChWJgXpyJEsPPTYdSP0oZYPUN dIwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FQNOABTbL/8jEK8m2LW+8rEri3jE9Z/p5qumYKibyAc=; b=V/Yb2YNwrEsMG1ZTrGdX2/v1yPBa0s29S+A6UJsqRWOQWovN6dmzmL3+qNo9gTRJMD Hu+GX87KnlFM7jYiQAFwZ5a5bsJ9J+VYgzpghG7L1armgWleoepcR2GH7/5O3DGLr3+d vzLrykOa6GXkCLnNwZ1i0ClcYtAawZbiNzoYs8tB6wzrNGg4sDorvTLO5qUklqAqaRIa diBFRNc2TvLkgBK2Q1bfoQiG7q+uKaM0hQyoRfISSJQRzVG5QjL3++ajviMlanlcJrXW KUFI9GoEL0rn3wgndDUXWEW66XGkrkHIe1bYZexdKp5tOp22MAd4EvahBDlJShhOqmCN zP1A== X-Gm-Message-State: APjAAAVdTTp36zc/S7Rlch8jLkwaWtWlvakpbbnQqWg2TySxt81iPYBV 7q3chJpXGGM5lWhw0BbZWDt2ZQ== X-Google-Smtp-Source: APXvYqwkcoRie5k+E43qVPnGy8gLOcWqpfViY09PKpvmM0UtWWG40ruV4lL5DZgQWO8n5OY//Yb53w== X-Received: by 2002:adf:c803:: with SMTP id d3mr5936871wrh.130.1565877723710; Thu, 15 Aug 2019 07:02:03 -0700 (PDT) Received: from [172.20.1.254] ([217.38.71.146]) by smtp.gmail.com with ESMTPSA id z8sm3559957wru.13.2019.08.15.07.02.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 07:02:02 -0700 (PDT) To: Andrii Nakryiko Cc: Alexei Starovoitov , Edward Cree , Alexei Starovoitov , Daniel Borkmann , bpf , Network Development , oss-drivers@netronome.com References: <20190813130921.10704-1-quentin.monnet@netronome.com> <20190814015149.b4pmubo3s4ou5yek@ast-mbp> From: Quentin Monnet Openpgp: preference=signencrypt Autocrypt: addr=quentin.monnet@netronome.com; prefer-encrypt=mutual; keydata= mQINBFnqRlsBEADfkCdH/bkkfjbglpUeGssNbYr/TD4aopXiDZ0dL2EwafFImsGOWmCIIva2 MofTQHQ0tFbwY3Ir74exzU9X0aUqrtHirQHLkKeMwExgDxJYysYsZGfM5WfW7j8X4aVwYtfs AVRXxAOy6/bw1Mccq8ZMTYKhdCgS3BfC7qK+VYC4bhM2AOWxSQWlH5WKQaRbqGOVLyq8Jlxk 2FGLThUsPRlXKz4nl+GabKCX6x3rioSuNoHoWdoPDKsRgYGbP9LKRRQy3ZeJha4x+apy8rAM jcGHppIrciyfH38+LdV1FVi6sCx8sRKX++ypQc3fa6O7d7mKLr6uy16xS9U7zauLu1FYLy2U N/F1c4F+bOlPMndxEzNc/XqMOM9JZu1XLluqbi2C6JWGy0IYfoyirddKpwzEtKIwiDBI08JJ Cv4jtTWKeX8pjTmstay0yWbe0sTINPh+iDw+ybMwgXhr4A/jZ1wcKmPCFOpb7U3JYC+ysD6m 6+O/eOs21wVag/LnnMuOKHZa2oNsi6Zl0Cs6C7Vve87jtj+3xgeZ8NLvYyWrQhIHRu1tUeuf T8qdexDphTguMGJbA8iOrncHXjpxWhMWykIyN4TYrNwnyhqP9UgqRPLwJt5qB1FVfjfAlaPV sfsxuOEwvuIt19B/3pAP0nbevNymR3QpMPRl4m3zXCy+KPaSSQARAQABtC1RdWVudGluIE1v bm5ldCA8cXVlbnRpbi5tb25uZXRAbmV0cm9ub21lLmNvbT6JAj0EEwEIACcFAlnqRlsCGyMF CQlmAYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQNvcEyYwwfB7tChAAqFWG30+DG3Sx B7lfPaqs47oW98s5tTMprA+0QMqUX2lzHX7xWb5v8qCpuujdiII6RU0ZhwNKh/SMJ7rbYlxK qCOw54kMI+IU7UtWCej+Ps3LKyG54L5HkBpbdM8BLJJXZvnMqfNWx9tMISHkd/LwogvCMZrP TAFkPf286tZCIz0EtGY/v6YANpEXXrCzboWEiIccXRmbgBF4VK/frSveuS7OHKCu66VVbK7h kyTgBsbfyQi7R0Z6w6sgy+boe7E71DmCnBn57py5OocViHEXRgO/SR7uUK3lZZ5zy3+rWpX5 nCCo0C1qZFxp65TWU6s8Xt0Jq+Fs7Kg/drI7b5/Z+TqJiZVrTfwTflqPRmiuJ8lPd+dvuflY JH0ftAWmN3sT7cTYH54+HBIo1vm5UDvKWatTNBmkwPh6d3cZGALZvwL6lo0KQHXZhCVdljdQ rwWdE25aCQkhKyaCFFuxr3moFR0KKLQxNykrVTJIRuBS8sCyxvWcZYB8tA5gQ/DqNKBdDrT8 F9z2QvNE5LGhWDGddEU4nynm2bZXHYVs2uZfbdZpSY31cwVS/Arz13Dq+McMdeqC9J2wVcyL DJPLwAg18Dr5bwA8SXgILp0QcYWtdTVPl+0s82h+ckfYPOmkOLMgRmkbtqPhAD95vRD7wMnm ilTVmCi6+ND98YblbzL64YG5Ag0EWepGWwEQAM45/7CeXSDAnk5UMXPVqIxF8yCRzVe+UE0R QQsdNwBIVdpXvLxkVwmeu1I4aVvNt3Hp2eiZJjVndIzKtVEoyi5nMvgwMVs8ZKCgWuwYwBzU Vs9eKABnT0WilzH3gA5t9LuumekaZS7z8IfeBlZkGXEiaugnSAESkytBvHRRlQ8b1qnXha3g XtxyEqobKO2+dI0hq0CyUnGXT40Pe2woVPm50qD4HYZKzF5ltkl/PgRNHo4gfGq9D7dW2OlL 5I9qp+zNYj1G1e/ytPWuFzYJVT30MvaKwaNdurBiLc9VlWXbp53R95elThbrhEfUqWbAZH7b ALWfAotD07AN1msGFCES7Zes2AfAHESI8UhVPfJcwLPlz/Rz7/K6zj5U6WvH6aj4OddQFvN/ icvzlXna5HljDZ+kRkVtn+9zrTMEmgay8SDtWliyR8i7fvnHTLny5tRnE5lMNPRxO7wBwIWX TVCoBnnI62tnFdTDnZ6C3rOxVF6FxUJUAcn+cImb7Vs7M5uv8GufnXNUlsvsNS6kFTO8eOjh 4fe5IYLzvX9uHeYkkjCNVeUH5NUsk4NGOhAeCS6gkLRA/3u507UqCPFvVXJYLSjifnr92irt 0hXm89Ms5fyYeXppnO3l+UMKLkFUTu6T1BrDbZSiHXQoqrvU9b1mWF0CBM6aAYFGeDdIVe4x ABEBAAGJAiUEGAEIAA8FAlnqRlsCGwwFCQlmAYAACgkQNvcEyYwwfB4QwhAAqBTOgI9k8MoM gVA9SZj92vYet9gWOVa2Inj/HEjz37tztnywYVKRCRfCTG5VNRv1LOiCP1kIl/+crVHm8g78 iYc5GgBKj9O9RvDm43NTDrH2uzz3n66SRJhXOHgcvaNE5ViOMABU+/pzlg34L/m4LA8SfwUG ducP39DPbF4J0OqpDmmAWNYyHh/aWf/hRBFkyM2VuizN9cOS641jrhTO/HlfTlYjIb4Ccu9Y S24xLj3kkhbFVnOUZh8celJ31T9GwCK69DXNwlDZdri4Bh0N8DtRfrhkHj9JRBAun5mdwF4m yLTMSs4Jwa7MaIwwb1h3d75Ws7oAmv7y0+RgZXbAk2XN32VM7emkKoPgOx6Q5o8giPRX8mpc PiYojrO4B4vaeKAmsmVer/Sb5y9EoD7+D7WygJu2bDrqOm7U7vOQybzZPBLqXYxl/F5vOobC 5rQZgudR5bI8uQM0DpYb+Pwk3bMEUZQ4t497aq2vyMLRi483eqT0eG1QBE4O8dFNYdK5XUIz oHhplrRgXwPBSOkMMlLKu+FJsmYVFeLAJ81sfmFuTTliRb3Fl2Q27cEr7kNKlsz/t6vLSEN2 j8x+tWD8x53SEOSn94g2AyJA9Txh2xBhWGuZ9CpBuXjtPrnRSd8xdrw36AL53goTt/NiLHUd RHhSHGnKaQ6MfrTge5Q0h5A= Subject: Re: [RFC bpf-next 0/3] tools: bpftool: add subcommand to count map entries Message-ID: <3684be7d-aae9-9478-6826-a8c92f01a2cd@netronome.com> Date: Thu, 15 Aug 2019 15:02:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org 2019-08-14 13:18 UTC-0700 ~ Andrii Nakryiko > On Wed, Aug 14, 2019 at 10:12 AM Quentin Monnet > wrote: >> >> 2019-08-14 09:58 UTC-0700 ~ Alexei Starovoitov >> >>> On Wed, Aug 14, 2019 at 9:45 AM Edward Cree wrote: >>>> >>>> On 14/08/2019 10:42, Quentin Monnet wrote: >>>>> 2019-08-13 18:51 UTC-0700 ~ Alexei Starovoitov >>>>> >>>>>> The same can be achieved by 'bpftool map dump|grep key|wc -l', no? >>>>> To some extent (with subtleties for some other map types); and we use a >>>>> similar command line as a workaround for now. But because of the rate of >>>>> inserts/deletes in the map, the process often reports a number higher >>>>> than the max number of entries (we observed up to ~750k when max_entries >>>>> is 500k), even is the map is only half-full on average during the count. >>>>> On the worst case (though not frequent), an entry is deleted just before >>>>> we get the next key from it, and iteration starts all over again. This >>>>> is not reliable to determine how much space is left in the map. >>>>> >>>>> I cannot see a solution that would provide a more accurate count from >>>>> user space, when the map is under pressure? >>>> This might be a really dumb suggestion, but: you're wanting to collect a >>>> summary statistic over an in-kernel data structure in a single syscall, >>>> because making a series of syscalls to examine every entry is slow and >>>> racy. Isn't that exactly a job for an in-kernel virtual machine, and >>>> could you not supply an eBPF program which the kernel runs on each entry >>>> in the map, thus supporting people who want to calculate something else >>>> (mean, min and max, whatever) instead of count? >>> >>> Pretty much my suggestion as well :) > > I also support the suggestion to count it from BPF side. It's flexible > and powerful approach and doesn't require adding more and more nuanced > sub-APIs to kernel to support subset of bulk operations on map > (subset, because we'll expose count, but what about, e.g., p50, etc, > there will always be something more that someone will want and it just > doesn't scale). Hi Andrii, Yes, that makes sense. > >>> >>> It seems the better fix for your nat threshold is to keep count of >>> elements in the map in a separate global variable that >>> bpf program manually increments and decrements. >>> bpftool will dump it just as regular map of single element. >>> (I believe it doesn't recognize global variables properly yet) >>> and BTF will be there to pick exactly that 'count' variable. >>> >> >> It would be with an offloaded map, but yes, I suppose we could keep >> track of the numbers in a separate map. We'll have a look into this. > > See if you can use a global variable, that way you completely > eliminate any overhead from BPF side of things, except for atomic > increment. Offloaded maps do not implement the map_direct_value_addr() operation, so global variables are not supported at the moment. I need to dive deeper into this and see what is required to add that support. Thanks for your advice! Quentin