Date: Sun, 08 Feb 2015 16:41:45 -0600 From: Mike Karels <mike@karels.net> To: Eric Joyner <erj@erj.cc> Cc: Adrian Chadd <adrian@freebsd.org>, Rui Paulo <rpaulo@me.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, John Baldwin <john@baldwin.cx>, Jack Vogel <jfvogel@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Fwd: Adding new media types to if_media.h Message-ID: <201502082241.t18MfjJc091202@mail.karels.net> In-Reply-To: Your message of January 6, 2015 4:50:28 PM CST <BC16B1C5-1F3D-4BE8-80B2-D49CFBDF4C27@karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ? Mike > From: Eric Joyner <erj@erj.cc> > Date: January 6, 2015 4:50:28 PM CST > To: mike@karels.net > Cc: Adrian Chadd <adrian@freebsd.org>, Rui Paulo <rpaulo@me.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Eric Joyner <erj@erj.cc>, John Baldwin <john@baldwin.cx>, Jack Vogel <jfvogel@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> > Subject: Re: Adding new media types to if_media.h > > Then going with what Mike says about leaving backwards compatibility, I > suppose we should do something like what Adrian suggested, and add a > separate struct. We can indicate that the separate struct exists by setting > the media type value in the if_media word to 0xc0, since that's the last > unused value. Then existing programs won't have to support any new features > if they don't want to. > > Adrian -- where can I look for more information on what net80211 does for > media types? Do you mean what it does with MCS values, or something more; > I've looked at it a bit, but I don't know very much about how Wi-Fi works. > > - Eric > > On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels <mike@karels.net> wrote: > >>> On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: >>>> I think I'd go along with Mike, keeping it simpler seems like a good >> idea. >>>> >>>> Jack >> >>> If the userland ABI impact isn't too broad I think this is fine. Mike, >> do you >>> know off hand how many user-facing things would be affected? >> >> I didn't know off hand, but I have a glimpse index at $WORK (it's for >> McAfee >> Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 references >> to >> if_media.h at user level, including "ports" that we use, and excluding our >> own software. The list includes libpcap, snmpd, dhclient, quagga, xorp, >> atm, devd, and rtsold. fwiw, I found about 260 inclusions of if_media.h >> in the kernel. >> >> This suggests that we should preserve a backward-compatible user API, even >> if it has limits. Unfortunately, the media word I mentioned is a plain >> int, >> not a typedef. I would propose a similar API that is not limited, but easy >> to convert (e.g. using a new typedef). I'd be willing to sketch out >> something >> like that. >> >>>> On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels <mike@karels.net> wrote: >>>>>> Any other thoughts, or should I start looking at seeing what I can >> take >>>>>> copy from net80211? >>>>>> >>>>>> Also adding -net, since this is pretty relevant. >>>>> >>>>> I had the same reaction as Adrian initially, as an int with numerous >>>>> fields >>>>> seems really messy. However, I don't think we have the challenges of >>>>> 802.11, >>>>> and the only real problem is that the subtype field has run out of >> bits. >>>>> And both ifconfig and the drivers are cast in the form of a scalar >> "media >>>>> word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | >>>>> IFM_FDX >>>>> (assuming that all the bits are in a scalar). >>>>> >>>>> Instead, I would propose that we simply change the media word from >> 32 bits >>>>> to 64, and move the subtype from its current location to a new field >> (e.g. >>>>> 16 bits) in the new space. I believe this can be KPI compatible, >> and it >>>>> is relatively easy to provide a backward-compatible ABI. There >> should be >>>>> a reserved subtype for "other" that can be encoded in the existing >> field >>>>> for use when the subtype can't fit in the old field. This seems much >>>>> easier, >>>>> can be KPI compatible, and will make it much easier to backport >> drivers. >>>>> A backport could simply define the new subtypes as "other", and the >> KPI >>>>> would still be compatible. >>>>> >>>>> Thoughts? >>>>> >>>>> Mike >> >>> -- >>> John Baldwin >> >> Mike >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201502082241.t18MfjJc091202>