From owner-freebsd-net@freebsd.org Fri Jan 20 17:56:31 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 4BCA3CB8E64 for ; Fri, 20 Jan 2017 17:56:31 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 129FF1504; Fri, 20 Jan 2017 17:56:31 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-io0-x242.google.com with SMTP id c80so8769827iod.1; Fri, 20 Jan 2017 09:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CwEYpwpVL5szGHzWQ1CylrB9Oxr/e5md7Dd5nJdBV84=; b=u/lZmQj872B3TxMF3phhKAh82LGin0PGtbaZ6a8XF9pfr2FmvlhpYlEW6VHOVShN5l b3Ox72KJ46ArOmPguShxBHcyZDA3oUJJlevModToRjNB+tRzYwkVeor1R0I4z2X5C4XE g4I+fTbzsoiOr3tIA/kYc1BhD5u43JrBLG18pbnBulrXum0Oaik5td26WNmNi+vbYg5t +B8JT7n9XAvztYh18GDYQTkl3yj9HMdoqtSsElt4o5+KaOV5VFIDPPKRsS3Vk8wjvUrx kaslTVBD+/9b73qbCrzvD7MoawFDqS16l9Y1EX3xPdrWZnfIwLFRURMYbKmALMqwG7wE RbbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CwEYpwpVL5szGHzWQ1CylrB9Oxr/e5md7Dd5nJdBV84=; b=TylQuw4zTHoonP7adjBvAa/766i7LUZWkobbqdVUG4WbzopeGNVrE+XD5LQ7eJoiKC Jjs65Ftpl2Ab0sztH6eWTAW6wtJ73mJIoDYVu4FstVSNeNDrf6sMGEJcarkpkP3Tp9tr Uu8fJpEwLkGWEsgKbPEsS/ZqLbTQ3IcKNzkPxV8D0S3pdiHcvFVavUnG4lplT33fB7XQ kImv3M7MyHeVGBxvlERS4cj2xx6dbNNkTT4ZK0s0PDya2GaLsjI1zO0FoTGQmK2urS6k 1BZhZ+LmvjhpkelmhzsKeE0mFAXjzTMYJZqCpTULMGg8NcP3K5seFQTnpDrCz2u9VLgf n5Lg== X-Gm-Message-State: AIkVDXLcO7imtSGFc21PKMxehLFE2gB4oEXDAXoCmCdCKULmcDXZOMggtfO307jYRVngr/U9jLHU10Gm/xNcjw== X-Received: by 10.107.129.222 with SMTP id l91mr13294292ioi.194.1484934990336; Fri, 20 Jan 2017 09:56:30 -0800 (PST) MIME-Version: 1.0 Sender: rizzo.unipi@gmail.com Received: by 10.107.169.213 with HTTP; Fri, 20 Jan 2017 09:56:29 -0800 (PST) In-Reply-To: References: From: Luigi Rizzo Date: Fri, 20 Jan 2017 09:56:29 -0800 X-Google-Sender-Auth: mcywOtv-BKtp4leqbEhRSG_V6Tw Message-ID: Subject: Re: RFC: ethctl To: Andrew Gallatin Cc: Kevin Bowling , "freebsd-net@freebsd.org" , Scott Long , "Joyner, Eric" , Oded Shanoon , Matthew Macy , hps@freebsd.org, "Cramer, Jeb J" , George Neville-Neil , arybchik@freebsd.org, shurd@freebsd.org, Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 20 Jan 2017 20:16:37 +0000 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: Fri, 20 Jan 2017 17:56:31 -0000 To summarize Drew's comments, which I mostly agree with, and suggest a possible strategy for deployment: - Irrespective of the user-facing command (ifconfig vs ethtool), a common kernel API for the most common features is very desirable. - There are very good reasons to take inspiration from include/linux/ethtool.h to decide on this set of features: 1. it is a valid starting point and as good as any other one; 2. ethtool functions are all optional so deciding what to put in is not a hard decision 3. may possibly ease porting drivers across platforms - I think the user interface bikeshed is not solvable other than eventually implementing both "ifconfig" and "ethtool" style user commands. This does not seem a major problem, because our ifconfig already implements some of the ethtool's commands, and to tell the truth, as much as I am (was) used to ifconfig, it is such a kitchen sink that it is sometimes hard to figure out how to use it (documentation and feature mismatch, ambiguity in the syntax etc.) - for some of the high level features (e.g. flashing a device) that may be more complicated than calling an ioctl(), we could implement a fallback mechanism where, say, the ioctl returns a special message that drives the user-facing app to call an external helper program (configured through /etc/rc.d/ or whatever other mechanism) cheers luigi On Fri, Jan 20, 2017 at 8:42 AM, Andrew Gallatin via freebsd-net wrote: > On 01/19/2017 22:58, Kevin Bowling wrote: >> >> Greetings, >> >> I'm casting a wide net in cc, try to keep the noise minimal but we need >> some input from a variety of HW vendors. >> >> I have heard from several vendors the need for a NIC configuration tool. >> Chelsio ships a cxgb/cxgbetool in FreeBSD as one example. There is >> precedence for some nod toward a basic unified tool in Linux ethtool. >> >> From your perspective, >> 1) What are the common requirements? >> 2) What are specialized requirements? For instance as a full TCP offload >> card Chelsio needs things others wont >> 3) What should it _not_ do? Several of you have experience doing >> Ethernet driver dev on many platforms so we should attempt to avoid >> repeating past design mistakes. >> >> I expect we can achieve some level of inversion so the device specific >> code can live close to the driver and plug into the ethctl framework. >> It should be general enough to add completely new top level commands, so >> vendors can implement HW specific features. On the other hand, we >> should attempt to hook into common core for features every NIC provides, >> with a focus on iflib. >> >> I will fund Matt Macy to do the overall design and implementation. >> >> Regards, >> Kevin Bowling, on behalf of Limelight Networks for this effort > > > In a previous job, I was the author of a few Linux drivers (as well as > FreeBSD, Solaris, OSX, ESX, etc) for Myricom NICs. > > IMHO, the "good" thing about ethtool was the standardized kernel API > to do things like change tx/rx ring size, and enable/disable offloads. > That was much nicer than having to parse ioctls and/or have custom > sysctls. I think Gleb had started on this in his ifnet branch, and > centralizing such features in iflib is a good carrot to encourage new > drivers to use iflib. > > However, as a user/admin, I believed that a lot of the stuff that was > in Linux's ethtool should really have been in ifconfig, and it was > always a bit hard to remember which tool did which thing. I think I > was spoiled by the rich configuration syntax available on FreeBSD's > ifconfig. Eg, this seems more natural: > > ifconfig mxge0 -tso > than this > ethtool -K eth2 tso off > > 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. > > As to other features, like writing firmware images and/or reading > dumping eeprom -- these were never a natural fit for us. We already > had our own tools that did just what we needed and worked across *all* > OSes (even Windows!). I remember trying to figure out the ethtool > way, but there was no substantial customer demand for using ethtool > for this that I was aware of, and the time needed to adapt our > firmware image, etc, to the ethtool format was just not possible to > justify. So I think asking vendors to support a FreeBSD ethtool-ish > interface for this is asking a lot. > > Drew > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------