[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6d8e9b8-1438-40c3-82f4-ec905ce2a862@habana.ai>
Date: Sun, 30 Jun 2024 07:11:59 +0000
From: Omer Shpigelman <oshpigelman@...ana.ai>
To: Andrew Lunn <andrew@...n.ch>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"ogabbay@...nel.org" <ogabbay@...nel.org>,
Zvika Yehudai <zyehudai@...ana.ai>
Subject: Re: [PATCH 09/15] net: hbl_en: add habanalabs Ethernet driver
On 6/26/24 17:13, Andrew Lunn wrote:
>> Here is the output:
>> $ ethtool eth0
>> Settings for eth0:
>> Supported ports: [ FIBRE Backplane ]
>> Supported link modes: 100000baseKR4/Full
>> 100000baseSR4/Full
>> 100000baseCR4/Full
>> 100000baseLR4_ER4/Full
>> Supported pause frame use: Symmetric
>> Supports auto-negotiation: Yes
>> Supported FEC modes: Not reported
>> Advertised link modes: 100000baseKR4/Full
>> 100000baseSR4/Full
>> 100000baseCR4/Full
>> 100000baseLR4_ER4/Full
>> Advertised pause frame use: Symmetric
>> Advertised auto-negotiation: Yes
>> Advertised FEC modes: Not reported
>> Link partner advertised link modes: Not reported
>> Link partner advertised pause frame use: No
>> Link partner advertised auto-negotiation: Yes
>> Link partner advertised FEC modes: Not reported
>> Speed: 100000Mb/s
>> Duplex: Full
>> Auto-negotiation: on
>>
>> There are few points to mention:
>> 1. We don't allow to modify the advertised link modes so by definition the
>> advertised ones are a copy of the supported ones.
>
> So there is no way to ask it use to use 100000baseCR4/Full, for
> example? You would normally change the advertised modes to just that
> one link mode, and then it has no choice. It either uses
> 100000baseCR4/Full, or it does not establish a link.
>
No, our FW doesn't support it as we have no use case for that.
> Also, my experience with slower modules is that one supporting
> 2500BaseX can also support 1000BaseX. However, there is no auto-neg
> defined for speeds, just pause. So if the link peer only supports
> 1000BaseX, you don't get link. What you typically see is:
>
> $ ethtool eth0
> Settings for eth0:
> Supported ports: [ FIBRE Backplane ]
> Supported link modes: 1000baseX
> 2500baseX
> Supported pause frame use: Symmetric
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 2500baseX
> Advertised pause frame use: Symmetric
>
> and then you use ethtool to change advertising to 1000baseX and then
> you get link. Can these modules support slower speeds?
>
No, we support a single speed.
>> 2. Reading the peer advertised link modes is not supported so we don't
>> report them (similarly to some other vendors).
>
> Not supported by your firmware? Or not supported by the modules?
>
Let me explain it better - Gaudi2 is not a general purpose Ethernet NIC.
Its goal is to support any Ethernet traffic that is needed for enabling
the scaling of AI neural networks training as part of HLS2 server:
https://www.intel.com/content/www/us/en/content-details/784778/hls-gaudi-2-deep-learning-server-datasheet.html
Hence, in contrary to a general purpose Ethernet NIC, it is well known who
is our peer and what are its capabilities - it is a Gaudi2 NIC or a
switch.
Technically we can read the advertised link partner modes but we had no
demand for that because the driver and the user are well aware of who is
on the other side.
Reading it from the FW will be the same as having it hard coded because
the value is already known (otherwise we won't have a link). I can add it
to lp_advertising if necessary although per my check most vendors don't
report it either.
> Andrew
Powered by blists - more mailing lists