netdev - RE: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link partners for X550 SFI"

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:
 <AM6PR04MB549643403E321AA968037310EAF42@AM6PR04MB5496.eurprd04.prod.outlook.com>
Date: Thu, 23 May 2024 16:18:48 +0000
From: Jeff Daly <jeffd@...icom-usa.com>
To: Jacob Keller <jacob.e.keller@...el.com>, "kernel.org-fo5k2w@...arbi.fr"
	<kernel.org-fo5k2w@...arbi.fr>, Simon Horman <horms@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link
 partners for X550 SFI"

Jacob, initially a config flag option was put forward but because of the maturity of the driver, that option was shot down by the maintainers.

> -----Original Message-----
> From: Jacob Keller <jacob.e.keller@...el.com>
> Sent: Thursday, May 23, 2024 12:15 PM
> To: kernel.org-fo5k2w@...arbi.fr; Jeff Daly <jeffd@...icom-usa.com>; Simon
> Horman <horms@...nel.org>
> Cc: netdev@...r.kernel.org
> Subject: Re: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link
> partners for X550 SFI"
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments.
> 
> 
> On 5/21/2024 2:05 PM, Jacob Keller wrote:
> >
> >
> > On 5/21/2024 10:12 AM, kernel.org-fo5k2w@...arbi.fr wrote:
> >> If any of you have the skills to develop a patch that tries to satisfy everyone,
> please know that I'm always available for testing on my hardware. If Jeff also
> has the possibilities, it's not impossible that we could come to a consensus. All
> we'd have to do would be to test the behavior of our equipment in the
> problematic situation.
> >>
> >
> > I would love a solution which fixes both cases. I don't currently have
> > any idea what it would be.
> >
> 
> It looks like netdev pulled the revert. Given the lack of a full understanding of the
> original fix posted from Jeff, I think this is the right decision.
> 
> >> Isn't there someone at Intel who can contribute their expertise on the
> underlying technical reasons for the problem (obviously level 1 OSI) in order to
> guide us towards a state-of-the-art solution?
> >>
> 
> I did create an internal ticket here to track and try to get a reproduction so that
> some of our link experts can diagnose the issue being seen.
> 
> I hope to have news I can report on this soon.
> 
> > I guess there is the option of some sort of toggle via
> > ethtool/otherwise to allow selection... But users might try to enable
> > this when link is faulty and end up hitting the case where once we try
> > the AN-37, the remote switch refuses to try again until a cycle.
> >
> 
> Given that we have two cases where our current understanding is a need for
> mutually exclusive behavior, we (Intel) would be open to some sort of config
> option, flag, or otherwise toggle to enable the Silicom folks without breaking
> everything else. I don't know what the acceptance for such an idea is with the
> rest of the community.
> 
> I hope that internal reproduction task above may lead to a better understanding
> and possibly a fix that can resolve both cases.