RFC: ethctl

[Borja Marcos]

> On 20 Jan 2017, at 19:36, Garrett Wollman <wollman at hergotha.csail.mit.edu> wrote:
> 
> In article <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b at netflix.com> you write:
>> Eg, I don't see why we need another tool for some of this missing
>> "ethtool" functionality; it seems like most of it would naturally fit
>> into ifconfig.
> 
> From the end-user perspective, I agree with Drew.  Most of this stuff
> should just be part of ifconfig.

Actually I have a concern regarding the ethtool inspiration. I am sure it’s not the only factor at play,
but I think that the decision to include options such as autonegotiation or forced speed/duplex modes in
ifconfig helped FreeBSD drivers to be more consistent. In the old days when Fast Ethernet ruled and so many
devices got negotiation wrong my few interactions with Linux systems were really frustrating. Either the ethtool
package wasn’t installed, or it was the wrong version, or the driver just didn’t support ethtool.

More recently I faced a bug in an Intel driver: media detection didn’t work properly for 10 GbE DA cables. 
The interface worked, but the it didn’t get marked as full duplex, which meant that lagg rightfully refused to use it in
LACP mode (LACP mandates full duplex interfaces).

Debugging it on FreeBSD was a somewhat straightforward task. It was easy to determine why lagg refused to use it,
ifconfig indeed reflected the “unknown duplexness” and it gave me a good pointer to the issue (driver problem).

My coworkers told me that they were facing a similar problem on some Linux systems and I tried to have a look at it.
But looking at the whole ifconfig/ethtool stuff I believe (note, _I believe_, I didn’t have time to pay more attention to it and
it wasn’t critical for us anyway) that ethtool didn’t report the actual interface status from the operating system point of view,
but it rather polled the network interface itself and represented its own picture.

So, while the same issue was probably causing LACP not to work, which would mean that the interface wasn’t considered
full-duplex, the system’s ifconfig did not show anything about it, and ethtool probably deducted by itself that the interface
was actually full duplex, after all half-duplex 10 GbE doesn’t exist.

The moral of the story is: ifconfig being tightly coupled to the OS is more likely to be made to present the proper information.
What about an ethtool-class command? I guess there is a risk that, being more close to hardware, in the future it might be subject
to a similar problem to that one I believe ethtool to have. 

I understand that it wouldn’t be a Linux-style optional package, but part of the system, which should remove the concerns
about driver support. But, anyway, given that ifconfig is already supporting plenty of media/driver options, wouldn’t it be better
to refine it a bit and leave the handful of esoteric operations to a driver specific tool?

At least it’s cleaner I think. Just my opinion, based in part on beliefs and, I admit it, on having been burned by linuxisms.







Borja.