Date: Mon, 09 Feb 2015 21:08:41 +0000 From: "George Neville-Neil" <gnn@neville-neil.com> To: "Mike Karels" <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 Message-ID: <BC6AB805-B699-438E-9EC6-015C005D6B1D@neville-neil.com> In-Reply-To: <201502082241.t18MfjJc091202@mail.karels.net> References: <201502082241.t18MfjJc091202@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Best, George > > 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" > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC6AB805-B699-438E-9EC6-015C005D6B1D>