From owner-freebsd-net@FreeBSD.ORG Tue Feb 17 17:17:16 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82CCB37B; Tue, 17 Feb 2015 17:17:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5961422B; Tue, 17 Feb 2015 17:17:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 742CDB91F; Tue, 17 Feb 2015 12:17:15 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org, mike@karels.net Subject: Re: Adding new media types to if_media.h Date: Tue, 17 Feb 2015 10:44:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201502170150.t1H1ouxM020621@mail.karels.net> In-Reply-To: <201502170150.t1H1ouxM020621@mail.karels.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201502171044.21319.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Feb 2015 12:17:15 -0500 (EST) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Feb 2015 17:17:16 -0000 On Monday, February 16, 2015 8:50:56 pm Mike Karels wrote: > On Feb 9, gnn wrote: > > > On 8 Feb 2015, at 22:41, Mike Karels wrote: > > > > Sorry to reply to a thread after such a long delay, but I think it is > > > unresolved, and needs more discussion. I'd like to elaborate a bit on > > > my goals and proposal. I believe Adrian has newer thoughts than have > > > been > > > circulated here as well. > > > > > > The last message(s) have gone to freebsd-arch and freebsd-net. If > > > someone > > > wants to pick one, we could consolidate, but this seems relevant to > > > both. > > > > > > I'm going to top-post to try to summarize and extend the discussion, > > > but the > > > preceding emails follow for reference. > > > > > > To recap: the existing if_media interface is running out of steam, at > > > least > > > in that the "Media variant" field, with 5 bits, is going to be > > > insufficient > > > to express existing 40 Gb/s variants. The if_media media type is a > > > 32-bit > > > int with a bunch of sub-fields for type (e.g. Ethernet), > > > subtype/variant > > > (e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related > > > fields. > > > > > > I made a proposal to extend the interface in a small way, specifically > > > to > > > replace the "media word" with a 64-bit int that is mostly the same, > > > but > > > has a new, larger variant/subtype field. The main reason for this > > > proposal > > > is to maintain the driver KPI (glimpse showed me 240 inclusions of > > > if_media.h > > > in the kernel in 8.2). That interface includes an initialization > > > using a > > > scalar value of fields ORed with each other. It would also be easy to > > > preserve a 32-bit user-level API/ABI that can express most of the > > > current > > > state, with a subtype/variant field value reserved for "other" (there > > > is > > > already one for "unknown", but that is not quite the same). fwiw, I > > > found 45 references to this user-level API in our tree, including both > > > base and "ports"-type software, which includes libpcap, snmpd, > > > dhclient, > > > quagga, xorp, atm, devd, and rtsold, which argues for a > > > backward-compatible > > > API/ABI as well as a more-complete current interface for ifconfig at > > > least. > > > > > > More generally, I see two problems with the existing if_media > > > interface: > > > > > > 1. It doesn't have enough bits for all the fields, in particular, > > > variant/ > > > subtype for Ethernet. That is the immediate issue. > > > > > > 2. The interface is not sufficiently generic; it was designed around > > > Ethernet > > > including MII, token ring, FDDI, and a few other interface types. > > > Some of > > > the fields like "instance" are primarily for MII as far as I know, and > > > are > > > basically unused. It is definitely not sufficient for 802.11, which > > > has > > > rolled its own interfaces. > > > > > > To solve the second problem, I think the right approach would be to > > > reduce > > > this interface to a truly generic one, such as media type (e.g. > > > Ethernet), > > > generic flags, and perhaps generic status. Then there should be a > > > separate > > > media-specific interface for each type, such as Ethernet and 802.11. > > > To a > > > small extent, we already have that. Solving the second, more general > > > problem, > > > requires a whole new driver KPI that will require surgery to every > > > driver, > > > which is not an exercise that I would consider. > > > > > > Using a separate int for each existing field, as proposed, would break > > > the > > > driver KPI, but would not really make the interface generic. Trying > > > to > > > make a single interface with the union of all network interface > > > requirements > > > seems like a bad idea to me (we failed last time; the "we" is BSDi, > > > where > > > I was the architect when this interface was first designed). (No, I > > > didn't > > > design this interface.) > > > > > > Solving the first problem only, I think it is preferable to preserve a > > > compatible driver KPI, which means using a scalar value encoding what > > > is > > > necessary. Although that interface is rather Ethernet-centric, that > > > is > > > really what it is used for. > > > > > > An additional, selfish goal is to make it easy to back-port drivers > > > using > > > the new interface to older versions (which I am quite likely to do). > > > Preserving the KPI and general user API will be highly useful there. > > > I'd be likely to do a 11-style version of ifconfig personally, but it > > > might not be difficult to do in a more general way. > > > > > > I am willing to do a prototype for -current for evaluation. > > > > > > Comments, alternatives, ? > > > I agree with your statements above and I'd like to see the prototype. > > Well, I developed the prototype as I had planned, using a 64-bit media > word, and found that I got about 100 files in GENERIC that didn't compile; > they attempted to store "media words" in an int. My kingdom for a typedef. > That didn't meet my goal of KPI compatibility, so I went to Plan B. > > Plan B is to steal an unused bit (RFU) to indicate an "extended" media > type. I then used the variant/subtype field to store the extended type. > Effectively, the previously unused bit doubles the effective size of the > subtype field. Given that the previous 5-bit field lasted us 18 years, > I figured that doubling it would last a while. I also changed the > SIOGGIFMEDIA ioctl, splitting it for binary compatibility; extended > types are all mapped to IFM_OTHER (31) using the old interface, but > are visible using the new one. > > With these changes, I modified one driver (vtnet) to use an extended type, > and the rest of GENERIC is happy. The changes to ifconfig are also fairly > small. The patch is appended, where email programs will screw it up, > or at ftp://ftp.karels.net/outgoing/if_media.patch. > > The VFAST subtype is a throw-away for testing. > > This seems like a reasonably pragmatic change to support the new 40 Gb/s > media types until someone wants to design an improved but non-backward- > compatible interface. I think it meets the goal of suitability for > back-porting; it could be MFCed. Seems like a reasonable next step to me. -- John Baldwin