On 2026-05-08 at 09:19:04, Ratheesh Kannoth ([email protected]) 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 <[email protected]>
>+ >> + 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.
