From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 20:02:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5238106566B; Thu, 10 Jun 2010 20:02:25 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 655528FC19; Thu, 10 Jun 2010 20:02:25 +0000 (UTC) Received: by gyh20 with SMTP id 20so338498gyh.13 for ; Thu, 10 Jun 2010 13:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FqQWD4gxEajH+/FaBQFeY93Bw3lL2A/i9EUhpXDgAE0=; b=tTo6LGktomN7clE6wgUw1g0k+He7ZPDbk/x/8eY9BGjKkPMrXJeC7yVIGtGsuXZNXh Vu5tmraUHk8FqnAUZ4UKUMPx5P4ptrd/2KMjxUUyWfG1pE+p3POLuooSR0gQPUneCf4V CKhKXlHdhxILmWlRFzqLWVsh9+cyaRQp9ujeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CU6pOMpsZNceXSiegC2ff3HWEOuChoa4S4ybQJpAxFG+H/p/c/QgY3zP8+LhLklsE3 DNBRe87loNOPLqYdB4xcpbz+tEtEo1qiXhNsfJdCbnrXD2Nz5bZYyYoI0gxyBgg9YZ3q ee5VNiJnijrlx1IWoE1IrF0nFAaseWzq9rzN4= MIME-Version: 1.0 Received: by 10.101.145.9 with SMTP id x9mr700693ann.13.1276200143614; Thu, 10 Jun 2010 13:02:23 -0700 (PDT) Received: by 10.100.137.4 with HTTP; Thu, 10 Jun 2010 13:02:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 16:02:23 -0400 Message-ID: From: Alexander Sack To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with ixgbe? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 20:02:25 -0000 On Thu, Jun 10, 2010 at 3:59 PM, Alexander Sack wrote: > On Thu, Jun 10, 2010 at 3:20 PM, Juli Mallett wrot= e: >> On Thu, Jun 10, 2010 at 12:04, Alexander Sack 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