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=-8.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 9FA6CC43461 for ; Thu, 10 Sep 2020 10:11:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5337F20BED for ; Thu, 10 Sep 2020 10:11:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=sartura-hr.20150623.gappssmtp.com header.i=@sartura-hr.20150623.gappssmtp.com header.b="0pUmmi0k" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730526AbgIJKLh (ORCPT ); Thu, 10 Sep 2020 06:11:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725913AbgIJKLM (ORCPT ); Thu, 10 Sep 2020 06:11:12 -0400 Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0D18C061756 for ; Thu, 10 Sep 2020 03:11:11 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id l4so5137045ilq.2 for ; Thu, 10 Sep 2020 03:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sartura-hr.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dYn711/ecEMa9YkRKRtL12MOp1Pmr/gkc97vbP51zKs=; b=0pUmmi0kKFjMFtMFkm81POxlGd8OLWHIbb357w8LJEutcKtX2TJY2D84oFNqpaKkWj LIZu8CjdTYcnK+j9/EGSdH0gxwP/ueYIs5FPFgQm8Sq5hOBWafg1XHeunzk02ZZTN1/H xt5iPuSprTSuTlJuVcu1Re0MnUq1SMx7pPtpkIWKnsmYIq4PxcC1cTC+6p0E/2V01yBf cWoyykLWj+7Ek7CEAl91yA2xB87BligfWuoTeEfAQH8Nch1eYqHbu9XDDVUcsYJQZx6/ PwzbWib+tGdPfZZohCcvXg4rknkfDVdQV3v7niGO6T+6FQhL0/4txIB+K4vNxyvLL0Ps 3wgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dYn711/ecEMa9YkRKRtL12MOp1Pmr/gkc97vbP51zKs=; b=LqsPBiAHRoHT5XNcUOSVCwH5wQenxLwc2CiEww8buFL9rTD5CgygfR4gcDB51eR4y7 SlN4cPFjDwQvDKvgpIhE0bvTqDEUX3urn5B9LTrjhhxZenpphjpse3e2mRhiMr/PgWZh JAAosHbLPnFvaPeaJA3hkEiqH2g/b8FIqMtGRnyHHe7PYdnBdzBfv42KAF3yJstUyOKX vqJ/iew9zpfMyUSvv7O3InsKaXHHiTdn54sYpXd4ZD8Into4nGGO3Oy8uHLM+Cp2xqL8 ekJI+V6hZQWmM64bc0ZVuhwmtdgnONREq0Pmi/+uxPB6IntPYtMjFuVnIQgqmojdwbTU DFxw== X-Gm-Message-State: AOAM533Yu1ngmhsoXyxonmTggVXq+UlScjsdIeXvRT0zXLCQSGRjkCEN wxauVZOni+Z33LjfM775iFAlIpp1WWUYX3nahk4YFw== X-Google-Smtp-Source: ABdhPJxsUK2w96KVp27uVBQuyvQ3vG3xd0ASnK210PCB3wzoJVXqDsJLG6KiuIhl1SK9e7YXDDkcbt+3siRcpE26a30= X-Received: by 2002:a92:ba45:: with SMTP id o66mr7609998ili.38.1599732670989; Thu, 10 Sep 2020 03:11:10 -0700 (PDT) MIME-Version: 1.0 References: <878sdlpv92.fsf@toke.dk> <87mu1znt7q.fsf@toke.dk> In-Reply-To: From: Borna Cafuk Date: Thu, 10 Sep 2020 12:11:00 +0200 Message-ID: Subject: Re: HASH_OF_MAPS inner map allocation from BPF To: KP Singh Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Alexei Starovoitov , bpf , Luka Perkov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Sep 9, 2020 at 12:36 PM KP Singh wrote: > > On Wed, Sep 9, 2020 at 12:24 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > Borna Cafuk writes: > > > > > On Mon, Sep 7, 2020 at 3:33 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > >> > > >> Borna Cafuk writes: > > >> > > >> > On Sat, Sep 5, 2020 at 12:47 AM Alexei Starovoitov > > >> > wrote: > > [...] > > > >> > > > >> > The idea is to have an outer map where the keys are PIDs, and inne= r maps where > > >> > the keys are system call numbers. This would enable tracking the n= umber of > > >> > syscalls made by each process and the makeup of those calls for al= l processes > > >> > simultaneously. > > >> > > > >> > [1] https://github.com/iovisor/bcc/blob/master/libbpf-tools/syscou= nt.bpf.c > > >> > > >> Well, if you just want to count, map-in-map seems a bit overkill? Yo= u > > >> could just do: > > >> > > >> struct { > > >> u32 pid; > > >> u32 syscall; > > >> } map_key; > > >> > > >> and use that? > > >> > > >> -Toke > > >> > > > > > > I have considered that, but maps in maps seem better for when I need = to get the > > > data about a single process's syscalls: It requires reading only one = of the > > > inner maps in its entirety. If I have a composite key like that, I do= n't see > > > any way, other than: > > > * either iterating through all the possible keys for a process > > > (i.e. over all syscalls) and looking them up in the map, or > > > * iterating over all entries in the map and filtering them. > > > > > > Looking at it again, the first option does not seem _that_ bad, > > > > You could even use BPF_MAP_LOOKUP_BATCH to do this in one operation, I > > suppose... > > > > > but just iterating over one (inner) map would be easier to fit into > > > our use-case. > > > > ...but yeah, I see what you mean. Well, maybe BPF local storage per > > process would also be a nice fit here? Thank you for the insight. > > Yes, task local storage does seem like a good fit and is the next one I w= as > thinking of implementing. > > - KP I'm looking forward to the patches. > > > > > -Toke > >