Date: Tue, 24 Jan 2017 11:14:45 +0100 From: Borja Marcos <borjam@sarenet.es> To: Garrett Wollman <wollman@hergotha.csail.mit.edu> Cc: gallatin@netflix.com, freebsd-net@freebsd.org Subject: Re: RFC: ethctl Message-ID: <EB688D2F-9176-43AB-9849-E3A0B7852F17@sarenet.es> In-Reply-To: <201701201836.v0KIailL014327@hergotha.csail.mit.edu> References: <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@netflix.com> <CAK7dMtCSRu6L67A46FU0eYqJ9=zGdyJPvBXLkL7gKbh=SbZ6cQ@mail.gmail.com> <201701201836.v0KIailL014327@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 20 Jan 2017, at 19:36, Garrett Wollman = <wollman@hergotha.csail.mit.edu> wrote: >=20 > In article <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@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. >=20 > =46rom 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=E2=80=99s 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=E2=80=99t installed, or it was the wrong version, or the = driver just didn=E2=80=99t support ethtool. More recently I faced a bug in an Intel driver: media detection didn=E2=80= =99t work properly for 10 GbE DA cables.=20 The interface worked, but the it didn=E2=80=99t 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 =E2=80=9Cunknown duplexness=E2=80=9D 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=E2=80=99t have time to pay more attention to it and it wasn=E2=80=99t critical for us anyway) that ethtool didn=E2=80=99t = 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=E2=80=99t considered full-duplex, the system=E2=80=99s 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=E2=80=99t = 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.=20 I understand that it wouldn=E2=80=99t 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=E2=80=99t it be better to refine it a bit and leave the handful of esoteric operations to a = driver specific tool? At least it=E2=80=99s cleaner I think. Just my opinion, based in part on = beliefs and, I admit it, on having been burned by linuxisms. Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EB688D2F-9176-43AB-9849-E3A0B7852F17>