From owner-freebsd-net@FreeBSD.ORG Fri Dec 12 20:26:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E4491FB; Fri, 12 Dec 2014 20:26:27 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 817F9D8E; Fri, 12 Dec 2014 20:26:26 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so3663970wiv.0; Fri, 12 Dec 2014 12:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PYrsTDlNXg7RMv0fkiGXDkgylp3clcjcRieHFrTSJzU=; b=dfpKeBJWf6KIEfTbS5+Kd7f9CZgVKDrdY0cHetkU0hl9Gnl7SMG/XPEiZ4unsApldA 7ZGT3r433cQqU+wGOjKW3v3oJ0x2VeGQbUcT/6G9ktPuSbqoJTnyX8UPr+fYFJnsEZhw 0lW7IAE0264HF6A1I7ZbaOOUoOE/nQsinMbzOFvjr7eQhDVSb2nIjELzIdHoGp9kM6vG j8USLTLilA3fbzdEyXQxOYa6G59jIM68kWFzeoVmfxk0Tqww6DhXZgExSq/rnUO/T2pZ HFVbMcmfo9ia0k0jVcVZy59rcdmubTUSDV2Zd8JaNTscNtNE1P2iVCaFKYc1uAfLq2Yw 9row== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr10894052wic.21.1418415984946; Fri, 12 Dec 2014 12:26:24 -0800 (PST) Received: by 10.194.81.233 with HTTP; Fri, 12 Dec 2014 12:26:24 -0800 (PST) In-Reply-To: <201412121439.sBCEdVRU071168@mail.karels.net> References: <201412121439.sBCEdVRU071168@mail.karels.net> Date: Fri, 12 Dec 2014 12:26:24 -0800 Message-ID: Subject: Re: Adding new media types to if_media.h From: Jack Vogel To: Mike Karels Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Rui Paulo , Eric Joyner , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:26:27 -0000 I think I'd go along with Mike, keeping it simpler seems like a good idea. Jack On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: > > > 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 > wrote: > > > > > > On 9 December 2014 at 07:27, Rui Paulo wrote: > > > > On Dec 9, 2014, at 01:05, Eric Joyner 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@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >