[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALzJLG8Ns+fA7cJHVN9wj_6COF71mu5CPOYWK+UR3r+X7+paLA@mail.gmail.com>
Date: Wed, 9 Nov 2016 11:32:50 +0200
From: Saeed Mahameed <saeedm@....mellanox.co.il>
To: "Mintz, Yuval" <Yuval.Mintz@...ium.com>
Cc: Gal Pressman <galp@...lanox.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"John W. Linville" <linville@...driver.com>,
Vidya Sagar Ravipati <vidya@...ulusnetworks.com>,
Saeed Mahameed <saeedm@...lanox.com>,
David Decotigny <decot@...glers.com>,
Ben Hutchings <ben@...adent.org.uk>
Subject: Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting
On Wed, Nov 2, 2016 at 5:50 PM, Mintz, Yuval <Yuval.Mintz@...ium.com> wrote:
>> Sending RFC to get feedback for the following ethtool proposal:
>>
>> In some cases such as virtual machines and multi functions (SR-IOV), the actual
>> bandwidth exposed for each machine is not accurately shown in ethtool.
>> Currently ethtool shows only physical port link speed.
>> In our case we would like to show the virtual port operational link speed which
>> in some cases is less than the physical port speed.
>>
>> This will give users better visibility for the actual speed running on their device.
>>
>> $ ethtool ens6
>> ...
>> Speed: 50000Mb/s
>> Actual speed: 25000Mb/s
>
> Not saying this is a bad thing, but where exactly is it listed that ethtool has
> to show the physical port speed?
Well, looking at the ethtool fields you can clearly see those fields
refer only to physical properties of port connector module.
from this you can conclude that the speed field refers to the physical
port speed.
Settings for ens1f0:
Supported ports: [ FIBRE Backplane ]
Supported link modes: 1000baseKX/Full
10000baseKR/Full
40000baseKR4/Full
40000baseCR4/Full
40000baseSR4/Full
40000baseLR4/Full
25000baseCR/Full
25000baseKR/Full
25000baseSR/Full
50000baseCR2/Full
50000baseKR2/Full
100000baseKR4/Full
100000baseSR4/Full
100000baseCR4/Full
100000baseLR4_ER4/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 1000baseKX/Full
10000baseKR/Full
40000baseKR4/Full
40000baseCR4/Full
40000baseSR4/Full
40000baseLR4/Full
25000baseCR/Full
25000baseKR/Full
25000baseSR/Full
50000baseCR2/Full
50000baseKR2/Full
100000baseKR4/Full
100000baseSR4/Full
100000baseCR4/Full
100000baseLR4_ER4/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100000Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
> E.g., bnx2x shows the logical speed instead, and has been doing that for years.
> [Perhaps that's a past wrongness, but that's how it goes].
>
> And besides, one can argue that in the SR-IOV scenario the VF has no business
> knowing the physical port speed.
Yes for SR-IOV VFs one field (logical) is sufficient.
But in some cases on a native system (no SR-IOV nor virtualization)
there will be a need for both physical and logical speed reporting.
logical speed can be limited for several reasons (NIC Low power mode,
pci (width,gen), Internal HCA rate limiters, etc ... ).
Such information will be more than useful for system administrators
and will not be available if we decide to show only one field.
-Saeed.
Powered by blists - more mailing lists