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  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]
Date:   Thu, 3 Nov 2016 18:59:11 +0200
From:   Gal Pressman <>
To:     "Mintz, Yuval" <>,
        Gal Pressman <>,
        "" <>,
        "John W. Linville" <>,
        Vidya Sagar Ravipati <>,
        Saeed Mahameed <>
Cc:     David Decotigny <>,
        Ben Hutchings <>
Subject: Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting

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

Powered by blists - more mailing lists