[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <df18c2c0a9b160bfabe0e4ba7f251e789a9d7d7c.camel@mellanox.com>
Date: Thu, 25 Jun 2020 20:24:12 +0000
From: Saeed Mahameed <saeedm@...lanox.com>
To: Meir Lichtinger <meirl@...lanox.com>,
"andrew@...n.ch" <andrew@...n.ch>
CC: Aya Levin <ayal@...lanox.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kuba@...nel.org" <kuba@...nel.org>,
"rmk+kernel@...linux.org.uk" <rmk+kernel@...linux.org.uk>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] ethtool: Add support for 100Gbps per lane
link modes
On Thu, 2020-06-11 at 16:19 +0300, Meir Lichtinger wrote:
> On 02-May-20 18:08, Andrew Lunn wrote:
> > On Thu, Apr 30, 2020 at 04:41:05PM -0700, Saeed Mahameed wrote:
> > > From: Meir Lichtinger <meirl@...lanox.com>
> > >
> > > Define 100G, 200G and 400G link modes using 100Gbps per lane
> > >
> > > Signed-off-by: Meir Lichtinger <meirl@...lanox.com>
> > > CC: Andrew Lunn <andrew@...n.ch>
> > > Reviewed-by: Aya Levin <ayal@...lanox.com>
> > > Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>
> > > ---
> > > drivers/net/phy/phy-core.c | 17 ++++++++++++++++-
> > > include/uapi/linux/ethtool.h | 15 +++++++++++++++
> > > net/ethtool/common.c | 15 +++++++++++++++
> > > net/ethtool/linkmodes.c | 16 ++++++++++++++++
> > > 4 files changed, 62 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-
> > > core.c
> > > index 66b8c61ca74c..a71fc8b18973 100644
> > > --- a/drivers/net/phy/phy-core.c
> > > +++ b/drivers/net/phy/phy-core.c
> > > @@ -8,7 +8,7 @@
> > >
> > > const char *phy_speed_to_str(int speed)
> > > {
> > > - BUILD_BUG_ON_MSG(__ETHTOOL_LINK_MODE_MASK_NBITS != 75,
> > > + BUILD_BUG_ON_MSG(__ETHTOOL_LINK_MODE_MASK_NBITS != 90,
> > > "Enum ethtool_link_mode_bit_indices and phylib
> > > are out of sync. "
> > > "If a speed or mode has been added please
> > > update phy_speed_to_str "
> > > "and the PHY settings array.\n");
> > > @@ -78,12 +78,22 @@ static const struct phy_setting settings[] =
> > > {
> > > PHY_SETTING( 400000, FULL, 400000baseLR8_ER8_FR8_Full )
> > > ,
> > > PHY_SETTING( 400000, FULL, 400000baseDR8_Full )
> > > ,
> > > PHY_SETTING( 400000, FULL, 400000baseSR8_Full )
> > > ,
> > > + PHY_SETTING( 400000, FULL, 400000baseCR4_Full ),
> > > + PHY_SETTING( 400000, FULL, 400000baseKR4_Full ),
> > > + PHY_SETTING( 400000, FULL, 400000baseLR4_ER4_FR4_Full ),
> > Hi Mier, Saeed.
> >
> > Could you explain this last one? Seems unlikely this is a 12 pair
> > link
> > mode. So i assume it is four pair which can do LR4, ER4 or FR4?
> Correct
> > Can
> > you connect a 400000baseLR4 to a 400000baseER4 with a 10Km cable
> > and
> > it work?
>
> LR, ER & FR are using same technology – single mode fiber, w/WDM –
>
> and by design are fully interoperable but haven’t tested all
> combinations.
>
> > How do you know you have connected a 400000baseLR4 to a
> > 400000baseER4 with a 40Km and it is not expected to work, when
> > looking
> > at ethtool? I assume the EEPROM contents tell you if the module is
> > LR4, ER4, or FR4?
> >
> > Andrew
> Correct.
>
> In addition, this is the terminology exposed in 50 Gbps and we
> followed it.
>
Hi Andrew,
we are going to update the commit message with:
LR, ER and FR are defined as a single link mode because they are
using same technology and by design are fully interoperable.
EEPROM content indicates if the module is LR, ER, or FR, and the
user space ethtool decoder is planned to support decoding these
modes in the EEPROM.
Please let me know it this answer your questions, so we can re-spin
this patch.
Thanks,
Saeed.
Powered by blists - more mailing lists