From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D474B2264AA; Mon, 11 May 2026 02:26:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=67.231.148.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778466365; cv=none; b=dAbi738uIr45wLlP81bXeSblA6kdNGfsWDBcjzOh69XzGByZMBAdCGScu8os7YhGLjizeNK7jobfFS4vlyC0k65Z9VEYgWS/8C5r1rv1JiVWaasqIAlO4GKJ2TmKXPMaxmlKsRBQEfM1obAQ96kdCMiQ4RSuHNtPZsfRV9fsMBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778466365; c=relaxed/simple; bh=mpHg8OjAND8f6K3OWAeTnzU2owwDVVyBgT70eqXDjzA=; h=Date:From:To:CC:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=joAdXxNgQdvgedCnhR/IOk9SXacHA/gcbLirl2iER+MzTyzjJ42dvp4q+uu2p/eXgJTjbu2RREKahn+Jybybu0Emt+qv18MfGUHs/FuvPOEBTOQJpwnx+PKGklEvHf1LZNtpj+ez/RzwAbtDYcs02DS9YwrZwhRe2NfaV6848s8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=marvell.com; spf=pass smtp.mailfrom=marvell.com; dkim=pass (2048-bit key) header.d=marvell.com header.i=@marvell.com header.b=dmOq99D8; arc=none smtp.client-ip=67.231.148.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=marvell.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=marvell.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=marvell.com header.i=@marvell.com header.b="dmOq99D8" Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 64ANe1DJ3060082; Sun, 10 May 2026 19:25:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pfpt0220; bh=HEXQPr43bSHyCbZRi+CP6TzHe /9mn4IyWPnqB/ie+PE=; b=dmOq99D8CbrHyG23rEgEOVCFtZWHGgGVWCyv41EHU ZTvJA5ramOU+OupdyjKsqG8erApLuP8jW9TMHEKtnkcO726CmGPQXjh/DtLyaAMZ Oj7rTcGHO44uX1nfKnE6J77PDLN/yozr6zBsmPBwP4elRWIL8WJREyhlp0wAZQia PoJwvJvTxF8Bi5QQJ0mP3i+Py7Io9GQxa05GP3h228vjmhXNhm919voj09Pt99CH jbjOXUR+6aYafisWmK5L2oZ8Z6vMP2WsrMKYDiRVMlCfOmtDl8OfHdOIbZ/XG6Kj QQ1Bi3q4pAANE4doW+rD+0nBW5CCq4ra42guZBjhAh6SA== Received: from dc6wp-exch02.marvell.com ([4.21.29.225]) by mx0a-0016f401.pphosted.com (PPS) with ESMTPS id 4e229jkea6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 May 2026 19:25:20 -0700 (PDT) Received: from DC6WP-EXCH02.marvell.com (10.76.176.209) by DC6WP-EXCH02.marvell.com (10.76.176.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.25; Sun, 10 May 2026 19:25:19 -0700 Received: from maili.marvell.com (10.69.176.80) by DC6WP-EXCH02.marvell.com (10.76.176.209) with Microsoft SMTP Server id 15.2.1544.25 via Frontend Transport; Sun, 10 May 2026 19:25:19 -0700 Received: from rkannoth-OptiPlex-7090 (unknown [10.28.36.165]) by maili.marvell.com (Postfix) with SMTP id 18C293F7088; Sun, 10 May 2026 19:25:09 -0700 (PDT) Date: Mon, 11 May 2026 07:55:08 +0530 From: Ratheesh Kannoth To: , , , , CC: , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v12 net-next 1/9] octeontx2-af: npc: cn20k: debugfs enhancements Message-ID: References: <20260508034912.4082520-1-rkannoth@marvell.com> <20260508034912.4082520-2-rkannoth@marvell.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20260508034912.4082520-2-rkannoth@marvell.com> X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNTExMDAyNSBTYWx0ZWRfX5L1/lLn/ICBU bhBoraIq0d1+kZonQd+pZui59fbV6NvOHhn4uZNcLoam1RgPv2duxNnIrIQv+i9I1TWPAkWcSve GyiIPJFGeVucOhUmTUZ+1lYtuNcC/6j3tUY0mHgzz4vIFesFmvCbP0W9YwPk6J3euAkb3C8DPZk EkcTZFZenOHc2qp262Lb/+rPaXsGF4eY4NcLuHRWETZDeUPjmnA/vwiQE5G+ltNW6fr+kO9Iaex t1XpKIiBL+oRePaeaKw7sZQq2j+aLfaIwBigZpD1Vo1jZGT4nNXDTx5oNmewPSMVWWMnpXkCSmn HSrjiwyVxcfQsWbG/b9gjcwXi9MD7pIxHlori6vTndUo372/jM8zv51KVBwNPdQJeCew4RE/LSK +20edk4Shglms9GELf3Ef+Ey73Dfqvcy8TVYgkEsKd2jJsueEP4bt6tVx6O9jnGLt8h3A+kFKuQ fxJYkKoO69tXXYn2Htw== X-Proofpoint-GUID: NpbUxd_Gso3XUBF29nYphxGlrKK7WwEC X-Proofpoint-ORIG-GUID: NpbUxd_Gso3XUBF29nYphxGlrKK7WwEC X-Authority-Analysis: v=2.4 cv=LdAMLDfi c=1 sm=1 tr=0 ts=6a013e10 cx=c_pps a=gIfcoYsirJbf48DBMSPrZA==:117 a=gIfcoYsirJbf48DBMSPrZA==:17 a=kj9zAlcOel0A:10 a=NGcC8JguVDcA:10 a=VkNPw1HP01LnGYTKEx00:22 a=l0iWHRpgs5sLHlkKQ1IR:22 a=EAYMVhzMl8SCOHhVQcBL:22 a=M5GUcnROAAAA:8 a=jt9vlcwtPs7hvUNDCZkA:9 a=CjuIK1q_8ugA:10 a=OBjm3rFKGHvpk9ecZwUJ:22 a=Oh551-UHZqmTy8JkqTUo:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-05-11_01,2026-05-08_02,2025-10-01_01 On 2026-05-08 at 09:19:04, Ratheesh Kannoth (rkannoth@marvell.com) wrote: > Improve MCAM visibility and field debugging for CN20K NPC. > > - Extend "mcam_layout" to show enabled (+) or disabled state per entry > so status can be verified without parsing the full "mcam_entry" dump. > - Add "dstats" debugfs entry: reports recently hit MCAM indices with > packet counts; stats are cleared on read so each read shows deltas. > - Add "mismatch" debugfs entry: lists MCAM entries that are enabled > but not explicitly allocated, helping diagnose allocation/field issues. > > Signed-off-by: Ratheesh Kannoth >+ >> + snprintf(buff, sizeof(buff), "%u\t%#04x\t%llu\n", >> + mcam_idx, pf, delta); >> + seq_puts(s, buff); >> + >> + dstats[bank][idx] = stats; >> + } >> + } >> + >> + mutex_unlock(&stats_lock); >> + return 0; >> +} >> + >> +/* "%u\t%#04x\t%llu\n" needs less than 64 characters to print */ >> +#define TOTAL_SZ (MAX_NUM_BANKS * MAX_NUM_SUB_BANKS * MAX_SUBBANK_DEPTH * 64) >> +DEFINE_OCTEONTX2_DEBUGFS_ATTRIBUTE_WITH_SIZE(npc_mcam_dstats, TOTAL_SZ); >Will this single_open_size() allocation reliably succeed on a running system? >Because single_open_size() uses kmalloc(), it requires a physically >contiguous memory block. TOTAL_SZ is the product of multiple maximum >hardware limits, which can be hundreds of kilobytes. This could result >in a high-order allocation that fails with an out of memory error due to >fragmentation. No. single_open_size() is calling seq_buf_alloc() which uses kvmalloc.