Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting

[Saeed Mahameed]

On Wed, Nov 2, 2016 at 5:50 PM, Mintz, Yuval  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: 5Mb/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
   1baseKR/Full
   4baseKR4/Full
   4baseCR4/Full
   4baseSR4/Full
   4baseLR4/Full
   25000baseCR/Full
   25000baseKR/Full
   25000baseSR/Full
   5baseCR2/Full
   5baseKR2/Full
   10baseKR4/Full
   10baseSR4/Full
   10baseCR4/Full
   10baseLR4_ER4/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes:  1000baseKX/Full
   1baseKR/Full
   4baseKR4/Full
   4baseCR4/Full
   4baseSR4/Full
   4baseLR4/Full
   25000baseCR/Full
   25000baseKR/Full
   25000baseSR/Full
   5baseCR2/Full
   5baseKR2/Full
   10baseKR4/Full
   10baseSR4/Full
   10baseCR4/Full
   10baseLR4_ER4/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 10Mb/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.

Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting

[Rick Jones]

And besides, one can argue that in the SR-IOV scenario the VF has no business
knowing the physical port speed.



Good point, but there are more use-cases we should consider.
For example, when using Multi-Host/Flex-10/Multi-PF each PF should
be able to query both physical port speed and actual speed.


Despite my email address, I'm not fully versed on VC/Flex, but I have 
always been under the impression that the flexnics created were, 
conceptually, "distinct" NICs considered independently of the physical 
port over which they operated.  Tossing another worm or three into the 
can, while "back in the day" (when some of the first ethtool changes to 
report speeds other than the "normal" ones went in) the speed of a 
flexnic was fixed, today, it can actually operate in a range.  From a 
minimum guarantee to an "if there is bandwidth available" cap.


rick jones

Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting

[Gal Pressman]

On 02/11/2016 17:50, Mintz, Yuval 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: 5Mb/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?
> 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.
> 

Good point, but there are more use-cases we should consider.
For example, when using Multi-Host/Flex-10/Multi-PF each PF should
be able to query both physical port speed and actual speed.

Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting

[Or Gerlitz]

On Wed, Nov 2, 2016 at 5:35 PM, Gal Pressman  wrote:

> 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.

You mean that if you rate-limit a VF from the host they will be able
to actually query that
and report it to their OS?

RE: [PATCH RFC 0/2] ethtool: Add actual port speed reporting

[Mintz, Yuval]

> 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: 5Mb/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?
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.