netdev - Re: [RFC PATCH net-next 1/8] ethtool: Add ability to control transceiver modules' low power mode

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: <4512fede-0581-34fc-e609-dc986c468daa@intel.com>
Date:   Tue, 10 Aug 2021 22:18:12 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Ido Schimmel <idosch@...sch.org>, Andrew Lunn <andrew@...n.ch>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "pali@...nel.org" <pali@...nel.org>,
        "vadimp@...dia.com" <vadimp@...dia.com>,
        "mlxsw@...dia.com" <mlxsw@...dia.com>,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next 1/8] ethtool: Add ability to control
 transceiver modules' low power mode

On 8/10/2021 3:06 PM, Jakub Kicinski wrote:
> On Tue, 10 Aug 2021 22:00:51 +0000 Keller, Jacob E wrote:
>>>> Jake do you know what the use cases for Intel are? Are they SFP, MAC,
>>>> or NC-SI related?  
>>>
>>> I went through all the Intel drivers that implement these operations and
>>> I believe you are talking about these commits:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c3880bd159d431d06b687b0b5ab22e24e6ef0070
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5ec9e2ce41ac198de2ee18e0e529b7ebbc67408
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab4ab73fc1ec6dec548fa36c5e383ef5faa7b4c1
>>>
>>> There isn't too much information about the motivation, but maybe it has
>>> something to do with multi-host controllers where you want to prevent
>>> one host from taking the physical link down for all the other hosts
>>> sharing it? I remember such issues with mlx5.
>>>   
>>
>> Ok, I found some more information here. The primary motivation of the
>> changes in the i40e and ice drivers is from customer requests asking to
>> have the link go down when the port is administratively disabled. This
>> is because if the link is down then the switch on the other side will
>> see the port not having link and will stop trying to send traffic to it.
>>
>> As far as I can tell, the reason its a flag is because some users wanted
>> the behavior the other way.
>>
>> I'm not sure it's really related to the behavior here.
>>
>> For what it's worth, I'm in favor of containing things like this into
>> ethtool as well.
> 
> I think the question was the inverse - why not always shut down the
> port if the interface is brought down?
> 

That... is a better question yes. Unfortunately so far I haven't found
any argument for not doing this. Only a bit about many requests to have
this behavior. It might just be inertia to maintain current behavior by
default...