On 8/9/2017 2:36 AM, James Feeney wrote:
On 08/08/2017 05:43 PM, Dan Williams wrote:
It's very relevant to the question. Because if the speed is actually
not useful for the requested purpose, there is no real point in having
it reported it via ethtool. Same for duplex. Wifi is only "half
duplex", and so the property is actually meaningless for WiFi.
That seems a little over-broad, at least certainly with respect to "half
duplex". If the link is known to be half duplex, then the kernel ethtool can
simply report that the link is "half duplex". I am not hearing a good
justification, or a necessity, for the kernel ethtool to return an error,
There is nothing "over-board" about it. Whhy asking a question if you
already know the answer.
worst, your bonding link will flip-flop between slaves every second or
two. At best, bonding won't do anything differently than if the speed
was just faked to some fake lowest common denominator number so that
your wired link was always faster.
Well ok, flip-flopping every second would seem a pointless and bad effect. But
then, for instance, my rtl8192ce driver shows a stable, actual link speed:
$ iwconfig wlp2s0
Bit Rate=72.2 Mb/s
$ ethtool -S wlp2s0
Then, I don't know if this effect is as bad as you suggest. Is there an actual
"stable" link speed here? Or is this an "illusion", of bit of "fluff" being
promoted by the user-space iwconfig and ethtool?
Sure, somebody could do a patch (like Ben has) that plumbs all this
stuff through. But that's not solving the *actual* problem, which is
that this bonding change makes assumptions of slave devices that simply
don't match how those devices work.
I take it that your position would be that the bonding module people, and Mahesh
in particular, are being unreasonable in expecting the kernel ethtool to provide
anything but an error in response to get_settings()? What do you think of
Florian's suggestion, to check for dev->ieee80211_ptr being set, and letting
these interfaces proceed with being enslaved in a bond master network device if
that's the case?
Would you go so far as to say that modifying the kernel ethtool to report
wireless link speed and duplex would be entirely pointless?
It really depends on how it is used. In case of the bonding module it
seems it need to be pretty accurate to assure using the fastest link.
You say your rtl8192ce driver reports stable speed, but what is your
connection state and are you actually sending packets over it. Also the
rxrate reported is 1MB/s, which is probably rate of the last received
packet. Apart from your data connection to the AP the device is
receiving beacons which are sent at a low speed thus screwing up the rx
speed accuracy of your link.
Actually what the bonding module could rely on would be what is
described in section 11.46 ("Estimated throughput") of IEEE802.11-2016
as it seems to address exactly the bonding use-case. However, I am not
aware of any devices in the field carrying that feature (but I am not
all knowing ;-) ).