On Thu, Jun 10, 2010 at 3:59 PM, Alexander Sack <pisym...@gmail.com> wrote: > On Thu, Jun 10, 2010 at 3:20 PM, Juli Mallett <jmall...@freebsd.org> wrote: >> On Thu, Jun 10, 2010 at 12:04, Alexander Sack <pisym...@gmail.com> wrote: >>> However, would it be possible to please make this a kenv tunable in >>> the driver? Its kinda stupid I have to recompile to add a SFP. It >>> 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. Whether 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. Since 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. Tested with CURRENT driver on a 7.2-amd64-release >>> machine. If you set the tunable to 1, ixgbe loads without issue. 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. But 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? >
Sorry for the mixed conversation in that last email....I think you guys can figure out who is who! :-)! -aps _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
