From: Rick Jones <rick.jones2@hpe.com>
To: Gal Pressman <galp.dev@gmail.com>,
"Mintz, Yuval" <Yuval.Mintz@cavium.com>,
Gal Pressman <galp@mellanox.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"John W. Linville" <linville@tuxdriver.com>,
Vidya Sagar Ravipati <vidya@cumulusnetworks.com>,
Saeed Mahameed <saeedm@mellanox.com>
Cc: David Decotigny <decot@googlers.com>,
Ben Hutchings <ben@decadent.org.uk>
Subject: Re: [PATCH RFC 0/2] ethtool: Add actual port speed reporting
Date: Thu, 3 Nov 2016 10:09:08 -0700 [thread overview]
Message-ID: <fce609ee-3dfd-b71b-b9d9-528d80d18081@hpe.com> (raw)
In-Reply-To: <7a681afa-a5fa-3039-873c-d13617484cc9@gmail.com>
>> 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
next prev parent reply other threads:[~2016-11-03 17:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 15:35 [PATCH RFC 0/2] ethtool: Add actual port speed reporting Gal Pressman
2016-11-02 15:35 ` [PATCH RFC 1/2] ethtool: Add get actual port speed Gal Pressman
2016-11-02 15:35 ` [PATCH RFC 2/2] net/mlx5e: Add support for ethtool get actual speed callback Gal Pressman
2016-11-02 15:50 ` [PATCH RFC 0/2] ethtool: Add actual port speed reporting Mintz, Yuval
2016-11-03 16:59 ` Gal Pressman
2016-11-03 17:09 ` Rick Jones [this message]
2016-11-09 9:32 ` Saeed Mahameed
2016-11-03 7:02 ` Or Gerlitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fce609ee-3dfd-b71b-b9d9-528d80d18081@hpe.com \
--to=rick.jones2@hpe.com \
--cc=Yuval.Mintz@cavium.com \
--cc=ben@decadent.org.uk \
--cc=decot@googlers.com \
--cc=galp.dev@gmail.com \
--cc=galp@mellanox.com \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
--cc=vidya@cumulusnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox