netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hangbin Liu <liuhangbin@gmail.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH net-next] team: add ethtool get_link_ksettings
Date: Thu, 13 Jun 2019 14:16:49 +0800	[thread overview]
Message-ID: <20190613061648.GE18865@dhcp-12-139.nay.redhat.com> (raw)
In-Reply-To: <20190528112431.GA2252@nanopsycho>

On Tue, May 28, 2019 at 01:24:31PM +0200, Jiri Pirko wrote:
> Tue, May 28, 2019 at 12:02:11PM CEST, liuhangbin@gmail.com wrote:
> >On Tue, May 28, 2019 at 11:08:23AM +0200, Jiri Pirko wrote:
> >> >+static int team_ethtool_get_link_ksettings(struct net_device *dev,
> >> >+					   struct ethtool_link_ksettings *cmd)
> >> >+{
> >> >+	struct team *team= netdev_priv(dev);
> >> >+	unsigned long speed = 0;
> >> >+	struct team_port *port;
> >> >+
> >> >+	cmd->base.duplex = DUPLEX_UNKNOWN;
> >> >+	cmd->base.port = PORT_OTHER;
> >> >+
> >> >+	list_for_each_entry(port, &team->port_list, list) {
> >> >+		if (team_port_txable(port)) {
> >> >+			if (port->state.speed != SPEED_UNKNOWN)
> >> >+				speed += port->state.speed;
> >> >+			if (cmd->base.duplex == DUPLEX_UNKNOWN &&
> >> >+			    port->state.duplex != DUPLEX_UNKNOWN)
> >> >+				cmd->base.duplex = port->state.duplex;
> >> 
> >> What is exactly the point of this patch? Why do you need such
> >> information. This is hw-related info. If you simply sum-up all txable
> >> ports, the value is always highly misleading.
> >> 
> >> For example for hash-based port selection with 2 100Mbit ports,
> >> you will get 200Mbit, but it is not true. It is up to the traffic and
> >> hash function what is the actual TX speed you can get.
> >> On the RX side, this is even more misleading as the actual speed depends
> >> on the other side of the wire.
> >
> >The number is the maximum speed in theory. I added it because someone

Hi Jiri,

Sorry for the late reply.

> 
> "in theory" is not what this value should return in my opinion.

Would you please give some hits about what "in theory" value we should return?

In my understanding, it just shows the maximum in theory speed. Just like a
NIC card shows the speed 1000Mb/s, but the actually max speed could be only
700-900 Mb/s for tcp/udp testing. No need to say if the other side's max speed
is only 100Mb/s, we will get lower speed value.

So I think with ab, rr, lb, random mode, the team speed could be the summary of
total active ports' speed. The only controversial mode may be the broadcast
mode as it just broadcast all the data from all ports. But it do send all the
data. If we ignore the fault tolerance sutff, all the bandwidth are used. The
speed shows the total number of all NICs looks also make sense.

Hope I made it clear and you could got what I mean..
> 
> 
> >said bond interface could show total speed while team could not...
> >The usage is customer could get team link-speed and throughput via SNMP.
> 
> Has no meaning though :/

Anyway, the customer is looking for this feature. Shouldn't we
consider about the requirement?

Thanks
Hangbin

  reply	other threads:[~2019-06-13 16:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27  3:31 [PATCH net-next] team: add ethtool get_link_ksettings Hangbin Liu
2019-05-27 17:09 ` David Miller
2019-05-28  9:08 ` Jiri Pirko
2019-05-28 10:02   ` Hangbin Liu
2019-05-28 11:24     ` Jiri Pirko
2019-06-13  6:16       ` Hangbin Liu [this message]
2019-06-14  8:32         ` Jiri Pirko
2019-06-14 15:55           ` David Miller
2019-06-14  8:32 ` Jiri Pirko
2019-06-17  1:32 ` [PATCHv2 " Hangbin Liu
2019-06-17  9:03   ` Jiri Pirko
2019-06-17 20:23   ` David Miller

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=20190613061648.GE18865@dhcp-12-139.nay.redhat.com \
    --to=liuhangbin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).