Subject: Re: [net-next 08/15] net/mlx5e: Add hairpin debugfs files

From: Saeed Mahameed <[email-masked]>
Date: Wed, 11 Jan 2023 12:46:08 -0800

On 11 Jan 10:34, Jakub Kicinski wrote:
>On Tue, 10 Jan 2023 21:30:38 -0800 Saeed Mahameed wrote:
>> +	debugfs_create_file("hairpin_num_queues", 0644, tc->dfs_root,
>> +			    &tc->hairpin_params, &fops_hairpin_queues);
>> +	debugfs_create_file("hairpin_queue_size", 0644, tc->dfs_root,
>> +			    &tc->hairpin_params, &fops_hairpin_queue_size);
>
>debugfs should be read-only, please LMK if I'm missing something,
>otherwise this series is getting reverted

I remember asking you about this and you said it's ok to use write for
debug features, this is needed for debugging performance bottlenecks.
hairpin + steering performance behaves differently between different
hardware versions and under different NIC/E-Switch configs, so it's really
important to have some control on some of these attributes when debugging.

Our dilemma was either to use devlink vendor params or a debug interface, 
since we are pretty sure that our NIC hairpin implementation
is unique as it uses software constructs (RQs/SQs) managed internally
by Firmware for abstraction of a TC redirect action, thus the only place
for this is either devlink vendor params or debugfs, we chose debugfs since
we want to keep this for debug purposes on production systems.

we also considered extending TC but again since this is unique to CX
architecture of the current chips, we didn't want to pollute TC.

Also devlink resource wasn't a good match since these resources don't
exist until a TC redirect action is offloaded.

Please let me know what you think and whether this is acceptable by you.