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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y78gEBXP9BuMq09O@x130>
Date:   Wed, 11 Jan 2023 12:46:08 -0800
From:   Saeed Mahameed <saeed@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org,
        Tariq Toukan <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>
Subject: Re: [net-next 08/15] net/mlx5e: Add hairpin debugfs files

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.