From owner-freebsd-net@freebsd.org Tue Jan 24 10:22:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF483CBFBCC for ; Tue, 24 Jan 2017 10:22:45 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E00135B for ; Tue, 24 Jan 2017 10:22:45 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (unknown [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPA id DEF589DC9D1; Tue, 24 Jan 2017 11:14:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: RFC: ethctl From: Borja Marcos In-Reply-To: <201701201836.v0KIailL014327@hergotha.csail.mit.edu> Date: Tue, 24 Jan 2017 11:14:45 +0100 Cc: gallatin@netflix.com, freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201701201836.v0KIailL014327@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 10:22:46 -0000 > On 20 Jan 2017, at 19:36, Garrett Wollman = wrote: >=20 > In article 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.