Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4395306pxf; Tue, 23 Mar 2021 09:33:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDK36F0s7EGDNyZATuvZEecz2qf4oAp569mFF2IcUB9XAFZ3CWWUs+LGFLjyOaGTc4Yts7 X-Received: by 2002:a17:906:5a8f:: with SMTP id l15mr5767103ejq.462.1616517193057; Tue, 23 Mar 2021 09:33:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616517193; cv=none; d=google.com; s=arc-20160816; b=KBgposG5ev36J3908il09Q8/N9dechpa3fP/AW3gfKHSsJF8YLYsdW09VtH1exnPri X2CdRvJTYZHjdmbZetfsOdvSEzfcBMAbSxd6Mqa7PEX2ydU/9feSho62nlozKjpe+1Gd ku0weG7rUQrmA9r6VADcBLefRPc3sdvIyYnNrPn/5gWrilAqDCxsMjMMvAPW0O/oV2KO ShCpDTdk4Z/nHHHx1I9P7Ah5NiuxSnVITuEe1Uj8LGorid+TvEmVMPfnuLEfjyRBqk0L 9gLcRd/ALYUCnb9Jt7heTcM1QC+LQHO7dVqWhwRRtRIXgymb/7Ro7fdURRm47BVmLTo5 r5Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=wWC5laX9IDoCEzRycyyox6gck/DlbB0qqaILtReIe6U=; b=J4Lwjm76hVh5walVr96lYcjRSMNhBZbvwT6g1jIbm3m4T/QU5Ut9pueItJzd7XovJQ ZNi1u4MvJM76B3rtCWZfD76B//Y9sNNHPLIfOTEuH5Kh3ls6xMzVzUoYKsiGLkRAmojz AwhS3L3Lws/mo0EnpgA5vRd/LOUj62orQvcgODVl3vM5mSYMSZGAa1PDhRwrmnmmOKgh D+2rpJvluvoEytxroQkCTbSws/DtC4Kki8XTKXZT9sJE1bgaMy56Ad9lr7GtsmeTInyW ED96sY1eB/7EoDzsSS6j7HO4QH1/g4ll8/61rVPnXxlv2XsmKk/faMoz4yLgmp8MKUYR PfIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=iPUPVcwm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f16si13977583edy.444.2021.03.23.09.32.49; Tue, 23 Mar 2021 09:33:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=iPUPVcwm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233352AbhCWQ3r (ORCPT + 99 others); Tue, 23 Mar 2021 12:29:47 -0400 Received: from linux.microsoft.com ([13.77.154.182]:52298 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233316AbhCWQ3J (ORCPT ); Tue, 23 Mar 2021 12:29:09 -0400 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by linux.microsoft.com (Postfix) with ESMTPSA id 50D0D20B5684; Tue, 23 Mar 2021 09:29:09 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 50D0D20B5684 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1616516949; bh=wWC5laX9IDoCEzRycyyox6gck/DlbB0qqaILtReIe6U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iPUPVcwmfeMhzq1717y6BGYGBREhAWaqdduP7d4jTpKVtV7/H1LEu3fWDh1tj97fD EzOFr41L/K7sPQ4k6l1bIfC8h+m+n2wiQ8akx1j9Gei1ev0QY4cwdRcEvgjt3GAN+4 cVBtI+GtUiCejLxglJ5xKlArX1QLgS17MMB7jeaQ= Received: by mail-pj1-f46.google.com with SMTP id t18so10305421pjs.3; Tue, 23 Mar 2021 09:29:09 -0700 (PDT) X-Gm-Message-State: AOAM533CHoXVFEko43kX6Pj3KP+qarHUg5yqQpaIGOq0n7YJJ8BguPp/ 6RmmMMRGXDsQ66OweGtHARHevz3vyC8bj+Fhp80= X-Received: by 2002:a17:90a:f190:: with SMTP id bv16mr5136541pjb.187.1616516948785; Tue, 23 Mar 2021 09:29:08 -0700 (PDT) MIME-Version: 1.0 References: <20210322170301.26017-1-mcroce@linux.microsoft.com> <20210323154112.131110-1-alobakin@pm.me> <20210323170447.78d65d05@carbon> In-Reply-To: From: Matteo Croce Date: Tue, 23 Mar 2021 17:28:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers To: Ilias Apalodimas Cc: Jesper Dangaard Brouer , Alexander Lobakin , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Jonathan Lemon , "David S. Miller" , Jesper Dangaard Brouer , Lorenzo Bianconi , Saeed Mahameed , David Ahern , Saeed Mahameed , Andrew Lunn 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 5:10 PM Ilias Apalodimas wrote: > > On Tue, Mar 23, 2021 at 05:04:47PM +0100, Jesper Dangaard Brouer wrote: > > On Tue, 23 Mar 2021 17:47:46 +0200 > > Ilias Apalodimas wrote: > > > > > On Tue, Mar 23, 2021 at 03:41:23PM +0000, Alexander Lobakin wrote: > > > > From: Matteo Croce > > > > Date: Mon, 22 Mar 2021 18:02:55 +0100 > > > > > > > > > From: Matteo Croce > > > > > > > > > > This series enables recycling of the buffers allocated with the page_pool API. > > > > > The first two patches are just prerequisite to save space in a struct and > > > > > avoid recycling pages allocated with other API. > > > > > Patch 2 was based on a previous idea from Jonathan Lemon. > > > > > > > > > > The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref > > > > > users, and 5,6 enable the recycling on two drivers. > > > > > > > > > > In the last two patches I reported the improvement I have with the series. > > > > > > > > > > The recycling as is can't be used with drivers like mlx5 which do page split, > > > > > but this is documented in a comment. > > > > > In the future, a refcount can be used so to support mlx5 with no changes. > > > > > > > > > > Ilias Apalodimas (2): > > > > > page_pool: DMA handling and allow to recycles frames via SKB > > > > > net: change users of __skb_frag_unref() and add an extra argument > > > > > > > > > > Jesper Dangaard Brouer (1): > > > > > xdp: reduce size of struct xdp_mem_info > > > > > > > > > > Matteo Croce (3): > > > > > mm: add a signature in struct page > > > > > mvpp2: recycle buffers > > > > > mvneta: recycle buffers > > > > > > > > > > .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +- > > > > > drivers/net/ethernet/marvell/mvneta.c | 4 +- > > > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++---- > > > > > drivers/net/ethernet/marvell/sky2.c | 2 +- > > > > > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +- > > > > > include/linux/mm_types.h | 1 + > > > > > include/linux/skbuff.h | 33 +++++++++++-- > > > > > include/net/page_pool.h | 15 ++++++ > > > > > include/net/xdp.h | 5 +- > > > > > net/core/page_pool.c | 47 +++++++++++++++++++ > > > > > net/core/skbuff.c | 20 +++++++- > > > > > net/core/xdp.c | 14 ++++-- > > > > > net/tls/tls_device.c | 2 +- > > > > > 13 files changed, 138 insertions(+), 26 deletions(-) > > > > > > > > Just for the reference, I've performed some tests on 1G SoC NIC with > > > > this patchset on, here's direct link: [0] > > > > > > > > > > Thanks for the testing! > > > Any chance you can get a perf measurement on this? > > > > I guess you mean perf-report (--stdio) output, right? > > > > Yea, > As hinted below, I am just trying to figure out if on Alexander's platform the > cost of syncing, is bigger that free-allocate. I remember one armv7 were that > was the case. > > > > Is DMA syncing taking a substantial amount of your cpu usage? > > > > (+1 this is an important question) > > > > > > > > > > [0] https://lore.kernel.org/netdev/20210323153550.130385-1-alobakin@pm.me > > > > > > That would be the same as for mvneta: Overhead Shared Object Symbol 24.10% [kernel] [k] __pi___inval_dcache_area 23.02% [mvneta] [k] mvneta_rx_swbm 7.19% [kernel] [k] kmem_cache_alloc Anyway, I tried to use the recycling *and* napi_build_skb on mvpp2, and I get lower packet rate than recycling alone. I don't know why, we should investigate it. Regards, -- per aspera ad upstream