netdev - Re: [PATCH] team: add support to get speed via ethtool

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Mar 2015 22:10:13 -0500
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	David Miller <davem@...emloft.net>
Cc:	sridhar.samudrala@...el.com, jiri@...nulli.us,
	netdev@...r.kernel.org
Subject: Re: [PATCH] team: add support to get speed via ethtool

On Fri, Mar 06, 2015 at 12:24:10AM -0500, David Miller wrote:
> From: Sridhar Samudrala <sridhar.samudrala@...el.com>
> Date: Thu,  5 Mar 2015 13:48:35 -0800
> 
> > +	list_for_each_entry(port, &team->port_list, list) {
> > +		if (port->linkup)
> > +			speed += port->state.speed;
> > +		if (ecmd->duplex == DUPLEX_UNKNOWN &&
> > +		    port->state.duplex != 0)
> > +			ecmd->duplex = port->state.duplex;
> 
> This makes no freakin' sense at all.  Adding the speeds together and
> returning that?  Are you kidding me?  Reporting only one of the
> duplex settings?  Are you kidding me?
> 
> Repeat after me: Speed and duplex has no meaning on software devices
> 
> Especially for software devices which aggregate links.
> 
> If the user wants the speed in a format that is actually useful, he
> has to actually know what the geography of the bond or team slaves,
> and since he knows that he can probe the individual hardware devices
> for speed and duplex information.

IIRC the value of a patch like this (where the underlying device is
backed by real hardware) is for remote monitoring tools.  I completely
agree that local users have no problem determining link utilization or
max bandwidth available by simply adding up all the members of the bond,
but this was not possible for SNMP-based tools that are not aware of the
aggregation of ports on the host.

> I'm not applying anything like this.
> 
> There appears to be some mania afoot about trying to return ethtool
> speed/duplex settings on software layering and tunneling device,
> can someone please cure this illness before I see more patches like
> this one?

You have made it clear that despite the value others see in it, you are
opposed to setting the speed and duplex on things like tuntap and I
agree with you on this.  Doing that does nothing but continue to enable
offload hardware to live in userspace and that is not the proper
direction the kernel should take.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html