From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Jones Subject: Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting Date: Thu, 3 Nov 2016 10:09:08 -0700 Message-ID: References: <1478100914-23610-1-git-send-email-galp@mellanox.com> <7a681afa-a5fa-3039-873c-d13617484cc9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: David Decotigny , Ben Hutchings To: Gal Pressman , "Mintz, Yuval" , Gal Pressman , "netdev@vger.kernel.org" , "John W. Linville" , Vidya Sagar Ravipati , Saeed Mahameed Return-path: Received: from g4t3427.houston.hpe.com ([15.241.140.73]:45217 "EHLO g4t3427.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759000AbcKCRJM (ORCPT ); Thu, 3 Nov 2016 13:09:12 -0400 In-Reply-To: <7a681afa-a5fa-3039-873c-d13617484cc9@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: >> 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