netdev - Re: [net-next 03/15] net/mlx5e: PFC stall prevention support

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: <20180325161815.GB12820@lunn.ch>
Date:   Sun, 25 Mar 2018 18:18:15 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Gal Pressman <galp@...lanox.com>
Cc:     Saeed Mahameed <saeedm@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Inbar Karmy <inbark@...lanox.com>
Subject: Re: [net-next 03/15] net/mlx5e: PFC stall prevention support

> > Shouldn't you map a value of MLX5E_PFC_PREVEN_AUTO_TOUT_MSEC back to 
> > PFC_STORM_PREVENTION_AUTO?
> 
> We discussed this point internally, mapping MLX5E_PFC_PREVEN_AUTO_TOUT_MSEC (100) to
> PFC_STORM_PREVENTION_AUTO might cause confusion when the user explicitly asks for 100msec timeout
> and gets auto in his following query.
> Also, this way the "auto" timeout is visible to the user, which might help him get an initial
> clue of which values are recommended.

Yes, this is a fair point, which is why i asked the question. Either
way, it can cause confusion. 'I configured it to auto, but it always
returns 100, not auto.'

Whatever is decided, it should be consistent across drivers. So please
add some documentation to the ethtool header file about what is
expected.

	Andrew