Date: Thu, 10 Jun 2010 16:02:23 -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: <AANLkTil3ojaY_WsG4mgwlBGFHEyyEERBJ7eI6mZzQipw@mail.gmail.com> In-Reply-To: <AANLkTinOnzvjrmmLb3w5jOYEk02CY2tWCwnKxTv8sHS8@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> <AANLkTinOnzvjrmmLb3w5jOYEk02CY2tWCwnKxTv8sHS8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 10, 2010 at 3:59 PM, Alexander Sack <pisymbol@gmail.com> wrote: > On Thu, Jun 10, 2010 at 3:20 PM, Juli Mallett <jmallett@freebsd.org> wrot= e: >> 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! =A0:) =A0I 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). =A0That's all I am saying. =A0I don't know th= e > 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. =A0Good > 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. =A0Let 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. =A0Right? > > 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. =A0= If >>> 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. =A0There is already a vendor_oui switch > which I now understand are the specific SFPs Intel tests and certifies > with! =A0(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 RIS= K) > > Is that right? > Sorry for the mixed conversation in that last email....I think you guys can figure out who is who! :-)! -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTil3ojaY_WsG4mgwlBGFHEyyEERBJ7eI6mZzQipw>