Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Dec 2014 17:04:13 +0400
From:      Slawa Olhovchenkov <slw@zxy.spb.ru>
To:        Eric Joyner <erj@erj.cc>
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:  <20141209130412.GA81921@zxy.spb.ru>
In-Reply-To: <CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg@mail.gmail.com>
References:  <CA%2Bb0zg80VPn%2BXLjQ5HZxLqsM-%2Bev65g8AYDpGfQD=Gruv-LPJg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
I think this is must be 'media: Ethernet 40G Unknown <full-duplex>'
because supported cable speed detetcted by i2c, unknown only cable type.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141209130412.GA81921>