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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 6806FC4707F for ; Tue, 25 May 2021 19:58:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4201C61401 for ; Tue, 25 May 2021 19:58:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232948AbhEYT7a (ORCPT ); Tue, 25 May 2021 15:59:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230343AbhEYT73 (ORCPT ); Tue, 25 May 2021 15:59:29 -0400 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECB98C061574; Tue, 25 May 2021 12:57:57 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id e2so33448135ljk.4; Tue, 25 May 2021 12:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4s7vCGqH0XmF+l5T0ZZ65rm+cCf196bb9Q/4DckFJcg=; b=cAXVMGYah5V9RlRZ3EBNnOceo2itK3w+IW+xPAMqU2D6u4YGXBqerZni5pcuJB+NxV 7rzC9482okTVr+e+0jqx8t12+aX91S5oT7hlD3fTWi9RSoF540Qti865/8QHLNLVjgE3 qMbhjuM7HChXgxfwLYlrPHVeOF5Mf8x60+tiGHN0fmyhTIHSRGnEhl1fdVo7/yL5zyp2 9pP7juyMcC5sD1V/oqVjfT0pMtPj1Cihv5U85a02M62ktAvOmETMLArADanADmwU6xdE SwtB6I8jayKXQ3/8Ns91GK0jS9DIvgscpG1XjRx/qugGZiQbKIVXvhog2LawbWt5R/39 KnNQ== 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; bh=4s7vCGqH0XmF+l5T0ZZ65rm+cCf196bb9Q/4DckFJcg=; b=XnY04Wo9j0g6azwHXWMytiG91y6uzBYOU12asRAoNiNzEIj6Z5PJiClEEXM+BT4Xox Z78NjCrc4l8bfgiS+hWEx1dgQS3qAkrcBeaZA1/YyYlDXKpxkjs3sJEvM0o12Bhue+cv ermF8/rLDFY6qWOBreZpjrwNh2QTsYAsutpHj19b2CMhz5LZz4/UfKFXjkQGD6T3MSqZ n0hCBRYBcMTWDFHfyH1SWojUv4VSQ/6W/aAuR+qSfjIWwmnTiZ6y6HM8U00hHuS2GDon 4jZlM4IzFR6XD/ytyrF5tTjmWzlbWtQTJSqrAaKG6Ql8rZTPyBGWc3A5aNSok7oR1xY7 I2iA== X-Gm-Message-State: AOAM530jImx7qyT6PFIFTaw1lUTab6XPM0jhwoVcRcXngg3V0IBeVD63 yZnxNbd4i74MwzEVh8Lz7iqhPir/FMrKvJBigqq6WmaQ X-Google-Smtp-Source: ABdhPJwfnnuCdxpZ2xllj1yM84DF3TTXPxxxfJDxAdKeBGjipAsgTG83zCIv82LwvnK1Es0Klq+o/bMYZnfgEjV2LTk= X-Received: by 2002:a2e:a489:: with SMTP id h9mr22497417lji.21.1621972676337; Tue, 25 May 2021 12:57:56 -0700 (PDT) MIME-Version: 1.0 References: <20210520185550.13688-1-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Tue, 25 May 2021 12:57:45 -0700 Message-ID: Subject: Re: [RFC PATCH bpf-next] bpf: Introduce bpf_timer To: Jamal Hadi Salim Cc: Cong Wang , David Miller , Daniel Borkmann , Andrii Nakryiko , John Fastabend , Lorenz Bauer , Linux Kernel Network Developers , bpf , kernel-team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, May 25, 2021 at 12:35 PM Jamal Hadi Salim wrote: > > On 2021-05-25 2:21 p.m., Alexei Starovoitov wrote: > > On Mon, May 24, 2021 at 9:59 PM Cong Wang wrote: > > > [..] > > In general the garbage collection in any form doesn't scale. > > The conntrack logic doesn't need it. The cillium conntrack is a great > > example of how to implement a conntrack without GC. > > For our use case, we need to collect info on all the flows > for various reasons (one of which is accounting of every byte and > packet). > So as a consequence - built-in GC (such as imposed by LRU) > cant interfere without our consent. The outcome of the last bpf office hours was a general agreement that we need new hooks in map update/delete operations (including auto-delete by LRU) that will trigger a bpf subprog. It might look very similar to the timer callback that is part of this patch, but instead of being called by the timer the LRU logic will call it. This way the subprog can transfer the data stored in the about-to-be-deleted map element into some other map or pass to user space via ringbuf or do any other logic.