Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp1463136rwo; Wed, 2 Aug 2023 14:44:22 -0700 (PDT) X-Google-Smtp-Source: APBJJlE85YPD7/qLVBG9gLJRXGmb0lR3kJKXaDFxVtq3pMosW2qmuQgZIoaCPwEFeU6JmnrY52Wa X-Received: by 2002:aa7:dace:0:b0:522:d801:7d07 with SMTP id x14-20020aa7dace000000b00522d8017d07mr8844574eds.10.1691012662406; Wed, 02 Aug 2023 14:44:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691012662; cv=none; d=google.com; s=arc-20160816; b=JgPtczoUIVKX6Lsf7+J78L2IFL3IxG+Dwj1HiuVDwF0BiALevpWUvncGLV7tNn62cn TraQ65F2gVNlRyRdNHQkDHCftt1UO1vqQuAFmt0GX5InzC/l1IpXcAN64YEZY+RlZrlr Mxpf6XSMhem4ibgTHrrVNXjU25iqnjLBr69wsETKRpBO1PD4skU3liSzPbEPCVJuHbT/ Izpspr1PI6QCJ7kcIjA4JSu/89T0lm0lYycc0rNMBgb9Qa+6cJ8rPNox/qMiAk8xZGE2 7R8pj/OrSSG14D+ESbJt8n6cwuYD3U7Th3FsPzh1GFJW4WBJJLQCZuLWCySbsD2tpTtD /s7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=Rl4S886Vpwd3CJZHEk13oRdx7cgpzo+FEUjXW+GY+fU=; fh=9td/jw969iLpLAYGpdhxsAlo+Zsj+pcV/J0+kv/1e8Y=; b=ltW/c/bAyoN/FRCG9BRxsGdw9lVhaMoCYIpz/QFnK9K3O3fqdrIBVGI88uLhVdxwq2 rdOvL47k+xHyDD65XeYpFMidRomQJPWMFDvQxXLNXgwsH2yXtwNCJFIwJ0YT0rkan+uw zIyS3L4EMXopHo/tMeEbmRT89oKyFyTQpfRmW7jCSfetmrlijbmAHIxNNpyZqh8x982Z S/FpJWHkShVlOO5OOXDUyJ6dxeK/ENPZ8ZT7XffSboZlk6m7wM2FS6uAvuKUFifopia3 stUyrcKf00KkIv8c1WrEpd9RKZ2bKrMfNEaQQtBL4z5Q0GLKoJjSoWphdgx3MS1YpJJ/ PMcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KpTuLIeD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n1-20020aa7c441000000b005222adc64f8si10984599edr.405.2023.08.02.14.43.57; Wed, 02 Aug 2023 14:44:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KpTuLIeD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232651AbjHBV30 (ORCPT + 99 others); Wed, 2 Aug 2023 17:29:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231350AbjHBV3Y (ORCPT ); Wed, 2 Aug 2023 17:29:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B8681FCB for ; Wed, 2 Aug 2023 14:29:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6FB5561B27 for ; Wed, 2 Aug 2023 21:29:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 452C0C433C8; Wed, 2 Aug 2023 21:29:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691011761; bh=s5Dw8JAhBv9uOSsXCyz3+dkPe5gQVfLZ75VqV/yv0LE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KpTuLIeDqDwUT5zzLPSj9dMfMPwqB6NB07gEGFDkfmm5hQkfIERn5Tb46wIx86a/t EDxFMTHRNMRYWHAgodmY67Y5L9JvVln7KNkh1i58i+Ufy+LmyI0ql1TaO+EMIG57KI xACefXuRYyqlHx2F0lczTCANaoVNR4PT5i2WXvszQRHUOLl/HJ/v7TIk68HYerpJJF V8qNQ0Xz5hAzIYG/sWTWk5zd7gUGbJRNAnuQdt8TKq/VLOcKjSS8zd099L+XbFLDoc tAlXWLgdAjiWbFYndzK6tEm12I7F+7/OVYFmdWxmZ/fHdfIbl9c6gPJVcBmz/XTn0R kJDgmaNvPMKaQ== Date: Wed, 2 Aug 2023 14:29:20 -0700 From: Jakub Kicinski To: Alexander Lobakin Cc: Yunsheng Lin , "David S. Miller" , Eric Dumazet , Paolo Abeni , Maciej Fijalkowski , Larysa Zaremba , Alexander Duyck , Jesper Dangaard Brouer , "Ilias Apalodimas" , Simon Horman , , Subject: Re: [PATCH net-next 5/9] page_pool: don't use driver-set flags field directly Message-ID: <20230802142920.4a777079@kernel.org> In-Reply-To: <0fe906a2-5ba1-f24a-efd8-7804ef0683b6@intel.com> References: <20230727144336.1646454-1-aleksander.lobakin@intel.com> <20230727144336.1646454-6-aleksander.lobakin@intel.com> <6f8147ec-b8ad-3905-5279-16817ed6f5ae@intel.com> <0fe906a2-5ba1-f24a-efd8-7804ef0683b6@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 1 Aug 2023 15:36:33 +0200 Alexander Lobakin wrote: > >> You would need a separate patch to convert all the page_pool_create() > >> users then either way. > >> And it doesn't look really natural to me to pass both driver-set params > >> and driver-set flags as separate function arguments. Someone may then > >> think "why aren't flags just put in the params itself". The fact that > >> Page Pool copies the whole params in the page_pool struct after > >> allocating it is internals, page_pool_create() prototype however isn't. > >> Thoughts? =20 > >=20 > > It just seems odd to me that dma_map and page_frag is duplicated as we > > seems to have the same info in the page_pool->p.flags. =20 >=20 > It's just because we copy the whole &page_pool_params passed by the > driver. It doesn't look good to me to define a new structure and copy > the values field-by-field just to avoid duplicating 3 bits :s FWIW I'm tempted to do something like the patch below (an obvious move, I suspect). I want to add another pointer (netdev) to the params and=20 I don't want it to eat up bytes in the first cache line. The patch is incomplete, we need to stash a one-bit indication in=20 the first cache line to know init_callback is not present without having to look at @slow. I'll defer doing that cleanly until your patches land. With this in place we can move flags outside of @fast, and interpret it manually while copying all the other members in one go. --->8------------------------------- =46rom c1290e74c3ec54090a49d0c88ca9d56c3bede825 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Wed, 2 Aug 2023 14:16:51 -0700 Subject: [PATCH] net: page_pool: split the page_pool_params into fast and s= low struct page_pool is rather performance critical and we use 16B of the first cache line to store 2 pointers used only by test code. Future patches will add more informational (non-fast path) attributes. It's convenient for the user of the API to not have to worry which fields are fast and which are slow path. Use struct groups to split the params into the two categories internally. Signed-off-by: Jakub Kicinski --- include/net/page_pool.h | 31 +++++++++++++++++++------------ net/core/page_pool.c | 7 ++++--- 2 files changed, 23 insertions(+), 15 deletions(-) diff --git a/include/net/page_pool.h b/include/net/page_pool.h index 73d4f786418d..f0267279a8cd 100644 --- a/include/net/page_pool.h +++ b/include/net/page_pool.h @@ -83,18 +83,22 @@ struct pp_alloc_cache { * @offset: DMA sync address offset for PP_FLAG_DMA_SYNC_DEV */ struct page_pool_params { - unsigned int flags; - unsigned int order; - unsigned int pool_size; - int nid; - struct device *dev; - struct napi_struct *napi; - enum dma_data_direction dma_dir; - unsigned int max_len; - unsigned int offset; + struct_group_tagged(page_pool_params_fast, fast, + unsigned int flags; + unsigned int order; + unsigned int pool_size; + int nid; + struct device *dev; + struct napi_struct *napi; + enum dma_data_direction dma_dir; + unsigned int max_len; + unsigned int offset; + ); + struct_group_tagged(page_pool_params_slow, slow, /* private: used by test code only */ - void (*init_callback)(struct page *page, void *arg); - void *init_arg; + void (*init_callback)(struct page *page, void *arg); + void *init_arg; + ); }; =20 #ifdef CONFIG_PAGE_POOL_STATS @@ -177,7 +181,7 @@ static inline u64 *page_pool_ethtool_stats_get(u64 *dat= a, void *stats) #endif =20 struct page_pool { - struct page_pool_params p; + struct page_pool_params_fast p; =20 struct delayed_work release_dw; void (*disconnect)(void *); @@ -236,6 +240,9 @@ struct page_pool { refcount_t user_cnt; =20 u64 destroy_cnt; + + /* Slow/Control-path information follows */ + struct page_pool_params_slow slow; }; =20 struct page *page_pool_alloc_pages(struct page_pool *pool, gfp_t gfp); diff --git a/net/core/page_pool.c b/net/core/page_pool.c index 5d615a169718..fc3f6878a002 100644 --- a/net/core/page_pool.c +++ b/net/core/page_pool.c @@ -173,7 +173,8 @@ static int page_pool_init(struct page_pool *pool, { unsigned int ring_qsize =3D 1024; /* Default */ =20 - memcpy(&pool->p, params, sizeof(pool->p)); + memcpy(&pool->p, ¶ms->fast, sizeof(pool->p)); + memcpy(&pool->slow, ¶ms->slow, sizeof(pool->slow)); =20 /* Validate only known flags were used */ if (pool->p.flags & ~(PP_FLAG_ALL)) @@ -372,8 +373,8 @@ static void page_pool_set_pp_info(struct page_pool *poo= l, { page->pp =3D pool; page->pp_magic |=3D PP_SIGNATURE; - if (pool->p.init_callback) - pool->p.init_callback(page, pool->p.init_arg); + if (pool->slow.init_callback) + pool->slow.init_callback(page, pool->slow.init_arg); } =20 static void page_pool_clear_pp_info(struct page *page) --=20 2.41.0