Dual-rate transceivers with ixgbe?

Alexander Sack pisymbol at gmail.com
Thu Jun 10 19:59:04 UTC 2010


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?

-aps


More information about the freebsd-net mailing list