Date: Tue, 9 Dec 2014 10:40:13 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Rui Paulo <rpaulo@me.com> Cc: Jack F Vogel <jfvogel@gmail.com>, Eric Joyner <erj@erj.cc>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Adding new media types to if_media.h Message-ID: <CAJ-Vmok9eifN3=3eb8w-VJdfnKY5Qcgu1cZjpi3B8=pYnjsQLQ@mail.gmail.com> In-Reply-To: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> References: <CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg@mail.gmail.com> <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 December 2014 at 07:27, Rui Paulo <rpaulo@me.com> wrote: > On Dec 9, 2014, at 01:05, Eric Joyner <erj@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 unde= r >> 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 fo= r 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 sho= uld >> 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 w= e >> 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 bes= t >> solution to me, but I don't know how much effort it would take to implem= ent >> -- does ifconfig need a lot of changing to handle this? > > ifconfig is a macro-intensive application, so maybe it's not that much wo= rk. > >> Thoughts? Any previous discussions worth looking at? > > Hmm, it looks like you're limited in the number of bits because of how th= e word was laid out. We can't simple remove token ring and get more bits fo= r ethernet... We could create another IFM_40GETHERNET type to replace toke= n ring but that would be ugly (the IFM_TYPE() macro could handle this idios= yncrasy). > > 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 sto= ring 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmok9eifN3=3eb8w-VJdfnKY5Qcgu1cZjpi3B8=pYnjsQLQ>