From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 16:47:43 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 679E52CB; Tue, 9 Dec 2014 16:47:43 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20B5FE10; Tue, 9 Dec 2014 16:47:43 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XyNwr-000Ped-6t; Tue, 09 Dec 2014 20:47:41 +0400 Date: Tue, 9 Dec 2014 20:47:41 +0400 From: Slawa Olhovchenkov To: Eric Joyner , Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org Subject: Re: Adding new media types to if_media.h Message-ID: <20141209164741.GP76224@zxy.spb.ru> References: <20141209130412.GA81921@zxy.spb.ru> <20141209153539.GA3925@ox> <20141209163136.GA94186@zxy.spb.ru> <20141209164334.GB3925@ox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141209164334.GB3925@ox> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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 16:47:43 -0000 On Tue, Dec 09, 2014 at 08:43:34AM -0800, Navdeep Parhar wrote: > On Tue, Dec 09, 2014 at 08:31:36PM +0400, Slawa Olhovchenkov wrote: > > On Tue, Dec 09, 2014 at 07:35:39AM -0800, Navdeep Parhar wrote: > > > > > On Tue, Dec 09, 2014 at 05:04:13PM +0400, Slawa Olhovchenkov wrote: > > > > On Tue, Dec 09, 2014 at 01:05:27AM -0800, 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? > > > > > > > > > > Thoughts? Any previous discussions worth looking at? > > > > > > > > I think need support for media type and subtype, i.e.: > > > > > > > > cxl0: flags=8843 metric 0 mtu 1500 > > > > options=ec07bb > > > > ether 00:07:43:2c:af:10 > > > > inet 37.220.36.28 netmask 0xffffff00 broadcast 37.220.36.255 > > > > nd6 options=9 > > > > media: Ethernet Unknown > > > > status: active > > > > > > > > This is 40G SFP+ DAC. > > > > > > This doesn't look related to the discussion Eric started, but I'd like > > > to point out that is not a reliable link -- "Unknown" media for > > > cxgbe/cxl means the driver has no idea what kind of cable this is and is > > > probably using incorrect settings that happen to work by accident (if > > > this is a working setup). Please provide the output of "cxgbetool > > > t5nex0 modinfo 0 raw" if you'd like to get to the bottom of this. > > > Off-list or new thread is better since it has nothing to do with the > > > stuff in if_media.h > > > > We already discussed about this setup. > > I have next answer from install enginer: "and i'm quite sure it is a + > > cable, Solid Optics is a highly respected cable/transceiver supplier. > > they would not invoice us a + cable if it is not" > > > > Yes, I see in i2c 'Identifier Values' as '0Ch -- QSFP'. QDR (40Gbit). > > So this cable was sold to you as a QSFP+, identifies itself as QSFP (no > plus), and seems to work even though it's not supposed to. Yes. > > > > This is a working setup. And this setup work at 40Gbit w/o errors. > > Ok, let's leave it at that then. Do keep an eye on things like checksum > errors, link flaps, or any other signs of shaky signals on the wire. # netstat -nbI cxl0 Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll cxl0 1500 00:07:43:2c:ad:50 210666777023 0 25518849 15296739966404 410181550989 0 600781280506189 0 cxl0 - 37.220.36.0/2 37.220.36.38 196734318463 - - 10287636760037 404180411324 - 580938380615819 - How I can see checksum errors, link flaps, or any other signs?