Received-SPF: pass (google.com: domain of linux-kernel+bounces-82745-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Huang Shijie <shijie@os.amperecomputing.com>
To: kuba@kernel.org
Cc: patches@amperecomputing.com,
	davem@davemloft.net,
	horms@kernel.org,
	edumazet@google.com,
	ast@kernel.org,
	dhowells@redhat.com,
	linyunsheng@huawei.com,
	aleksander.lobakin@intel.com,
	linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org,
	cl@os.amperecomputing.com,
	Huang Shijie <shijie@os.amperecomputing.com>
Subject: [PATCH v2] net: skbuff: set FLAG_SKB_NO_MERGE for skbuff_fclone_cache
Date: Tue, 27 Feb 2024 14:28:33 +0800
Message-Id: <20240227062833.7404-1-shijie@os.amperecomputing.com>
In-Reply-To: <CANn89iJoHDzfYfhcwVvR4m7DiVG-UfFNqm+D1WD-2wjOttk6ew@mail.gmail.com>
References: <CANn89iJoHDzfYfhcwVvR4m7DiVG-UfFNqm+D1WD-2wjOttk6ew@mail.gmail.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ab3DLWXeLqikx9aXFqx31ShbKio8+ibLrXFNcJJNNlZG7CtbAMsXSciYMAIS?=
 =?us-ascii?Q?ZwKs3Y+DxMifG9jJ49aMR3GSNpTqXGME+C8B+TmVsywMWx3Zoba2R9Np5C/s?=
 =?us-ascii?Q?1N78iutJNouURoCV29ICY98K+6Rl44V658e2IqE3srOUfYKObRMVTcWxqgb/?=
 =?us-ascii?Q?J+TgEbWDb48RouMIwOOv3ZLVLgMY6m2ualny7LK4PhRCAxtDHmeB1lpAxuKP?=
 =?us-ascii?Q?19Gun1DY/fXgj/IESEQLo+pcnOsf8cW8VUGBGZzpSmT27VEN+BNT4KE4D/7w?=
 =?us-ascii?Q?sCVbrq4+2AY3pgepcR32tKhv3piSaxpkGk+FNY2ONraYEAs5QzXLzw9qEzVv?=
 =?us-ascii?Q?eFXwbbdrQ9d+edw55T0Rf0BfgZPl/kZyqTM90g7QUFf9iAItjrvWIvMMV37u?=
 =?us-ascii?Q?RrKq9XKMwJuDG5/eEoZjoJyHIJt1YcfbEZ1hdZZWV+Cwj2DslXzjPZgHzqm/?=
 =?us-ascii?Q?xs7hyAuEYZV1UQjq1eaJxvivhkIcw5VLSqGpB5FKhvavyd05We7IogFj0Feb?=
 =?us-ascii?Q?6EsAl3xh1Y0qZR7Pf9GNP5z171RlhK85k4t9nCTrEtMvHq+S35hVZyiZuu37?=
 =?us-ascii?Q?ltxPTCmcXzjBEUKzKx1S9inro9fMHXmflX15yJpNkoGR26/dTtgAf0kbIV3s?=
 =?us-ascii?Q?9UHIJaduYP2vAeHPr8KsPacdJyStelnC2aWeDNsUHG4n/FmjH0JqdtyDEArz?=
 =?us-ascii?Q?vr5/9+jlZKZ+6er+ukLMc5/lvyxHudlqEDiC89DM8mNcRfUPsoX81hAB37ix?=
 =?us-ascii?Q?LC2s1F/J9DMPiuki6BweVZJq7tU54uqZSDcNvvrBnQMikteNohZrVuSgs14R?=
 =?us-ascii?Q?mq3SogxEPK5ZIjYpmrpipQbxcKE4k4+ot5i8ozwFwWVkUKZexSgf2CCDgiWo?=
 =?us-ascii?Q?Ec7VYvy76KwSMZw4dDcr46r2HJtuZbBPKkRXwrTjVIAc6qcawd5MUpxKQicf?=
 =?us-ascii?Q?zdkeXWKxBiPIJ2UhBH6Gk45mLX7QCnf7by4oQVv99ubGPdYJDRI3AAARU1aI?=
 =?us-ascii?Q?LC0c3hLk/1OsOYMZrNd8L3JCA3o1Iz/LnFmqFrWodr8dTbjlyteJN3Yp4zEe?=
 =?us-ascii?Q?q9vHI+f23C6FVIrl/bG8RFEv7nHGuODek0AeIzQyqlWofMYFsmfj4770lQT7?=
 =?us-ascii?Q?qGZLpiRhpWYaS/AiqZi43yqWR1dlHCYALI+m20y3xyoKPqykrgg2IYPE/UQX?=
 =?us-ascii?Q?cfoA5z5bFt5RjrUyZkeEXX3PqabebPDqnUFhP6HRwDSkMlis4IoDS/7uJTFg?=
 =?us-ascii?Q?6MSJjaFT6Lz+NebKHtPa7P8H/FASh07RG7Z3GDevU8mMrUHRdppuzA0Do7+u?=
 =?us-ascii?Q?3P4w84Z4k1iFerKSTmIWoWpyo1nD5Uj0T5mEtr6mmCnd63K6A5aHz//FEApK?=
 =?us-ascii?Q?VKhiMlihfkn8bkvOS4nSDWF45U+wirj8hgmVZEaGCJh+V3ixSyjOnujcjnrF?=
 =?us-ascii?Q?p+1ITDLeoWfND7jQIGrtZtXGX8w7Hv3F1FpOEetsdFTK7GpzpCmS/WIaM7eR?=
 =?us-ascii?Q?jIMZO6exk3txvnlteoO15bVpCBpmCdpvaLQZrnIpeL8quI+5f8dip/2u+DTo?=
 =?us-ascii?Q?9EzMuWFERg/AKR3CTQa510p6lOZNqgUBeQFk4QtbioGPTbhLpz049gfdZBx3?=
 =?us-ascii?Q?gw=3D=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54bebe46-5258-4e70-7d89-08dc375d692a
X-MS-Exchange-CrossTenant-AuthSource: PH0PR01MB7975.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2024 06:29:11.9634
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: EoipA8JqLKQ9ldPD4SfO4kW9SVlM3+bgmP+QHbg4gIRk/w9z2aDSuVuFAUZRPGhsFgQpyrw0ejtAWC+r/pgeTIA97hbzakXekHbMPNaiZtMGhw7CqzIXIYxJ5iS89kBi
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR01MB6172

Since we do not set FLAG_SKB_NO_MERGE for skbuff_fclone_cache,
the current skbuff_fclone_cache maybe not really allocated, it maybe
used an exist old kmem_cache. In NUMA, the fclone allocated by
alloc_skb_fclone() maybe in remote node.

So set FLAG_SKB_NO_MERGE for skbuff_fclone_cache to fix it.

Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
---
v1 --> v2:
       set FLAG_SKB_NO_MERGE for skbuff_fclone_cache in initialization.

v1: https://lkml.org/lkml/2024/2/20/121	
---
 net/core/skbuff.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 1f918e602bc4..5e3e130fb57a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5013,7 +5013,8 @@ void __init skb_init(void)
 	skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
 						sizeof(struct sk_buff_fclones),
 						0,
-						SLAB_HWCACHE_ALIGN|SLAB_PANIC,
+						SLAB_HWCACHE_ALIGN|SLAB_PANIC|
+						FLAG_SKB_NO_MERGE,
 						NULL);
 	/* usercopy should only access first SKB_SMALL_HEAD_HEADROOM bytes.
 	 * struct skb_shared_info is located at the end of skb->head,
-- 
2.40.1