Date: Tue, 09 Dec 2014 07:27:10 -0800 From: Rui Paulo <rpaulo@me.com> To: Eric Joyner <erj@erj.cc> Cc: Adrian Chadd <adrian@freebsd.org>, Jack F Vogel <jfvogel@gmail.com>, freebsd-arch@freebsd.org Subject: Re: Adding new media types to if_media.h Message-ID: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> In-Reply-To: <CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg@mail.gmail.com> References: <CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 9, 2014, at 01:05, Eric Joyner <erj@erj.cc> wrote: >=20 > This is a continuation of a discussion from off the list: >=20 > 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. >=20 > 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: >=20 > 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. >=20 > 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. >=20 > 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.=20 -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1AA55540-AADD-45CB-BC93-E2F81258B1F1>