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: <ac5bf8cd-c30a-0c36-a6ca-a95a8ed0d152@nvidia.com>
Date:   Sun, 15 Jan 2023 12:04:58 +0200
From:   Gal Pressman <gal@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        "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>
Subject: Re: [net-next 08/15] net/mlx5e: Add hairpin debugfs files

On 13/01/2023 0:20, Jakub Kicinski wrote:
> On Thu, 12 Jan 2023 11:17:07 +0200 Gal Pressman wrote:
>> As Saeed said, we discussed different APIs for this, debugfs seemed like
>> the best fit as we don't want users to change the queues parameters for
>> production purposes. Debugfs makes it clear that these params aren't for
>> your ordinary use, and allows us to be more flexible over time if needed
>> (we don't necessarily have to keep these files there forever, if our
>> hardware implementation changes for example).
> 
> You cut off the original question in your reply, it was:
> 
>   Can you expand on the use of this params when debugging?
> 
> IOW why do you need to change this configuration during debug.

The hairpin queues are different than other queues in the driver as they
are controlled by the device (refill, completion handling, etc.).
Hardware configuration can make a difference in performance when working
with hairpin, things that wouldn't necessarily affect regular queues the
driver uses. The debugging process is also more difficult as the driver
has little control/visibility over these.

At the end of the day, the debug process *is* going to be playing with
the queue size/number, this allows us to potentially find a number that
releases the bottleneck and see how it affects other stages in the pipe.
Since these cases are unlikely to happen, and changing of these
parameters can affect the device in other ways, we don't want people to
just increase them when they encounter performance issues, especially
not in production environments.

Does that make sense?