Dual-rate transceivers with ixgbe?

[Alexander Sack]

On Thu, Jun 10, 2010 at 3:59 PM, Alexander Sack <pisymbol at gmail.com> wrote:
> On Thu, Jun 10, 2010 at 3:20 PM, Juli Mallett <jmallett at freebsd.org> wrote:
>> On Thu, Jun 10, 2010 at 12:04, Alexander Sack <pisymbol at 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