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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 828ECC433DB for ; Wed, 24 Mar 2021 18:26:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 55AA661A1E for ; Wed, 24 Mar 2021 18:26:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237564AbhCXS0X (ORCPT ); Wed, 24 Mar 2021 14:26:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237549AbhCXS0C (ORCPT ); Wed, 24 Mar 2021 14:26:02 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D529C0613DF for ; Wed, 24 Mar 2021 11:26:01 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id b83so33414360lfd.11 for ; Wed, 24 Mar 2021 11:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T4N8DBRr0y3pnQ+GYU6PHDcjxPfiucyRsdqMiT4zgqA=; b=G6Mpzu8Fe8xOBs6JczHBtn8H0S8SCoL1f8ofwhnllztiurQZdtRKZfp9fQh5HV+Zha u8r+/u2f70a05QIFYREh/+taoxH++OKNA425bEESIlpfmAPzzV5mU2NydGChVd/0LHxY XEUViqaaHmjCHFqeIrZDAqfMHH8MMp0dHbZE7EKo00GjFbl8Bdqgyja6/NxSJdNGVYBp p4NJfhzdfQ9irpzalC4O5NRVp6DG1A3wZIOSxd0RZ0EMqHYYjg2haX0i1RyhustM4tnU C6LDzJlJpcs47PgnI0rbDzEzYUarNvEY9LvK/4MffNmBCPBazyFFVsd3/7ZhxAiY1+Nh a6OA== 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=T4N8DBRr0y3pnQ+GYU6PHDcjxPfiucyRsdqMiT4zgqA=; b=RvHNiCG+T90lN8YHvvvQtpBS6M0TwGd9FCHVypreeZDE3jPzoDb1Cg4AQn1Tc7jQCL Q0TK+PryO2Ny+bZ4KX2VyvRYZR7mMMjrxZJ0COu8gH7RhpiIsWBQa8GMtrGGKsC8iGLb RlADWpttx6gEzCZhmbLi2DRUD2zjhaFMBu0kGmGJXjuQ9U6dzanb4ovhInYm9ei7eelX XhiG/KKnSxosXGkD0AKcvdlmw5S2oN69EhsETzbDWXdYRLQPIaupr7BH/n1FGuEXIwbn bxzsmtJGdza8FCvlnZLGszgu//JgvbdPzESaEsQCjait66XF1RRfLu+LrVDrxR5o4oZJ DmaQ== X-Gm-Message-State: AOAM533AhbxN5q11WOfwF0fj+ijbT15xa0BWYiVzYj1q1bOyA3mnyFb/ Tauw6yNUD7fEGysCxzxUUkoLcTTNSHh3bIQpg1TcMQ== X-Google-Smtp-Source: ABdhPJzU2LObFzD9uVmKqWKo6lDRJghCKK6OF13SkHBoNeLbJ3Nm3c7JlGcLbbioSEdzB+IJyTohlPk5Vn9yuz2lt14= X-Received: by 2002:a19:e0d:: with SMTP id 13mr2611590lfo.549.1616610359718; Wed, 24 Mar 2021 11:25:59 -0700 (PDT) MIME-Version: 1.0 References: <20210316041645.144249-1-arjunroy.kdev@gmail.com> In-Reply-To: From: Shakeel Butt Date: Wed, 24 Mar 2021 11:25:47 -0700 Message-ID: Subject: Re: [mm, net-next v2] mm: net: memcg accounting for TCP rx zerocopy To: Arjun Roy Cc: Johannes Weiner , Arjun Roy , Andrew Morton , David Miller , netdev , Linux Kernel Mailing List , Cgroups , Linux MM , Eric Dumazet , Soheil Hassas Yeganeh , Jakub Kicinski , Michal Hocko , Yang Shi , Roman Gushchin Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 23, 2021 at 11:42 AM Arjun Roy wrote: > [...] > > To summarize then, it seems to me that we're on the same page now. > I'll put together a tentative v3 such that: > 1. It uses pre-charging, as previously discussed. > 2. It uses a page flag to delineate pages of a certain networking sort > (ie. this mechanism). > 3. It avails itself of up to 4 words of data inside struct page, > inside the networking specific struct. > 4. And it sets up this opt-in lifecycle notification for drivers that > choose to use it, falling back to existing behaviour without. > Arjun, if you don't mind, can you explain how the lifetime of such a page will look like? For example: Driver: page = dev_alloc_page() /* page has 1 ref */ dev_map_page(page) /* I don't think dev_map_page() takes a ref on page, so the ref remains 1. */ On incoming traffic the page goes to skb and which then gets assigned to a struct sock. Does the kernel increase refcnt of the page on these operations? The page gets mapped into user space which increments its refcnt. After processing the data, the application unmaps the page and its refcnt will be decremented. __put_page() will be called when refcnt reaches 0, so, the initial refcnt which the driver has acquired, has to be transferred to the next layer. So, I am trying to understand how that will work?