From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 14:18:04 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7240ED0D for ; Mon, 8 Dec 2014 14:18:04 +0000 (UTC) Received: from testsoekris.hotsoft.nl (unknown [IPv6:2001:888:1227:0:200:24ff:fec9:5934]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28DFA948 for ; Mon, 8 Dec 2014 14:18:03 +0000 (UTC) Received: from beastie.hotsoft.nl (beastie.hotsoft.nl [IPv6:2001:888:1227:0:219:d1ff:fee8:91eb]) by testsoekris.hotsoft.nl (8.14.7/8.14.7) with ESMTP id sB8EI0vc063301; Mon, 8 Dec 2014 15:18:00 +0100 (CET) (envelope-from hans@beastielabs.net) Message-ID: <5485B318.3030402@beastielabs.net> Date: Mon, 08 Dec 2014 15:18:00 +0100 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Process reapers References: <20141201185237.GC97072@kib.kiev.ua> In-Reply-To: <20141201185237.GC97072@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 14:18:04 -0000 On 12/01/14 19:52, Konstantin Belousov wrote: > Please find at https://www.kib.kiev.ua/kib/reaper.6.patch > the patch which adds a way for the process to declare itself a reaper > for the subtree of processes forked after the event. In other words, > after the process is marked as reaper, all orphaned children somewhere > in subtree after the reaper, are reparented to the process instead of > init(8). > > The API is based on the following DragonFlyBSD commit > http://gitweb.dragonflybsd.org/dragonfly.git/commit/fc3bc2868ad212f3b412ad13f0eaa35b3f8d458d > Linux has somewhat similar prctl(PR_SET_CHILD_SUBREAPER). > Solaris is most advanced in the area, the feature which provides > the same function is contracts(4), which is very advanced and > IMO over-designed interface. > > I did not wrote the man page, the API is still in flux. It should > be relatively clean how to use the thing by the descriptive names > and comments in header file. One of the test programs illustrating > the interface is available at https://www.kib.kiev.ua/kib/reaper2.c . > See http://leaf.dragonflybsd.org/cgi/web-man?command=procctl§ion=2 > for the description of DragonFly interface. > > The feature was requested by bapt, jilles already provided useful > feedback that was incorporated into the patch. > > Please review and comment. I gave your patch a try over the weekend (I had to reassemble a system and install 11-CURRENT for testing and that took a while.) The test program you provided demonstrates quite clearly what is intended and it also functions well. First thing I asked myself was: what happens if the reaper dies? What I see happening is that the reaper of the dead reaper becomes the reaper of its process subtree. The new reaper will often be init but it is also possible it is another process and that sounds OK. Concerning the API: The call of procctl() with subcommands PROC_REAP_ACQUIRE, PROC_REAP_RELEASE and PROC_REAP_STATUS all require a pid_t as second argument that -must- be the current process id, as obtained by getpid(). As far as I can see procctl() returns an error otherwise, so the pid argument seems a bit superfluous. Is it absolutely required to use procctl() for this functionality? Isn't a separate system call for process reaping a better solution? Second, the PROC_REAP_GETPIDS command indeed provides a snapshot of the subtree at the moment procctl() is called but on a busy system many processes are created and go away, so this is very dynamic information. I wonder what you expect to do with this call. As far as I know PROC_REAP_KILL is the first facility apart from kill(2) that signals a collection of processes. Isn't there a way to incorporate it in kill(2). I have no idea what you (or bapt@) are planning to do with this reaper stuff, maybe you could share a bit more detailed information about your goals. Kind regards, Hans From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 14:42:39 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 147C23FA for ; Mon, 8 Dec 2014 14:42:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC69AC08 for ; Mon, 8 Dec 2014 14:42:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sB8EgV71082233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2014 16:42:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sB8EgV71082233 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sB8EgVbX082232; Mon, 8 Dec 2014 16:42:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Dec 2014 16:42:30 +0200 From: Konstantin Belousov To: Hans Ottevanger Subject: Re: Process reapers Message-ID: <20141208144230.GU97072@kib.kiev.ua> References: <20141201185237.GC97072@kib.kiev.ua> <5485B318.3030402@beastielabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5485B318.3030402@beastielabs.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 14:42:39 -0000 On Mon, Dec 08, 2014 at 03:18:00PM +0100, Hans Ottevanger wrote: > On 12/01/14 19:52, Konstantin Belousov wrote: > > Please find at https://www.kib.kiev.ua/kib/reaper.6.patch > > the patch which adds a way for the process to declare itself a reaper > > for the subtree of processes forked after the event. In other words, > > after the process is marked as reaper, all orphaned children somewhere > > in subtree after the reaper, are reparented to the process instead of > > init(8). > > > > The API is based on the following DragonFlyBSD commit > > http://gitweb.dragonflybsd.org/dragonfly.git/commit/fc3bc2868ad212f3b412ad13f0eaa35b3f8d458d > > Linux has somewhat similar prctl(PR_SET_CHILD_SUBREAPER). > > Solaris is most advanced in the area, the feature which provides > > the same function is contracts(4), which is very advanced and > > IMO over-designed interface. > > > > I did not wrote the man page, the API is still in flux. It should > > be relatively clean how to use the thing by the descriptive names > > and comments in header file. One of the test programs illustrating > > the interface is available at https://www.kib.kiev.ua/kib/reaper2.c . > > See http://leaf.dragonflybsd.org/cgi/web-man?command=procctl§ion=2 > > for the description of DragonFly interface. > > > > The feature was requested by bapt, jilles already provided useful > > feedback that was incorporated into the patch. > > > > Please review and comment. > > I gave your patch a try over the weekend (I had to reassemble a system > and install 11-CURRENT for testing and that took a while.) > > The test program you provided demonstrates quite clearly what is > intended and it also functions well. > > First thing I asked myself was: what happens if the reaper dies? What I > see happening is that the reaper of the dead reaper becomes the reaper > of its process subtree. The new reaper will often be init but it is also > possible it is another process and that sounds OK. RIght, this is intended behaviour. > > Concerning the API: > > The call of procctl() with subcommands PROC_REAP_ACQUIRE, > PROC_REAP_RELEASE and PROC_REAP_STATUS all require a pid_t as second > argument that -must- be the current process id, as obtained by getpid(). > As far as I can see procctl() returns an error otherwise, so the pid > argument seems a bit superfluous. Is it absolutely required to use > procctl() for this functionality? Isn't a separate system call for > process reaping a better solution? REAP_STATUS does not require the pid to be equal getpid(). I used the procctl(2) since this syscall was intended as administrative control over process facility, and reaper is exactly this sort of thing. IMO adding new syscall for reaping is overkill, e.g. Linux uses its analog of procctl (prctl AFAIR) for the same purpose. Requiring pid for two rarely used (at the start and at the end of being reaper) points of reaper life is fine from my PoV. What I apparently dislike from the current procctl(2) interface is the lack of the integer argument along the pointer. I.e. now I would prefer a signature similar to ptrace(2). Go know when single-use procctl(2) was added. > > Second, the PROC_REAP_GETPIDS command indeed provides a snapshot of the > subtree at the moment procctl() is called but on a busy system many > processes are created and go away, so this is very dynamic information. > I wonder what you expect to do with this call. REAP_GETPIDS return a list with two kinds of pids. One kind is just pid of a process in the descending tree of subprocesses. There is nothing much you could do with the pid except showing it to user, similarly to ps(1). Other kind if pid of the child process, marked with the corresponding flag in the list. Since the pid of child is sort of handle in the parent process, you can do interesting things with it, e.g. killing certainly correct process, or wait(2) for it. Note that any descendant is either killed and reaped by its parent, or is re-parented ot the reaper, which makes it child of the reaper. This allows for reaper to kill all the tree in race-free manner, guaranteeing that no runaway process was left. The non-children pids are useful for informational purposes, to explain the state to the user, from the orchestrator. Think about batch runners, like port building tools, which allow reliable termination of the builds, without jailing. > > As far as I know PROC_REAP_KILL is the first facility apart from kill(2) > that signals a collection of processes. Isn't there a way to incorporate > it in kill(2). I am not sure what you propose. kill(2) and killpg(2) have defined semantic, I do not see how could kill(2) can incorporate the tweaky behaviour of the REAP_KILL. > > I have no idea what you (or bapt@) are planning to do with this reaper > stuff, maybe you could share a bit more detailed information about your > goals. It was requested by bapt, who could explain it further. As I understand, port bulk builds and utilities like timeout(1) are to use the facility. From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 09:06:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33640F60; Tue, 9 Dec 2014 09:06:08 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6F245E5; Tue, 9 Dec 2014 09:06:07 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id z10so192700pdj.0 for ; Tue, 09 Dec 2014 01:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=LocTVtiW5mvtcmdCS9wizVH/iXgfoffJlWaH1uZ36pM=; b=owfazaW75P3+qvrxO3zaTYyKX5cM324aWt1I0KHOD46C38WesrNNBYsQvrCM6BNOsX zpl9ddEjpL1D+cnRLiC+ViVOyo4DBPowjm6aaKAe2UIL7mC5VrOBQe2eMh5Xv0859h+K ItFlXbYNX455kCBYsROdwpwrZqViOn7kQzKV80P4m38C0oTy2otHbnw1eZLZ2q78HyxF KaBq4zp9cmc8gVRfitNYO9+WBd3nxtMEmI/ay6IuTpym/6NS0gOTAZ6v7ClGTKpcMg0v SBqWdNJrKh7vOs+KsPoEnCotFN//G2L00GHpCMK2dHlqLriTTYCA8YP8BhaJCOECjpAN KXdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erj.cc; s=ericroxx; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=LocTVtiW5mvtcmdCS9wizVH/iXgfoffJlWaH1uZ36pM=; b=Ttmo4CmvgQJkdqGzw9fXY/z0LAQ+kLU7XI4YV/OGoyDDQnepYKuyff6jSR4qT7Ay7K yDz12ci8U8Kih/sHY22UDczv9FVTtgOiFyBsXLoYG4KQ7WWceheLE1/0H9WO/ucYT7p8 KEVdk85ocBeZFQUuF68Ytb08xF1u/CYAbWhGQ= X-Received: by 10.70.22.227 with SMTP id h3mr29091912pdf.160.1418115967312; Tue, 09 Dec 2014 01:06:07 -0800 (PST) MIME-Version: 1.0 Sender: ricera10@gmail.com Received: by 10.70.89.209 with HTTP; Tue, 9 Dec 2014 01:05:27 -0800 (PST) From: Eric Joyner Date: Tue, 9 Dec 2014 01:05:27 -0800 X-Google-Sender-Auth: 75VpiSZ0ZB-pRgX27TGWJKywKSE Message-ID: Subject: Adding new media types to if_media.h To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , Jack F Vogel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 09:06:08 -0000 This is a continuation of a discussion from off the list: ixgbe needs to support devices with media types that aren't in if_media.h; for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we're running into the issue that there is no room for all of these types under the IFM_ETHER category; there's only room for two more (and per John Baldwin, only one more if one of those two unused types is to be used for a reserved type). Long term, there are going to be tons of media types for future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already supports media types that aren't in if_media.h, either. So, something needs to change. Does anyone have any thoughts on what should happen? I've thought of a few things, but I don't have an adequate grasp of what the pros/cons of each are: 1. Add a new media category (like IFM_ETHER) and change kernel code to treat it like the existing IFM_ETHER. This creates ~28 new media types we can use, but it may just be delaying the inevitable for a short time. 2. Extend media value from 32-bits to 64-bits. I don't have a good idea of what the consequences are of this on architectures that aren't amd64. 3. (Initially suggested by Adrian) would be to create a new media type struct (instead of using an int value) or adding an extra value to the existing ifmedia/ifmedia_entry struct for this. This sounds like the best solution to me, but I don't know how much effort it would take to implement -- does ifconfig need a lot of changing to handle this? Thoughts? Any previous discussions worth looking at? - Eric From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 13:04:22 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED9244A5; Tue, 9 Dec 2014 13:04:22 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A79F6DA; Tue, 9 Dec 2014 13:04:22 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XyKSb-000Ld6-1u; Tue, 09 Dec 2014 17:04:13 +0400 Date: Tue, 9 Dec 2014 17:04:13 +0400 From: Slawa Olhovchenkov To: Eric Joyner Subject: Re: Adding new media types to if_media.h Message-ID: <20141209130412.GA81921@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 13:04:23 -0000 On Tue, Dec 09, 2014 at 01:05:27AM -0800, Eric Joyner wrote: > This is a continuation of a discussion from off the list: > > ixgbe needs to support devices with media types that aren't in if_media.h; > for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we're > running into the issue that there is no room for all of these types under > the IFM_ETHER category; there's only room for two more (and per John > Baldwin, only one more if one of those two unused types is to be used for a > reserved type). Long term, there are going to be tons of media types for > future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > supports media types that aren't in if_media.h, either. > > So, something needs to change. Does anyone have any thoughts on what should > happen? I've thought of a few things, but I don't have an adequate grasp of > what the pros/cons of each are: > > 1. Add a new media category (like IFM_ETHER) and change kernel code to > treat it like the existing IFM_ETHER. This creates ~28 new media types we > can use, but it may just be delaying the inevitable for a short time. > > 2. Extend media value from 32-bits to 64-bits. I don't have a good idea of > what the consequences are of this on architectures that aren't amd64. > > 3. (Initially suggested by Adrian) would be to create a new media type > struct (instead of using an int value) or adding an extra value to the > existing ifmedia/ifmedia_entry struct for this. This sounds like the best > solution to me, but I don't know how much effort it would take to implement > -- does ifconfig need a lot of changing to handle this? > > Thoughts? Any previous discussions worth looking at? I think need support for media type and subtype, i.e.: cxl0: flags=8843 metric 0 mtu 1500 options=ec07bb ether 00:07:43:2c:af:10 inet 37.220.36.28 netmask 0xffffff00 broadcast 37.220.36.255 nd6 options=9 media: Ethernet Unknown status: active This is 40G SFP+ DAC. I think this is must be 'media: Ethernet 40G Unknown ' because supported cable speed detetcted by i2c, unknown only cable type. From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 15:27:21 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95943557; Tue, 9 Dec 2014 15:27:21 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B11D231; Tue, 9 Dec 2014 15:27:20 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NGB0083SMXAK850@st11p02mm-asmtp001.mac.com>; Tue, 09 Dec 2014 15:27:13 +0000 (GMT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Adding new media types to if_media.h From: Rui Paulo In-reply-to: Date: Tue, 09 Dec 2014 07:27:10 -0800 Content-transfer-encoding: quoted-printable Message-id: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> References: To: Eric Joyner X-Mailer: Apple Mail (2.1993) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-09_05:2014-12-09,2014-12-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412090154 Cc: Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 15:27:21 -0000 On Dec 9, 2014, at 01:05, Eric Joyner wrote: >=20 > This is a continuation of a discussion from off the list: >=20 > ixgbe needs to support devices with media types that aren't in = if_media.h; > for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, = we're > running into the issue that there is no room for all of these types = under > the IFM_ETHER category; there's only room for two more (and per John > Baldwin, only one more if one of those two unused types is to be used = for a > reserved type). Long term, there are going to be tons of media types = for > future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > supports media types that aren't in if_media.h, either. >=20 > So, something needs to change. Does anyone have any thoughts on what = should > happen? I've thought of a few things, but I don't have an adequate = grasp of > what the pros/cons of each are: >=20 > 1. Add a new media category (like IFM_ETHER) and change kernel code to > treat it like the existing IFM_ETHER. This creates ~28 new media types = we > can use, but it may just be delaying the inevitable for a short time. >=20 > 2. Extend media value from 32-bits to 64-bits. I don't have a good = idea of > what the consequences are of this on architectures that aren't amd64. >=20 > 3. (Initially suggested by Adrian) would be to create a new media type > struct (instead of using an int value) or adding an extra value to the > existing ifmedia/ifmedia_entry struct for this. This sounds like the = best > solution to me, but I don't know how much effort it would take to = implement > -- does ifconfig need a lot of changing to handle this? ifconfig is a macro-intensive application, so maybe it's not that much = work. > Thoughts? Any previous discussions worth looking at? Hmm, it looks like you're limited in the number of bits because of how = the word was laid out. We can't simple remove token ring and get more = bits for ethernet... We could create another IFM_40GETHERNET type to = replace token ring but that would be ugly (the IFM_TYPE() macro could = handle this idiosyncrasy). I think if_media should probably be a structure with unions to store the = subtypes. net80211 has the same problem with MCS rates and we ended up = storing them outside if_media because of this.=20 -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 15:35:47 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4160F798; Tue, 9 Dec 2014 15:35:47 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10D66356; Tue, 9 Dec 2014 15:35:47 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id eu11so756100pac.22 for ; Tue, 09 Dec 2014 07:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=61+hF24eYIGjkbatguO9qYGfTDcvGZtkQ6y7Htj1JT8=; b=U/Pb4+xO7zDjcssQAheVuxNx0ri7/8LQZFTBIsccQNJSZKl7tjpOKkS0PTDLqiswo4 MQp5IeU7FYAlYrPv7iOKancofOpqiBPJNP9WggJ8xgYY6wBvOpQ2gim3/5Ly9S3XzejN pEoJHObUoR+fjBYskesBk9yE5S4svl6ZnYSni2f4W8W9w/AEBNjcStcwD49Qtk3aJ7hJ nivVdc9BIjdGQecNBwlcl6LkS84QMW3RCBy5LDAhwPlVj1yiyFegkUIsHfc0fgyqCQvy LQ0/qua2vNdibagHqxtCYHlbRdjSTWUrBCZJ0wTZ1tMZXRlAcPvMORJiTpFnZwVKy3uT DeEg== X-Received: by 10.68.208.65 with SMTP id mc1mr6341535pbc.111.1418139346553; Tue, 09 Dec 2014 07:35:46 -0800 (PST) Received: from ox ([24.6.44.228]) by mx.google.com with ESMTPSA id kb16sm1819735pbb.34.2014.12.09.07.35.44 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Dec 2014 07:35:45 -0800 (PST) Date: Tue, 9 Dec 2014 07:35:39 -0800 From: Navdeep Parhar To: Slawa Olhovchenkov Subject: Re: Adding new media types to if_media.h Message-ID: <20141209153539.GA3925@ox> Mail-Followup-To: Slawa Olhovchenkov , Eric Joyner , Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org References: <20141209130412.GA81921@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141209130412.GA81921@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , Jack F Vogel , Eric Joyner , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 15:35:47 -0000 On Tue, Dec 09, 2014 at 05:04:13PM +0400, Slawa Olhovchenkov wrote: > On Tue, Dec 09, 2014 at 01:05:27AM -0800, Eric Joyner wrote: > > > This is a continuation of a discussion from off the list: > > > > ixgbe needs to support devices with media types that aren't in if_media.h; > > for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we're > > running into the issue that there is no room for all of these types under > > the IFM_ETHER category; there's only room for two more (and per John > > Baldwin, only one more if one of those two unused types is to be used for a > > reserved type). Long term, there are going to be tons of media types for > > future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > > supports media types that aren't in if_media.h, either. > > > > So, something needs to change. Does anyone have any thoughts on what should > > happen? I've thought of a few things, but I don't have an adequate grasp of > > what the pros/cons of each are: > > > > 1. Add a new media category (like IFM_ETHER) and change kernel code to > > treat it like the existing IFM_ETHER. This creates ~28 new media types we > > can use, but it may just be delaying the inevitable for a short time. > > > > 2. Extend media value from 32-bits to 64-bits. I don't have a good idea of > > what the consequences are of this on architectures that aren't amd64. > > > > 3. (Initially suggested by Adrian) would be to create a new media type > > struct (instead of using an int value) or adding an extra value to the > > existing ifmedia/ifmedia_entry struct for this. This sounds like the best > > solution to me, but I don't know how much effort it would take to implement > > -- does ifconfig need a lot of changing to handle this? > > > > Thoughts? Any previous discussions worth looking at? > > I think need support for media type and subtype, i.e.: > > cxl0: flags=8843 metric 0 mtu 1500 > options=ec07bb > ether 00:07:43:2c:af:10 > inet 37.220.36.28 netmask 0xffffff00 broadcast 37.220.36.255 > nd6 options=9 > media: Ethernet Unknown > status: active > > This is 40G SFP+ DAC. This doesn't look related to the discussion Eric started, but I'd like to point out that is not a reliable link -- "Unknown" media for cxgbe/cxl means the driver has no idea what kind of cable this is and is probably using incorrect settings that happen to work by accident (if this is a working setup). Please provide the output of "cxgbetool t5nex0 modinfo 0 raw" if you'd like to get to the bottom of this. Off-list or new thread is better since it has nothing to do with the stuff in if_media.h Regards, Navdeep > I think this is must be 'media: Ethernet 40G Unknown ' > because supported cable speed detetcted by i2c, unknown only cable type. > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 16:31:40 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5EFF972; Tue, 9 Dec 2014 16:31:40 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7FC56C82; Tue, 9 Dec 2014 16:31:40 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XyNhI-000PJn-Jf; Tue, 09 Dec 2014 20:31:36 +0400 Date: Tue, 9 Dec 2014 20:31:36 +0400 From: Slawa Olhovchenkov To: Eric Joyner , Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org Subject: Re: Adding new media types to if_media.h Message-ID: <20141209163136.GA94186@zxy.spb.ru> References: <20141209130412.GA81921@zxy.spb.ru> <20141209153539.GA3925@ox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141209153539.GA3925@ox> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 16:31:41 -0000 On Tue, Dec 09, 2014 at 07:35:39AM -0800, Navdeep Parhar wrote: > On Tue, Dec 09, 2014 at 05:04:13PM +0400, Slawa Olhovchenkov wrote: > > On Tue, Dec 09, 2014 at 01:05:27AM -0800, Eric Joyner wrote: > > > > > This is a continuation of a discussion from off the list: > > > > > > ixgbe needs to support devices with media types that aren't in if_media.h; > > > for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we're > > > running into the issue that there is no room for all of these types under > > > the IFM_ETHER category; there's only room for two more (and per John > > > Baldwin, only one more if one of those two unused types is to be used for a > > > reserved type). Long term, there are going to be tons of media types for > > > future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > > > supports media types that aren't in if_media.h, either. > > > > > > So, something needs to change. Does anyone have any thoughts on what should > > > happen? I've thought of a few things, but I don't have an adequate grasp of > > > what the pros/cons of each are: > > > > > > 1. Add a new media category (like IFM_ETHER) and change kernel code to > > > treat it like the existing IFM_ETHER. This creates ~28 new media types we > > > can use, but it may just be delaying the inevitable for a short time. > > > > > > 2. Extend media value from 32-bits to 64-bits. I don't have a good idea of > > > what the consequences are of this on architectures that aren't amd64. > > > > > > 3. (Initially suggested by Adrian) would be to create a new media type > > > struct (instead of using an int value) or adding an extra value to the > > > existing ifmedia/ifmedia_entry struct for this. This sounds like the best > > > solution to me, but I don't know how much effort it would take to implement > > > -- does ifconfig need a lot of changing to handle this? > > > > > > Thoughts? Any previous discussions worth looking at? > > > > I think need support for media type and subtype, i.e.: > > > > cxl0: flags=8843 metric 0 mtu 1500 > > options=ec07bb > > ether 00:07:43:2c:af:10 > > inet 37.220.36.28 netmask 0xffffff00 broadcast 37.220.36.255 > > nd6 options=9 > > media: Ethernet Unknown > > status: active > > > > This is 40G SFP+ DAC. > > This doesn't look related to the discussion Eric started, but I'd like > to point out that is not a reliable link -- "Unknown" media for > cxgbe/cxl means the driver has no idea what kind of cable this is and is > probably using incorrect settings that happen to work by accident (if > this is a working setup). Please provide the output of "cxgbetool > t5nex0 modinfo 0 raw" if you'd like to get to the bottom of this. > Off-list or new thread is better since it has nothing to do with the > stuff in if_media.h We already discussed about this setup. I have next answer from install enginer: "and i'm quite sure it is a + cable, Solid Optics is a highly respected cable/transceiver supplier. they would not invoice us a + cable if it is not" Yes, I see in i2c 'Identifier Values' as '0Ch -- QSFP'. QDR (40Gbit). This is a working setup. And this setup work at 40Gbit w/o errors. I think driver idea about correct settings irrelevant to reported link speed (reported speed may be need for automatic discovering by network managemnt software, SNMP reporting and etc.) From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 16:43:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA5D6EE; Tue, 9 Dec 2014 16:43:39 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B39A0DC1; Tue, 9 Dec 2014 16:43:39 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id fp1so859067pdb.38 for ; Tue, 09 Dec 2014 08:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ANmtLqsgjdEoyRzZ37VqQRCa67IW6PlsQKLweH4ySS0=; b=i9wtSmOaC5Dq2l3y6yTFrRkzCr6g+eRaX9QP73SBnOqR06wTdjhmaEOD68KCjhoGH3 ql4PIw8+rlbftG4DbkjBt9abM0Ri+g1X6lV8YWueLD2FvsktxUbk/szfgA0P2jPA5CbH vj4LqWSAp0+H2qUzsjnkVpAT6pLE4Zb72PmCcL4+XRmhjlKWTMT+GFJ6FlXWI9NDvELY qVucCPJBia07imLm876+OF9TN43wmtU37eLrHCmgZLWhlbx6xhnCymY4g3QpnFHcaeSC zxRTkvYCjQ2H+QhcCiwoEpFSsX0yUVoiaWY4hAp3d2ceLtwujdqMQZ6Ij9a1S08EdW2z eDMw== X-Received: by 10.67.6.233 with SMTP id cx9mr7093600pad.110.1418143419194; Tue, 09 Dec 2014 08:43:39 -0800 (PST) Received: from ox ([24.6.44.228]) by mx.google.com with ESMTPSA id ug6sm1905915pbc.72.2014.12.09.08.43.37 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Dec 2014 08:43:38 -0800 (PST) Date: Tue, 9 Dec 2014 08:43:34 -0800 From: Navdeep Parhar To: Slawa Olhovchenkov Subject: Re: Adding new media types to if_media.h Message-ID: <20141209164334.GB3925@ox> Mail-Followup-To: Slawa Olhovchenkov , Eric Joyner , Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org References: <20141209130412.GA81921@zxy.spb.ru> <20141209153539.GA3925@ox> <20141209163136.GA94186@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141209163136.GA94186@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , Jack F Vogel , Eric Joyner , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 16:43:40 -0000 On Tue, Dec 09, 2014 at 08:31:36PM +0400, Slawa Olhovchenkov wrote: > On Tue, Dec 09, 2014 at 07:35:39AM -0800, Navdeep Parhar wrote: > > > On Tue, Dec 09, 2014 at 05:04:13PM +0400, Slawa Olhovchenkov wrote: > > > On Tue, Dec 09, 2014 at 01:05:27AM -0800, Eric Joyner wrote: > > > > > > > This is a continuation of a discussion from off the list: > > > > > > > > ixgbe needs to support devices with media types that aren't in if_media.h; > > > > for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we're > > > > running into the issue that there is no room for all of these types under > > > > the IFM_ETHER category; there's only room for two more (and per John > > > > Baldwin, only one more if one of those two unused types is to be used for a > > > > reserved type). Long term, there are going to be tons of media types for > > > > future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > > > > supports media types that aren't in if_media.h, either. > > > > > > > > So, something needs to change. Does anyone have any thoughts on what should > > > > happen? I've thought of a few things, but I don't have an adequate grasp of > > > > what the pros/cons of each are: > > > > > > > > 1. Add a new media category (like IFM_ETHER) and change kernel code to > > > > treat it like the existing IFM_ETHER. This creates ~28 new media types we > > > > can use, but it may just be delaying the inevitable for a short time. > > > > > > > > 2. Extend media value from 32-bits to 64-bits. I don't have a good idea of > > > > what the consequences are of this on architectures that aren't amd64. > > > > > > > > 3. (Initially suggested by Adrian) would be to create a new media type > > > > struct (instead of using an int value) or adding an extra value to the > > > > existing ifmedia/ifmedia_entry struct for this. This sounds like the best > > > > solution to me, but I don't know how much effort it would take to implement > > > > -- does ifconfig need a lot of changing to handle this? > > > > > > > > Thoughts? Any previous discussions worth looking at? > > > > > > I think need support for media type and subtype, i.e.: > > > > > > cxl0: flags=8843 metric 0 mtu 1500 > > > options=ec07bb > > > ether 00:07:43:2c:af:10 > > > inet 37.220.36.28 netmask 0xffffff00 broadcast 37.220.36.255 > > > nd6 options=9 > > > media: Ethernet Unknown > > > status: active > > > > > > This is 40G SFP+ DAC. > > > > This doesn't look related to the discussion Eric started, but I'd like > > to point out that is not a reliable link -- "Unknown" media for > > cxgbe/cxl means the driver has no idea what kind of cable this is and is > > probably using incorrect settings that happen to work by accident (if > > this is a working setup). Please provide the output of "cxgbetool > > t5nex0 modinfo 0 raw" if you'd like to get to the bottom of this. > > Off-list or new thread is better since it has nothing to do with the > > stuff in if_media.h > > We already discussed about this setup. > I have next answer from install enginer: "and i'm quite sure it is a + > cable, Solid Optics is a highly respected cable/transceiver supplier. > they would not invoice us a + cable if it is not" > > Yes, I see in i2c 'Identifier Values' as '0Ch -- QSFP'. QDR (40Gbit). So this cable was sold to you as a QSFP+, identifies itself as QSFP (no plus), and seems to work even though it's not supposed to. > > This is a working setup. And this setup work at 40Gbit w/o errors. Ok, let's leave it at that then. Do keep an eye on things like checksum errors, link flaps, or any other signs of shaky signals on the wire. Regards, Navdeep > > I think driver idea about correct settings irrelevant to reported link > speed (reported speed may be need for automatic discovering by network > managemnt software, SNMP reporting and etc.) > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 16:47:43 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 679E52CB; Tue, 9 Dec 2014 16:47:43 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20B5FE10; Tue, 9 Dec 2014 16:47:43 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XyNwr-000Ped-6t; Tue, 09 Dec 2014 20:47:41 +0400 Date: Tue, 9 Dec 2014 20:47:41 +0400 From: Slawa Olhovchenkov To: Eric Joyner , Adrian Chadd , Jack F Vogel , freebsd-arch@freebsd.org Subject: Re: Adding new media types to if_media.h Message-ID: <20141209164741.GP76224@zxy.spb.ru> References: <20141209130412.GA81921@zxy.spb.ru> <20141209153539.GA3925@ox> <20141209163136.GA94186@zxy.spb.ru> <20141209164334.GB3925@ox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141209164334.GB3925@ox> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 16:47:43 -0000 On Tue, Dec 09, 2014 at 08:43:34AM -0800, Navdeep Parhar wrote: > On Tue, Dec 09, 2014 at 08:31:36PM +0400, Slawa Olhovchenkov wrote: > > On Tue, Dec 09, 2014 at 07:35:39AM -0800, Navdeep Parhar wrote: > > > > > On Tue, Dec 09, 2014 at 05:04:13PM +0400, Slawa Olhovchenkov wrote: > > > > On Tue, Dec 09, 2014 at 01:05:27AM -0800, Eric Joyner wrote: > > > > > > > > > This is a continuation of a discussion from off the list: > > > > > > > > > > ixgbe needs to support devices with media types that aren't in if_media.h; > > > > > for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we're > > > > > running into the issue that there is no room for all of these types under > > > > > the IFM_ETHER category; there's only room for two more (and per John > > > > > Baldwin, only one more if one of those two unused types is to be used for a > > > > > reserved type). Long term, there are going to be tons of media types for > > > > > future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > > > > > supports media types that aren't in if_media.h, either. > > > > > > > > > > So, something needs to change. Does anyone have any thoughts on what should > > > > > happen? I've thought of a few things, but I don't have an adequate grasp of > > > > > what the pros/cons of each are: > > > > > > > > > > 1. Add a new media category (like IFM_ETHER) and change kernel code to > > > > > treat it like the existing IFM_ETHER. This creates ~28 new media types we > > > > > can use, but it may just be delaying the inevitable for a short time. > > > > > > > > > > 2. Extend media value from 32-bits to 64-bits. I don't have a good idea of > > > > > what the consequences are of this on architectures that aren't amd64. > > > > > > > > > > 3. (Initially suggested by Adrian) would be to create a new media type > > > > > struct (instead of using an int value) or adding an extra value to the > > > > > existing ifmedia/ifmedia_entry struct for this. This sounds like the best > > > > > solution to me, but I don't know how much effort it would take to implement > > > > > -- does ifconfig need a lot of changing to handle this? > > > > > > > > > > Thoughts? Any previous discussions worth looking at? > > > > > > > > I think need support for media type and subtype, i.e.: > > > > > > > > cxl0: flags=8843 metric 0 mtu 1500 > > > > options=ec07bb > > > > ether 00:07:43:2c:af:10 > > > > inet 37.220.36.28 netmask 0xffffff00 broadcast 37.220.36.255 > > > > nd6 options=9 > > > > media: Ethernet Unknown > > > > status: active > > > > > > > > This is 40G SFP+ DAC. > > > > > > This doesn't look related to the discussion Eric started, but I'd like > > > to point out that is not a reliable link -- "Unknown" media for > > > cxgbe/cxl means the driver has no idea what kind of cable this is and is > > > probably using incorrect settings that happen to work by accident (if > > > this is a working setup). Please provide the output of "cxgbetool > > > t5nex0 modinfo 0 raw" if you'd like to get to the bottom of this. > > > Off-list or new thread is better since it has nothing to do with the > > > stuff in if_media.h > > > > We already discussed about this setup. > > I have next answer from install enginer: "and i'm quite sure it is a + > > cable, Solid Optics is a highly respected cable/transceiver supplier. > > they would not invoice us a + cable if it is not" > > > > Yes, I see in i2c 'Identifier Values' as '0Ch -- QSFP'. QDR (40Gbit). > > So this cable was sold to you as a QSFP+, identifies itself as QSFP (no > plus), and seems to work even though it's not supposed to. Yes. > > > > This is a working setup. And this setup work at 40Gbit w/o errors. > > Ok, let's leave it at that then. Do keep an eye on things like checksum > errors, link flaps, or any other signs of shaky signals on the wire. # netstat -nbI cxl0 Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll cxl0 1500 00:07:43:2c:ad:50 210666777023 0 25518849 15296739966404 410181550989 0 600781280506189 0 cxl0 - 37.220.36.0/2 37.220.36.38 196734318463 - - 10287636760037 404180411324 - 580938380615819 - How I can see checksum errors, link flaps, or any other signs? From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 18:40:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 577A1E88 for ; Tue, 9 Dec 2014 18:40:15 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC2CE12D for ; Tue, 9 Dec 2014 18:40:14 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id em10so2712913wid.11 for ; Tue, 09 Dec 2014 10:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ReMlWx4ruz+yPje5med/8s2KdqLF3GgeQl9JmelrwFQ=; b=kSFQ3ftavVpPiej3Ut0RzM3NXeHOQpGq0g1z+YPVUSpW0Ay5CUmhdVoZHKT1tCwRvc /T7yKwpe9Zm5TLwJni2ksaCgPdfLsHPKc2070NyhveTErb2JQTi8ETZlU16IVfeWS06r HZEQmHFwrxQCRxueEhy00ybdKct2nynze0sbEMW/uV0OdcYtWm72uAIWHN9ppgCWif7k 7b/axJBM8PpgN2rtjZTxKyTQs/IOIciS+iMUg5fZ5qw+N9zkhrn+P7EsfklynyvSOXql Wd9SMBb291u5Kjb90usD4neg0vvXMTUYm7aSCGFUUt+D8ttmMdaBA629slEvKAw6azZD 4o0Q== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr7625854wjz.20.1418150413276; Tue, 09 Dec 2014 10:40:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Tue, 9 Dec 2014 10:40:13 -0800 (PST) In-Reply-To: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> References: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> Date: Tue, 9 Dec 2014 10:40:13 -0800 X-Google-Sender-Auth: AfzSh4_adNTVZ2mqCFWGVxo89pQ Message-ID: Subject: Re: Adding new media types to if_media.h From: Adrian Chadd To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jack F Vogel , Eric Joyner , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:40:15 -0000 On 9 December 2014 at 07:27, Rui Paulo wrote: > On Dec 9, 2014, at 01:05, Eric Joyner wrote: >> >> This is a continuation of a discussion from off the list: >> >> ixgbe needs to support devices with media types that aren't in if_media.= h; >> for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, we= 're >> running into the issue that there is no room for all of these types unde= r >> the IFM_ETHER category; there's only room for two more (and per John >> Baldwin, only one more if one of those two unused types is to be used fo= r a >> reserved type). Long term, there are going to be tons of media types for >> future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already >> supports media types that aren't in if_media.h, either. >> >> So, something needs to change. Does anyone have any thoughts on what sho= uld >> happen? I've thought of a few things, but I don't have an adequate grasp= of >> what the pros/cons of each are: >> >> 1. Add a new media category (like IFM_ETHER) and change kernel code to >> treat it like the existing IFM_ETHER. This creates ~28 new media types w= e >> can use, but it may just be delaying the inevitable for a short time. >> >> 2. Extend media value from 32-bits to 64-bits. I don't have a good idea = of >> what the consequences are of this on architectures that aren't amd64. >> >> 3. (Initially suggested by Adrian) would be to create a new media type >> struct (instead of using an int value) or adding an extra value to the >> existing ifmedia/ifmedia_entry struct for this. This sounds like the bes= t >> solution to me, but I don't know how much effort it would take to implem= ent >> -- does ifconfig need a lot of changing to handle this? > > ifconfig is a macro-intensive application, so maybe it's not that much wo= rk. > >> Thoughts? Any previous discussions worth looking at? > > Hmm, it looks like you're limited in the number of bits because of how th= e word was laid out. We can't simple remove token ring and get more bits fo= r ethernet... We could create another IFM_40GETHERNET type to replace toke= n ring but that would be ugly (the IFM_TYPE() macro could handle this idios= yncrasy). > > I think if_media should probably be a structure with unions to store the = subtypes. net80211 has the same problem with MCS rates and we ended up sto= ring them outside if_media because of this. I think solving this like how it's done in net80211 (ie, with an external structure that represents the media type details for a given media) is the right thing to do. Otherwise it'll be a path to madness in the future. The net80211 side of things is mostly extensible and I'm going to (eventually) end up using it for the 11ac rates that have shown up. I couldn't do that whilst trying to cram it into the existing ifmedia variable. -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 22:48:33 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91F27461; Thu, 11 Dec 2014 22:48:33 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56355F5B; Thu, 11 Dec 2014 22:48:33 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id kx10so5933796pab.16 for ; Thu, 11 Dec 2014 14:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iwTxErDJc/vZqQ27qkGbUvW3nCO8N+bLde+u9U1L/G4=; b=AN6xBLBRazmgbBma8poJEEJJofa2xM3BG6nm+fiI5vRq+38z/MWyF/ov7qPzzqGeGq TNxTPTTN2ksgU84dI3qpEZraFwgQNZufghmRHw6JUT+L+bfMuXisGvAe3+qMy8s0qRkQ JV23vty+zpGJ2+y8YJzQABrhH6zHO279/FTV4exfVsY9wfXSs5r9qTq0i2LZIG9hycz9 uYO/tSdijHJqZokFb7a3o3lvBxRfjXpvbkY7s06FVDNMocRW5H9lk4HgdEf8O8nvSY5z yFuyPEhcx7+YGxaZND2NVQkeoURCXvzyRr4HzqYmJ1uboiugDne1S1knFfKWtreArZBg Jwsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erj.cc; s=ericroxx; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iwTxErDJc/vZqQ27qkGbUvW3nCO8N+bLde+u9U1L/G4=; b=ZChhTL8okMEYnrMgJ0chEpF0GZT9FHMqAotqXablUPCRLq25sCWhIK3Za+Y2AY5Pna yOBaW/Fqvavec4VlthTVJRkD7TnYVk6l06E8imX0SQSA0PkN5/rP3P/BG5m74d9/3Knx 2oQ56yOWGmO7MI8Fbbug1t7ihqxzxrgm3v2/s= X-Received: by 10.69.26.98 with SMTP id ix2mr20792272pbd.161.1418338112693; Thu, 11 Dec 2014 14:48:32 -0800 (PST) MIME-Version: 1.0 Sender: ricera10@gmail.com Received: by 10.70.89.209 with HTTP; Thu, 11 Dec 2014 14:47:52 -0800 (PST) In-Reply-To: References: <1AA55540-AADD-45CB-BC93-E2F81258B1F1@me.com> From: Eric Joyner Date: Thu, 11 Dec 2014 14:47:52 -0800 X-Google-Sender-Auth: ceOn6QsJiZtgQ8SlgXSMF8YcndA Message-ID: Subject: Re: Adding new media types to if_media.h To: Adrian Chadd , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arch@freebsd.org" , Jack F Vogel , Eric Joyner , Rui Paulo X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 22:48:33 -0000 Any other thoughts, or should I start looking at seeing what I can take copy from net80211? Also adding -net, since this is pretty relevant. On Tue, Dec 9, 2014 at 10:40 AM, Adrian Chadd wrote: > > On 9 December 2014 at 07:27, Rui Paulo wrote: > > On Dec 9, 2014, at 01:05, Eric Joyner wrote: > >> > >> This is a continuation of a discussion from off the list: > >> > >> ixgbe needs to support devices with media types that aren't in > if_media.h; > >> for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, > we're > >> running into the issue that there is no room for all of these types > under > >> the IFM_ETHER category; there's only room for two more (and per John > >> Baldwin, only one more if one of those two unused types is to be used > for a > >> reserved type). Long term, there are going to be tons of media types for > >> future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > >> supports media types that aren't in if_media.h, either. > >> > >> So, something needs to change. Does anyone have any thoughts on what > should > >> happen? I've thought of a few things, but I don't have an adequate > grasp of > >> what the pros/cons of each are: > >> > >> 1. Add a new media category (like IFM_ETHER) and change kernel code to > >> treat it like the existing IFM_ETHER. This creates ~28 new media types > we > >> can use, but it may just be delaying the inevitable for a short time. > >> > >> 2. Extend media value from 32-bits to 64-bits. I don't have a good idea > of > >> what the consequences are of this on architectures that aren't amd64. > >> > >> 3. (Initially suggested by Adrian) would be to create a new media type > >> struct (instead of using an int value) or adding an extra value to the > >> existing ifmedia/ifmedia_entry struct for this. This sounds like the > best > >> solution to me, but I don't know how much effort it would take to > implement > >> -- does ifconfig need a lot of changing to handle this? > > > > ifconfig is a macro-intensive application, so maybe it's not that much > work. > > > >> Thoughts? Any previous discussions worth looking at? > > > > Hmm, it looks like you're limited in the number of bits because of how > the word was laid out. We can't simple remove token ring and get more bits > for ethernet... We could create another IFM_40GETHERNET type to replace > token ring but that would be ugly (the IFM_TYPE() macro could handle this > idiosyncrasy). > > > > I think if_media should probably be a structure with unions to store the > subtypes. net80211 has the same problem with MCS rates and we ended up > storing them outside if_media because of this. > > I think solving this like how it's done in net80211 (ie, with an > external structure that represents the media type details for a given > media) is the right thing to do. > > Otherwise it'll be a path to madness in the future. > > The net80211 side of things is mostly extensible and I'm going to > (eventually) end up using it for the 11ac rates that have shown up. I > couldn't do that whilst trying to cram it into the existing ifmedia > variable. > > > -adrian > From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 14:48:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3733278F; Fri, 12 Dec 2014 14:48:18 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id A24E01EC; Fri, 12 Dec 2014 14:48:16 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id sBCEdVRU071168; Fri, 12 Dec 2014 08:39:31 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201412121439.sBCEdVRU071168@mail.karels.net> To: Eric Joyner From: Mike Karels Reply-to: mike@karels.net Subject: Re: Adding new media types to if_media.h In-reply-to: Your message of Thu, 11 Dec 2014 14:47:52 -0800. Date: Fri, 12 Dec 2014 08:39:31 -0600 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Rui Paulo , Jack F Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 14:48:18 -0000 > Any other thoughts, or should I start looking at seeing what I can take > copy from net80211? > Also adding -net, since this is pretty relevant. I had the same reaction as Adrian initially, as an int with numerous fields seems really messy. However, I don't think we have the challenges of 802.11, and the only real problem is that the subtype field has run out of bits. And both ifconfig and the drivers are cast in the form of a scalar "media word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | IFM_FDX (assuming that all the bits are in a scalar). Instead, I would propose that we simply change the media word from 32 bits to 64, and move the subtype from its current location to a new field (e.g. 16 bits) in the new space. I believe this can be KPI compatible, and it is relatively easy to provide a backward-compatible ABI. There should be a reserved subtype for "other" that can be encoded in the existing field for use when the subtype can't fit in the old field. This seems much easier, can be KPI compatible, and will make it much easier to backport drivers. A backport could simply define the new subtypes as "other", and the KPI would still be compatible. Thoughts? Mike > On Tue, Dec 9, 2014 at 10:40 AM, Adrian Chadd wrote: > > > > On 9 December 2014 at 07:27, Rui Paulo wrote: > > > On Dec 9, 2014, at 01:05, Eric Joyner wrote: > > >> > > >> This is a continuation of a discussion from off the list: > > >> > > >> ixgbe needs to support devices with media types that aren't in > > if_media.h; > > >> for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, > > we're > > >> running into the issue that there is no room for all of these types > > under > > >> the IFM_ETHER category; there's only room for two more (and per John > > >> Baldwin, only one more if one of those two unused types is to be used > > for a > > >> reserved type). Long term, there are going to be tons of media types for > > >> future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > > >> supports media types that aren't in if_media.h, either. > > >> > > >> So, something needs to change. Does anyone have any thoughts on what > > should > > >> happen? I've thought of a few things, but I don't have an adequate > > grasp of > > >> what the pros/cons of each are: > > >> > > >> 1. Add a new media category (like IFM_ETHER) and change kernel code to > > >> treat it like the existing IFM_ETHER. This creates ~28 new media types > > we > > >> can use, but it may just be delaying the inevitable for a short time. > > >> > > >> 2. Extend media value from 32-bits to 64-bits. I don't have a good idea > > of > > >> what the consequences are of this on architectures that aren't amd64. > > >> > > >> 3. (Initially suggested by Adrian) would be to create a new media type > > >> struct (instead of using an int value) or adding an extra value to the > > >> existing ifmedia/ifmedia_entry struct for this. This sounds like the > > best > > >> solution to me, but I don't know how much effort it would take to > > implement > > >> -- does ifconfig need a lot of changing to handle this? > > > > > > ifconfig is a macro-intensive application, so maybe it's not that much > > work. > > > > > >> Thoughts? Any previous discussions worth looking at? > > > > > > Hmm, it looks like you're limited in the number of bits because of how > > the word was laid out. We can't simple remove token ring and get more bits > > for ethernet... We could create another IFM_40GETHERNET type to replace > > token ring but that would be ugly (the IFM_TYPE() macro could handle this > > idiosyncrasy). > > > > > > I think if_media should probably be a structure with unions to store the > > subtypes. net80211 has the same problem with MCS rates and we ended up > > storing them outside if_media because of this. > > > > I think solving this like how it's done in net80211 (ie, with an > > external structure that represents the media type details for a given > > media) is the right thing to do. > > > > Otherwise it'll be a path to madness in the future. > > > > The net80211 side of things is mostly extensible and I'm going to > > (eventually) end up using it for the 11ac rates that have shown up. I > > couldn't do that whilst trying to cram it into the existing ifmedia > > variable. > > > > > > -adrian > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 20:26:27 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E4491FB; Fri, 12 Dec 2014 20:26:27 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 817F9D8E; Fri, 12 Dec 2014 20:26:26 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so3663970wiv.0; Fri, 12 Dec 2014 12:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PYrsTDlNXg7RMv0fkiGXDkgylp3clcjcRieHFrTSJzU=; b=dfpKeBJWf6KIEfTbS5+Kd7f9CZgVKDrdY0cHetkU0hl9Gnl7SMG/XPEiZ4unsApldA 7ZGT3r433cQqU+wGOjKW3v3oJ0x2VeGQbUcT/6G9ktPuSbqoJTnyX8UPr+fYFJnsEZhw 0lW7IAE0264HF6A1I7ZbaOOUoOE/nQsinMbzOFvjr7eQhDVSb2nIjELzIdHoGp9kM6vG j8USLTLilA3fbzdEyXQxOYa6G59jIM68kWFzeoVmfxk0Tqww6DhXZgExSq/rnUO/T2pZ HFVbMcmfo9ia0k0jVcVZy59rcdmubTUSDV2Zd8JaNTscNtNE1P2iVCaFKYc1uAfLq2Yw 9row== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr10894052wic.21.1418415984946; Fri, 12 Dec 2014 12:26:24 -0800 (PST) Received: by 10.194.81.233 with HTTP; Fri, 12 Dec 2014 12:26:24 -0800 (PST) In-Reply-To: <201412121439.sBCEdVRU071168@mail.karels.net> References: <201412121439.sBCEdVRU071168@mail.karels.net> Date: Fri, 12 Dec 2014 12:26:24 -0800 Message-ID: Subject: Re: Adding new media types to if_media.h From: Jack Vogel To: Mike Karels Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Rui Paulo , Eric Joyner , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:26:27 -0000 I think I'd go along with Mike, keeping it simpler seems like a good idea. Jack On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: > > > Any other thoughts, or should I start looking at seeing what I can take > > copy from net80211? > > > Also adding -net, since this is pretty relevant. > > I had the same reaction as Adrian initially, as an int with numerous fields > seems really messy. However, I don't think we have the challenges of > 802.11, > and the only real problem is that the subtype field has run out of bits. > And both ifconfig and the drivers are cast in the form of a scalar "media > word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | IFM_FDX > (assuming that all the bits are in a scalar). > > Instead, I would propose that we simply change the media word from 32 bits > to 64, and move the subtype from its current location to a new field (e.g. > 16 bits) in the new space. I believe this can be KPI compatible, and it > is relatively easy to provide a backward-compatible ABI. There should be > a reserved subtype for "other" that can be encoded in the existing field > for use when the subtype can't fit in the old field. This seems much > easier, > can be KPI compatible, and will make it much easier to backport drivers. > A backport could simply define the new subtypes as "other", and the KPI > would still be compatible. > > Thoughts? > > Mike > > > On Tue, Dec 9, 2014 at 10:40 AM, Adrian Chadd > wrote: > > > > > > On 9 December 2014 at 07:27, Rui Paulo wrote: > > > > On Dec 9, 2014, at 01:05, Eric Joyner wrote: > > > >> > > > >> This is a continuation of a discussion from off the list: > > > >> > > > >> ixgbe needs to support devices with media types that aren't in > > > if_media.h; > > > >> for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. > Immediately, > > > we're > > > >> running into the issue that there is no room for all of these types > > > under > > > >> the IFM_ETHER category; there's only room for two more (and per John > > > >> Baldwin, only one more if one of those two unused types is to be > used > > > for a > > > >> reserved type). Long term, there are going to be tons of media > types for > > > >> future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > > > >> supports media types that aren't in if_media.h, either. > > > >> > > > >> So, something needs to change. Does anyone have any thoughts on what > > > should > > > >> happen? I've thought of a few things, but I don't have an adequate > > > grasp of > > > >> what the pros/cons of each are: > > > >> > > > >> 1. Add a new media category (like IFM_ETHER) and change kernel code > to > > > >> treat it like the existing IFM_ETHER. This creates ~28 new media > types > > > we > > > >> can use, but it may just be delaying the inevitable for a short > time. > > > >> > > > >> 2. Extend media value from 32-bits to 64-bits. I don't have a good > idea > > > of > > > >> what the consequences are of this on architectures that aren't > amd64. > > > >> > > > >> 3. (Initially suggested by Adrian) would be to create a new media > type > > > >> struct (instead of using an int value) or adding an extra value to > the > > > >> existing ifmedia/ifmedia_entry struct for this. This sounds like the > > > best > > > >> solution to me, but I don't know how much effort it would take to > > > implement > > > >> -- does ifconfig need a lot of changing to handle this? > > > > > > > > ifconfig is a macro-intensive application, so maybe it's not that > much > > > work. > > > > > > > >> Thoughts? Any previous discussions worth looking at? > > > > > > > > Hmm, it looks like you're limited in the number of bits because of > how > > > the word was laid out. We can't simple remove token ring and get more > bits > > > for ethernet... We could create another IFM_40GETHERNET type to > replace > > > token ring but that would be ugly (the IFM_TYPE() macro could handle > this > > > idiosyncrasy). > > > > > > > > I think if_media should probably be a structure with unions to store > the > > > subtypes. net80211 has the same problem with MCS rates and we ended up > > > storing them outside if_media because of this. > > > > > > I think solving this like how it's done in net80211 (ie, with an > > > external structure that represents the media type details for a given > > > media) is the right thing to do. > > > > > > Otherwise it'll be a path to madness in the future. > > > > > > The net80211 side of things is mostly extensible and I'm going to > > > (eventually) end up using it for the 11ac rates that have shown up. I > > > couldn't do that whilst trying to cram it into the existing ifmedia > > > variable. > > > > > > > > > -adrian > > > > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 20:31:14 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0F9471; Fri, 12 Dec 2014 20:31:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64970E5A; Fri, 12 Dec 2014 20:31:14 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 48B88B913; Fri, 12 Dec 2014 15:31:13 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Adding new media types to if_media.h Date: Fri, 12 Dec 2014 15:31:06 -0500 Message-ID: <2116096.l1vR0RuKRU@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <201412121439.sBCEdVRU071168@mail.karels.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Dec 2014 15:31:13 -0500 (EST) Cc: Adrian Chadd , Mike Karels , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , Jack Vogel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:31:14 -0000 On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: > I think I'd go along with Mike, keeping it simpler seems like a good idea. > > Jack If the userland ABI impact isn't too broad I think this is fine. Mike, do you know off hand how many user-facing things would be affected? > On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: > > > Any other thoughts, or should I start looking at seeing what I can take > > > copy from net80211? > > > > > > Also adding -net, since this is pretty relevant. > > > > I had the same reaction as Adrian initially, as an int with numerous > > fields > > seems really messy. However, I don't think we have the challenges of > > 802.11, > > and the only real problem is that the subtype field has run out of bits. > > And both ifconfig and the drivers are cast in the form of a scalar "media > > word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | > > IFM_FDX > > (assuming that all the bits are in a scalar). > > > > Instead, I would propose that we simply change the media word from 32 bits > > to 64, and move the subtype from its current location to a new field (e.g. > > 16 bits) in the new space. I believe this can be KPI compatible, and it > > is relatively easy to provide a backward-compatible ABI. There should be > > a reserved subtype for "other" that can be encoded in the existing field > > for use when the subtype can't fit in the old field. This seems much > > easier, > > can be KPI compatible, and will make it much easier to backport drivers. > > A backport could simply define the new subtypes as "other", and the KPI > > would still be compatible. > > > > Thoughts? > > > > Mike -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Dec 13 01:07:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 202CA49F for ; Sat, 13 Dec 2014 01:07:02 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id C7A20CC0 for ; Sat, 13 Dec 2014 01:07:01 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id sBD16tgl072730; Fri, 12 Dec 2014 19:06:56 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201412130106.sBD16tgl072730@mail.karels.net> To: John Baldwin From: Mike Karels Reply-to: mike@karels.net Subject: Re: Adding new media types to if_media.h In-reply-to: Your message of Fri, 12 Dec 2014 15:31:06 -0500. <2116096.l1vR0RuKRU@ralph.baldwin.cx> Date: Fri, 12 Dec 2014 19:06:55 -0600 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , Jack Vogel , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 01:07:02 -0000 > On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: > > I think I'd go along with Mike, keeping it simpler seems like a good idea. > > > > Jack > If the userland ABI impact isn't too broad I think this is fine. Mike, do you > know off hand how many user-facing things would be affected? I didn't know off hand, but I have a glimpse index at $WORK (it's for McAfee Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 references to if_media.h at user level, including "ports" that we use, and excluding our own software. The list includes libpcap, snmpd, dhclient, quagga, xorp, atm, devd, and rtsold. fwiw, I found about 260 inclusions of if_media.h in the kernel. This suggests that we should preserve a backward-compatible user API, even if it has limits. Unfortunately, the media word I mentioned is a plain int, not a typedef. I would propose a similar API that is not limited, but easy to convert (e.g. using a new typedef). I'd be willing to sketch out something like that. > > On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: > > > > Any other thoughts, or should I start looking at seeing what I can take > > > > copy from net80211? > > > > > > > > Also adding -net, since this is pretty relevant. > > > > > > I had the same reaction as Adrian initially, as an int with numerous > > > fields > > > seems really messy. However, I don't think we have the challenges of > > > 802.11, > > > and the only real problem is that the subtype field has run out of bits. > > > And both ifconfig and the drivers are cast in the form of a scalar "media > > > word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | > > > IFM_FDX > > > (assuming that all the bits are in a scalar). > > > > > > Instead, I would propose that we simply change the media word from 32 bits > > > to 64, and move the subtype from its current location to a new field (e.g. > > > 16 bits) in the new space. I believe this can be KPI compatible, and it > > > is relatively easy to provide a backward-compatible ABI. There should be > > > a reserved subtype for "other" that can be encoded in the existing field > > > for use when the subtype can't fit in the old field. This seems much > > > easier, > > > can be KPI compatible, and will make it much easier to backport drivers. > > > A backport could simply define the new subtypes as "other", and the KPI > > > would still be compatible. > > > > > > Thoughts? > > > > > > Mike > -- > John Baldwin Mike