Date: Tue, 9 Dec 2014 20:31:36 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Eric Joyner <erj@erj.cc>, Adrian Chadd <adrian@freebsd.org>, Jack F Vogel <jfvogel@gmail.com>, freebsd-arch@freebsd.org Subject: Re: Adding new media types to if_media.h Message-ID: <20141209163136.GA94186@zxy.spb.ru> In-Reply-To: <20141209153539.GA3925@ox> References: <CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg@mail.gmail.com> <20141209130412.GA81921@zxy.spb.ru> <20141209153539.GA3925@ox>
next in thread | previous in thread | raw e-mail | index | archive | help
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> > > ether 00:07:43:2c:af:10 > > inet 37.220.36.28 netmask 0xffffff00 broadcast 37.220.36.255 > > nd6 options=9<PERFORMNUD,IFDISABLED> > > media: Ethernet Unknown <full-duplex> > > 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). This is a working setup. And this setup work at 40Gbit w/o errors. I think driver idea about correct settings irrelevant to reported link speed (reported speed may be need for automatic discovering by network managemnt software, SNMP reporting and etc.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141209163136.GA94186>