netdev - Re: [PATCH net-next 2/2] sunvnet: implement basic ethtool get

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20170621.172840.2117049575055680390.davem@davemloft.net>
Date:   Wed, 21 Jun 2017 17:28:40 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     shannon.nelson@...cle.com
Cc:     netdev@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] sunvnet: implement basic ethtool
 get_settings

From: Shannon Nelson <shannon.nelson@...cle.com>
Date: Wed, 21 Jun 2017 13:59:45 -0700

> On 6/21/2017 12:06 PM, David Miller wrote:
>> From: Shannon Nelson <shannon.nelson@...cle.com>
>> Date: Wed, 21 Jun 2017 09:09:54 -0700
>> 
>>> Add the get_settings callback so that both the ldmvsw and sunvnet
>>> drivers will give a little more information when asked for its
>>> basic settings.  These aren't necessarily very useful, but they
>>> make some users happier.  Also, a side effect is that the speed
>>> attribute in /sys/class/net/<dev> is now readable, which makes
>>> a couple of the ldom management tools happier.
>>>
>>> Orabug: 26175474
>>>
>>> Signed-off-by: Shannon Nelson <shannon.nelson@...cle.com>
>> I would set the speed to something other than zero, and also
> 
> I kept looking at that and wasn't sure which value to pretend with.  I
> looked at what was reported in the Solaris world and saw '0' so went
> with that.  I suppose using SPEED_10000 shouldn't hurt anything, and
> is close enough to observed client-to-client speeds.
> 
>> consider the ramifications of this change upon things like
>> 'bonding' and 'team'.
> 
> The request I was responding to with this was really more targeted at
> the ldmvsw (host) side of the connection, the vif device, which I
> believe only ever gets connected to the vsw bridge.  You're right,
> tho', because the eth0 in the ldom client *does* get sucked into
> teams.  I may drop the sunvnet/client side of this patch and stick
> with just the host/ldmvsw side.

Usually if possible you propagate the speed of the underlying physical
layer, if applicable.

You can see what some other software devices do in the case of ethtool
link speed settings.