Adding new media types to if_media.h

[Mike Karels]

> 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

> On Tue, Dec 9, 2014 at 10:40 AM, Adrian Chadd <adrian at freebsd.org> wrote:
> >
> > On 9 December 2014 at 07:27, Rui Paulo <rpaulo at me.com> wrote:
> > > On Dec 9, 2014, at 01:05, Eric Joyner <erj at erj.cc> wrote:
> > >>
> > >> This is a continuation of a discussion from off the list:
> > >>
> > >> ixgbe needs to support devices with media types that aren't in
> > if_media.h;
> > >> for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately,
> > we're
> > >> running into the issue that there is no room for all of these types
> > under
> > >> the IFM_ETHER category; there's only room for two more (and per John
> > >> Baldwin, only one more if one of those two unused types is to be used
> > for a
> > >> reserved type). Long term, there are going to be tons of media types for
> > >> future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already
> > >> supports media types that aren't in if_media.h, either.
> > >>
> > >> So, something needs to change. Does anyone have any thoughts on what
> > should
> > >> happen? I've thought of a few things, but I don't have an adequate
> > grasp of
> > >> what the pros/cons of each are:
> > >>
> > >> 1. Add a new media category (like IFM_ETHER) and change kernel code to
> > >> treat it like the existing IFM_ETHER. This creates ~28 new media types
> > we
> > >> can use, but it may just be delaying the inevitable for a short time.
> > >>
> > >> 2. Extend media value from 32-bits to 64-bits. I don't have a good idea
> > of
> > >> what the consequences are of this on architectures that aren't amd64.
> > >>
> > >> 3. (Initially suggested by Adrian) would be to create a new media type
> > >> struct (instead of using an int value) or adding an extra value to the
> > >> existing ifmedia/ifmedia_entry struct for this. This sounds like the
> > best
> > >> solution to me, but I don't know how much effort it would take to
> > implement
> > >> -- does ifconfig need a lot of changing to handle this?
> > >
> > > ifconfig is a macro-intensive application, so maybe it's not that much
> > work.
> > >
> > >> Thoughts? Any previous discussions worth looking at?
> > >
> > > Hmm, it looks like you're limited in the number of bits because of how
> > the word was laid out. We can't simple remove token ring and get more bits
> > for ethernet...  We could create another IFM_40GETHERNET type to replace
> > token ring but that would be ugly (the IFM_TYPE() macro could handle this
> > idiosyncrasy).
> > >
> > > I think if_media should probably be a structure with unions to store the
> > subtypes.  net80211 has the same problem with MCS rates and we ended up
> > storing them outside if_media because of this.
> >
> > I think solving this like how it's done in net80211 (ie, with an
> > external structure that represents the media type details for a given
> > media) is the right thing to do.
> >
> > Otherwise it'll be a path to madness in the future.
> >
> > The net80211 side of things is mostly extensible and I'm going to
> > (eventually) end up using it for the 11ac rates that have shown up. I
> > couldn't do that whilst trying to cram it into the existing ifmedia
> > variable.
> >
> >
> > -adrian
> >
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"