Date: Tue, 17 Feb 2015 10:44:21 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org, mike@karels.net Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Adding new media types to if_media.h Message-ID: <201502171044.21319.jhb@freebsd.org> In-Reply-To: <201502170150.t1H1ouxM020621@mail.karels.net> References: <201502170150.t1H1ouxM020621@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201502171044.21319.jhb>