From owner-freebsd-net@freebsd.org Thu Jul 16 13:01:52 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2811199C51C for ; Thu, 16 Jul 2015 13:01:52 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward17p.cmail.yandex.net (forward17p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::b3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE2AB1AF5; Thu, 16 Jul 2015 13:01:51 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web4g.yandex.ru (web4g.yandex.ru [95.108.252.104]) by forward17p.cmail.yandex.net (Yandex) with ESMTP id 8AAE322439; Thu, 16 Jul 2015 16:01:46 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web4g.yandex.ru (Yandex) with ESMTP id DBCD23800CAF; Thu, 16 Jul 2015 16:01:45 +0300 (MSK) Received: by web4g.yandex.ru with HTTP; Thu, 16 Jul 2015 16:01:45 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: Alan Somers , FreeBSD Net , Navdeep Parhar In-Reply-To: References: Subject: Re: Displaying the supported module types of a network adapter MIME-Version: 1.0 Message-Id: <1127061437051705@web4g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 16 Jul 2015 16:01:45 +0300 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Jul 2015 13:01:52 -0000 16.07.2015, 01:25, "Alan Somers" : > SIOCGIFMEDIA will return the list of supported media types and the > current media type of a network interface. But for NICs with > pluggable modules (SFP+, QSFP, etc), it would also be useful to know > the allowed module type. I can't find any way to determine that using Well, it might be a bit tricky. There are basically 2 parts: physical constraints and logical ones. E.g. first we have to specify what we could physically insert (gbic, rj45?, sfp/sfp+, qsfp+). Here we can consider adopting values from ftp://ftp.seagate.com/sff/SFF-8024.PDF Table 4.1 Next step would be specifying what exact modules could be used. Examples could be: * 1G sfp on 10G card (chip constraint) * qsfp<>sfp hydra cables (chip constraint) * QSFP-2-SFP+ (chip constraint) * using SR/LR transceiver on card, sold as "Direct attached one" (Vendor SW constraint) It looks like that bit masks from TABLE 6-17 SPECIFICATION COMPLIANCE CODES from ftp://ftp.seagate.com/sff/SFF-8636.PDF can be adopted for the logical part. so we could have something like { u16 version; u16 cage_type; u32 spare; u64 module_type; u64 spare; } for the new ioctl. > the standard tools. cxgbe(4) is aware of the module type allowed by > the card, but doesn't expose that information to userspace. I can add > a simple sysctl to do so, but it would be better to add a standard > ioctl that can be used by all network drivers. > > Besides cxgbe(4), can any other network drivers support this? If so, > would anybody else be interested? If so, should I add it to the > "ifconfig -v" output? > > -Alan