Date: Thu, 10 Jun 2010 15:59:01 -0400 From: Alexander Sack <pisymbol@gmail.com> To: Juli Mallett <jmallett@freebsd.org> Cc: freebsd-net@freebsd.org, Jack Vogel <jfvogel@gmail.com> Subject: Re: Dual-rate transceivers with ixgbe? Message-ID: <AANLkTinOnzvjrmmLb3w5jOYEk02CY2tWCwnKxTv8sHS8@mail.gmail.com> In-Reply-To: <AANLkTilqb4y0zEmom0jyg-HEi4yp8D3nkkbUWGHUjWPt@mail.gmail.com> References: <AANLkTinO9NZ8F9TeS68I2ULQgdlMGzlXkinCsywWosAM@mail.gmail.com> <AANLkTinS607kd3wc3F2WWmA6Zk9KL4GhscxEHPtcvxA5@mail.gmail.com> <AANLkTimkxOn9h6SAkTPDqfUM9kl2CZiFrZC_BuNDfRyB@mail.gmail.com> <AANLkTikcQMXk8UebmaynOeeInGiwx8yr0NMGE1yJfm8u@mail.gmail.com> <AANLkTil_YRvU54qHtIMO7mP4yYjojeHVrCHaRcl2K2Ug@mail.gmail.com> <AANLkTim5Ao9nSh6T6HF7NztLgvbTzxuVyr8lSXAJ7bMo@mail.gmail.com> <AANLkTim9-Za5mzLTw7MDAHY_TuIQsQ0SF0_1xpxyGY7v@mail.gmail.com> <AANLkTik-V2frmirwBLtg4RemdEVvPhUmVsOP7CqEkvUi@mail.gmail.com> <AANLkTikqjQic_M3mX7OTx-V0OJxbk4vzxajPmHmIUAKa@mail.gmail.com> <AANLkTikjs42mE5QHnSvZ9x9DI1xfYowvIES-DRORz6hH@mail.gmail.com> <AANLkTilqb4y0zEmom0jyg-HEi4yp8D3nkkbUWGHUjWPt@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 10, 2010 at 3:20 PM, Juli Mallett <jmallett@freebsd.org> wrote: > On Thu, Jun 10, 2010 at 12:04, Alexander Sack <pisymbol@gmail.com> wrote: >> However, would it be possible to please make this a kenv tunable in >> the driver? =A0Its kinda stupid I have to recompile to add a SFP. =A0It >> can certainly be an unsupported feature by you. > > This is a good idea, but asking Jack to commit something that goes > against Intel's wishes and which he's not going to support is probably > a losing strategy. =A0Whether he minds someone else committing might be > another story :) Sorry Jack! :) I am not trying to cause you grief but.... It would SEEM BENEFICIAL to the community to allow unsupported SFPs (again use at your own risk, don't ask Jack why doesn't it work and expect a lot of attention). That's all I am saying. I don't know the history here, so if this topic has been heavily debated on the lists, please forgive. I am also not trying to upset Jack or Intel or anyone here. Good intentions an all that!? > One thing that the base driver probably ought to do is not fail in > attach if there's an unrecognized SFP+ module. =A0Since we get > interrupts on module change (although this doesn't seem to always work > *entirely* right in the stock sources, mostly wrt stored values of > AUTOC and the like) it should be possible to bring the interface up > with the unsupported (and disabled) SFP+ module and do the SFP+ module > probing we already do on hot-swap. Alright, let me see if I can test that. Let me rephrase so I validate what you are saying: The driver can come up with an unsupported module but disable the interface (ifconfig shows the interface, etc.). If you then hot-swap a supported SFP, it should come up then with a ifconfig down/up cycle. Right? As it stand now, if you load the driver with an unsupported module, it will not attach at all causing you to reload the entire driver OR reboot the box to have it reattach to the other SFP. Do I understand you correctly? >> Patch attached. =A0Tested with CURRENT driver on a 7.2-amd64-release >> machine. =A0If you set the tunable to 1, ixgbe loads without issue. =A0I= f >> you leave it to zero (default), it will not attach to unsupported >> SFPs. > > If you're going to do this, you ought to support SFP as well as SFP+ > modules which requires a few more changes. =A0But not very many :) LOL....right....let me adjust...let me look at the SFP path. > Although some SFP modules seem to return something for the > comp_codes_10g read, which makes deciding which SFI mode to configure > non-trivial, short of providing an actual vendor/model switch. I want to avoid this completely. There is already a vendor_oui switch which I now understand are the specific SFPs Intel tests and certifies with! (right?) I think the policy should be (ideally): - Attach to all supported tested Intel stamp-of-approval SFPs (normal driver path) - Disable any unsupported SFPs but still complete driver attachment - Tunable to control attaching to an unsupported SFP (YOU AT YOUR OWN RISK) Is that right? -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinOnzvjrmmLb3w5jOYEk02CY2tWCwnKxTv8sHS8>