From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 15:27:21 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95943557; Tue, 9 Dec 2014 15:27:21 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B11D231; Tue, 9 Dec 2014 15:27:20 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NGB0083SMXAK850@st11p02mm-asmtp001.mac.com>; Tue, 09 Dec 2014 15:27:13 +0000 (GMT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Adding new media types to if_media.h From: Rui Paulo In-reply-to: Date: Tue, 09 Dec 2014 07:27:10 -0800 Content-transfer-encoding: quoted-printable Message-id: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> References: To: Eric Joyner X-Mailer: Apple Mail (2.1993) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-09_05:2014-12-09,2014-12-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412090154 Cc: Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 15:27:21 -0000 On Dec 9, 2014, at 01:05, Eric Joyner 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