Adding new media types to if_media.h

Tue Feb 17 17:17:16 UTC 2015

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