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: <ff07fe13-9fcc-214f-fe56-fa29c4b022ad@intel.com>
Date:   Wed, 11 Aug 2021 00:38:07 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>
CC:     Ido Schimmel <idosch@...sch.org>,
        "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:31 PM, Andrew Lunn wrote:
> On Tue, Aug 10, 2021 at 03:06:36PM -0700, 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.
>>
>> I think the question was the inverse - why not always shut down the
>> port if the interface is brought down?
> 
> Humm. Something does not seem right here. I would assume that when you
> administratively configure the link down, the SERDES in the MAC would
> stop sending anything. So the module has nothing to send. The link
> peer SERDES then looses sync, and reports that upwards as carrier
> lost.
> 

Right....

> Does the i40e and ice leave its SERDES running when the link is
> configured down? Or is the switch FUBAR and does not consider SERDES
> loss of sync as carrier down?
>


It's not clear to me. I tried to test with the driver, and it looks like
upstream doesn't yet have the link-down-on-close merged into net-next,
so I grabbed our out-of-tree driver.

Interestingly, both ip link show and ethtool do not report link as up
when the device is closed (ip link set enp175f0s0 down).....

So... whatever difference link-down-on-close makes we're definitely not
reporting things up.


I don't have a setup to confirm anything else right now unfortunately,
but I suspect something is wrong with the implementation of
link-down-on-close (at the very least it seems like we should still be
reporting LOWER_UP.... no?)

Unless there's some other weirdness like with QSFP or other
multi-port-single-cable setups?

I even tried adding some VFs and I see that regardless of whether
link-down-on-close is set, I can see link up on the VF....

Hmmmmm.

> Ido's use case does seem to be different. The link is down. Do we want
> to leave the module active, probably sending a bit stream of all 0,
> maybe noise, or do we want to power the module down, so it does not
> send anything at all.
> 
>      Andrew
> 

Right, I think these two cases are very different.