Adding new media types to if_media.h

[Slawa Olhovchenkov]

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<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).
> 
> 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 <Link#4>      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?