Date: Tue, 9 Dec 2014 01:05:27 -0800 From: Eric Joyner <erj@erj.cc> To: freebsd-arch@freebsd.org Cc: Adrian Chadd <adrian@freebsd.org>, Jack F Vogel <jfvogel@gmail.com> Subject: Adding new media types to if_media.h Message-ID: <CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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? Thoughts? Any previous discussions worth looking at? - Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg>