From owner-freebsd-net@FreeBSD.ORG Thu Dec 11 22:48:33 2014 Return-Path: Delivered-To: freebsd-net@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 91F27461; Thu, 11 Dec 2014 22:48:33 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 56355F5B; Thu, 11 Dec 2014 22:48:33 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id kx10so5933796pab.16 for ; Thu, 11 Dec 2014 14:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iwTxErDJc/vZqQ27qkGbUvW3nCO8N+bLde+u9U1L/G4=; b=AN6xBLBRazmgbBma8poJEEJJofa2xM3BG6nm+fiI5vRq+38z/MWyF/ov7qPzzqGeGq TNxTPTTN2ksgU84dI3qpEZraFwgQNZufghmRHw6JUT+L+bfMuXisGvAe3+qMy8s0qRkQ JV23vty+zpGJ2+y8YJzQABrhH6zHO279/FTV4exfVsY9wfXSs5r9qTq0i2LZIG9hycz9 uYO/tSdijHJqZokFb7a3o3lvBxRfjXpvbkY7s06FVDNMocRW5H9lk4HgdEf8O8nvSY5z yFuyPEhcx7+YGxaZND2NVQkeoURCXvzyRr4HzqYmJ1uboiugDne1S1knFfKWtreArZBg Jwsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erj.cc; s=ericroxx; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iwTxErDJc/vZqQ27qkGbUvW3nCO8N+bLde+u9U1L/G4=; b=ZChhTL8okMEYnrMgJ0chEpF0GZT9FHMqAotqXablUPCRLq25sCWhIK3Za+Y2AY5Pna yOBaW/Fqvavec4VlthTVJRkD7TnYVk6l06E8imX0SQSA0PkN5/rP3P/BG5m74d9/3Knx 2oQ56yOWGmO7MI8Fbbug1t7ihqxzxrgm3v2/s= X-Received: by 10.69.26.98 with SMTP id ix2mr20792272pbd.161.1418338112693; Thu, 11 Dec 2014 14:48:32 -0800 (PST) MIME-Version: 1.0 Sender: ricera10@gmail.com Received: by 10.70.89.209 with HTTP; Thu, 11 Dec 2014 14:47:52 -0800 (PST) In-Reply-To: References: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> From: Eric Joyner Date: Thu, 11 Dec 2014 14:47:52 -0800 X-Google-Sender-Auth: ceOn6QsJiZtgQ8SlgXSMF8YcndA Message-ID: Subject: Re: Adding new media types to if_media.h To: Adrian Chadd , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arch@freebsd.org" , Jack F Vogel , Eric Joyner , Rui Paulo 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: Thu, 11 Dec 2014 22:48:33 -0000 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. 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 >