From sacadmin Wed Aug 29 15:35:23 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7TMZN6d028225 for ; Wed, 29 Aug 2007 15:35:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7TMWhd0015834; Wed, 29 Aug 2007 15:32:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNK00J0D3YKAE00@brm-avmta-1.central.sun.com>; Wed, 29 Aug 2007 16:32:44 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNK00J5E3YJ6F00@brm-avmta-1.central.sun.com>; Wed, 29 Aug 2007 16:32:44 -0600 (MDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7TMWhOx028501; Wed, 29 Aug 2007 22:32:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JNK005013OCTE00@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) ; Wed, 29 Aug 2007 16:32:43 -0600 (MDT) Received: from [129.145.154.61] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JNK00FOZ3YDVZW8@mail-amer.sun.com>; Wed, 29 Aug 2007 16:32:37 -0600 (MDT) Date: Wed, 29 Aug 2007 15:32:37 -0700 From: Aarti Pai Subject: New materials for PSARC/2007/429 Brussels Enhanced Network Driver Configuration Via dladm Sender: Aarti.Pai@sun.com To: psarc@sun.com Cc: Sowmini Varadhan , PSARC-coord@sun.com Reply-to: Aarti.Pai@sun.com Message-id: <46D5F405.8000208@Sun.COM> MIME-version: 1.0 Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 813 sac% pwd
/shared/sac/Archives/CaseLog/arc/PSARC/2007/429/inception2.materials
sac% ls -l
total 6694
-rw-rw-r--   1 apai     sacmail 3036439 Aug 29 15:17 Coso-Infrastructure-UseCases-v0.41.odt
-rw-rw-r--   1 apai     sacmail    14236 Aug 29 15:17 brussels-umbrella.txt
-rw-rw-r--   1 apai     sacmail   176640 Aug 29 15:17 brussels.pdf

--

Regards,
Aarti

From sacadmin Wed Aug 29 15:45:41 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7TMjevU028435 for ; Wed, 29 Aug 2007 15:45:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l7TMgoE8002150; Thu, 30 Aug 2007 06:43:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNK00K054FML300@nwk-avmta-2.sfbay.sun.com>; Wed, 29 Aug 2007 15:42:58 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNK006EX4FL13F0@nwk-avmta-2.sfbay.sun.com>; Wed, 29 Aug 2007 15:42:57 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7TMguek028650; Wed, 29 Aug 2007 15:42:56 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l7TMhobv004825; Wed, 29 Aug 2007 15:43:50 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l7TMhou9004824; Wed, 29 Aug 2007 15:43:50 -0700 (PDT) Date: Wed, 29 Aug 2007 15:43:50 -0700 (PDT) From: Gary Winiger Subject: Re: New materials for PSARC/2007/429 Brussels Enhanced Network Driver Configuration Via dladm To: psarc@sun.com, Aarti.Pai@sun.com Cc: Sowmini.Varadhan@sun.com, PSARC-coord@sun.com Message-id: <200708292243.l7TMhou9004824@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 317 > /shared/sac/Archives/CaseLog/arc/PSARC/2007/429/inception2.materials cd /shared/sac/Archives/CaseLog/arc/PSARC/2007/429/inception2.materials /shared/sac/Archives/CaseLog/arc/PSARC/2007/429/inception2.materials: Permission denied drwxrwSr-- 2 apai sac 5 Aug 29 15:17 inception2.materials/ Gary.. From gww@eng.sun.com Thu Sep 13 16:12:40 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8DNCdpo012958 for ; Thu, 13 Sep 2007 16:12:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8DN9i9d010769 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 14 Sep 2007 00:09:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JOB00E05XO7LD00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 13 Sep 2007 16:09:43 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOB00D2YXO7FW20@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 13 Sep 2007 16:09:43 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l8DN9h7h006924 for ; Thu, 13 Sep 2007 16:09:43 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l8DNAxZb028662; Thu, 13 Sep 2007 16:10:59 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l8DNAxId028661; Thu, 13 Sep 2007 16:10:59 -0700 (PDT) Date: Thu, 13 Sep 2007 16:10:59 -0700 (PDT) From: Gary Winiger Subject: 2007/429 Brussels Enhanced Network Driver Configuration Via dladm To: psarc-ext@sun.com Message-id: <200709132310.l8DNAxId028661@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 675 First my apologies if this is in the materials and I've overlooked it. Unfortunately I didn't get to thoroughly review the materials. In looking back at things, it seems there may be Solaris Audit and RBAC requirements for the additions suggested. Presently there's wifi.config and wifi.web authorizations, and create network security object and delete network security object audit events. Is the intent of the Brussels changes to dladm to rely on svc.configd auditing and RBAC? If so at least the SMF properties and authorizations should be part of the case. If not, how does this project deal with the Audit and RBAC requirements for administrative interfaces? Gary.. From sowmini.varadhan@sun.com Thu Sep 13 17:08:06 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8E086ee014261 for ; Thu, 13 Sep 2007 17:08:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8E05BNv029226; Fri, 14 Sep 2007 01:05:12 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JOC0090R08NIZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Sep 2007 17:05:11 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOC006L008IKC10@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Sep 2007 17:05:07 -0700 (PDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l8E056BT058550; Thu, 13 Sep 2007 20:05:06 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l8DNthJn018939; Thu, 13 Sep 2007 19:55:43 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8DNthw5018938; Thu, 13 Sep 2007 19:55:43 -0400 (EDT) Date: Thu, 13 Sep 2007 19:55:43 -0400 From: sowmini.varadhan@sun.com Subject: Re: 2007/429 Brussels Enhanced Network Driver Configuration Via dladm In-reply-to: <200709132310.l8DNAxId028661@marduk.eng.sun.com> To: Gary Winiger Cc: psarc-ext@sun.com, brussels-interest@sun.com Message-id: <20070913235543.GA18928@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200709132310.l8DNAxId028661@marduk.eng.sun.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.16 (2007-06-11) Status: RO Content-Length: 2217 On (09/13/07 16:10), Gary Winiger wrote: > > First my apologies if this is in the materials and I've overlooked it. > Unfortunately I didn't get to thoroughly review the materials. > In looking back at things, it seems there may be Solaris Audit and > RBAC requirements for the additions suggested. Presently there's > wifi.config and wifi.web authorizations, and create network security object > and delete network security object audit events. > Is the intent of the Brussels changes to dladm to rely on svc.configd > auditing and RBAC? If so at least the SMF properties and authorizations > should be part of the case. If not, how does this project deal with the > Audit and RBAC requirements for administrative interfaces? > > Gary.. > Hi, we are planning to leverage on the same RBAC infrastructure currently used by dladm for managing wifi and aggr interfaces, which appears to be quasimodo(391)% pwd /etc/security quasimodo(393)% grep dladm *attr exec_attr:Network Link Security:solaris:cmd:::/sbin/dladm:euid=dladm;egid=sys; privs=sys_net_config,net_rawaccess,proc_audit exec_attr:Network Management:solaris:cmd:::/sbin/dladm:euid=dladm;egid=sys; privs=sys_net_config,net_rawaccess,proc_audit The "Network Management" profile looks like it would cover PSARC 2007/429 (could you please confirm that this is adequate) quasimodo(390)% grep 'Network Managemen' prof_attr Network Management:::Manage the host and network configuration:auths=solaris.smf.manage.name-service-cache,solaris.smf.manage.bind,solaris.smf.value.routing,solaris.smf.manage.routing,solaris.smf.value.nwam,solaris.smf.manage.nwam,solaris.smf.manage.wpa,solaris.admin.dcmgr.clients,solaris.admin.dcmgr.read,solaris.snmp.*,solaris.network.hosts.*;profiles=Network Wifi Management;help=RtNetMngmnt.html System Administrator:::Can perform most non-security administrative tasks:profiles=Audit Review,Printer Management,Cron Management,Device Management,File System Management,Mail Management,Maintenance and Repair,Media Backup,Media Restore,Name Service Management,Network Management,Object Access Management,Process Management,Software Installation,User Management,Project Management,All;help=RtSysAdmin.html Thanks, Sowmini From sacadmin Tue Sep 18 12:50:27 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8IJoQVS008860 for ; Tue, 18 Sep 2007 12:50:27 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l8IJlLEu012559; Wed, 19 Sep 2007 03:47:21 +0800 (SGT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8IJlKrH024371; Tue, 18 Sep 2007 19:47:20 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JOK00601X67BG00@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) ; Tue, 18 Sep 2007 13:47:20 -0600 (MDT) Received: from [129.145.154.61] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOK00713XMUZ7C0@mail-amer.sun.com>; Tue, 18 Sep 2007 13:47:19 -0600 (MDT) Date: Tue, 18 Sep 2007 12:47:18 -0700 From: Aarti Pai Subject: PSARC Meeting Minutes 09/12/2007 Inception: 2007/429 Sender: Aarti.Pai@Sun.COM To: psarc@Sun.COM Cc: PSARC-coord@Sun.COM, Sowmini Varadhan , brussels-interest@Sun.COM Reply-to: Aarti.Pai@Sun.COM Message-id: <46F02B46.4070208@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ooPQBBirVJ0sWiByQTMVcg)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 2495 This is a multi-part message in MIME format. --Boundary_(ID_ooPQBBirVJ0sWiByQTMVcg) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Minutes/Audio for PSARC meeting of 09/12/2007: - Arc Business: http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.arcbiz - Open Arc Business Audio: http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.arcbiz.open.mp3 - Closed Arc Business Audio: http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.arcbiz.closed.mp3 - Inception 2007/429: http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.2007.429.inception Audio: http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.2007.429.inception.mp3 Please contact me directly if you require any corrections/modifications to these minutes. --Boundary_(ID_ooPQBBirVJ0sWiByQTMVcg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Minutes/Audio for PSARC meeting of 09/12/2007:

- Arc Business: http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.arcbiz
- Open Arc Business Audio: http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.arcbiz.open.mp3
- Closed Arc Business Audio:
http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.arcbiz.closed.mp3

- Inception 2007/429:
http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.2007.429.inception
Audio:
http://sac.sfbay/Archives/Minutes/PSARC/2007/20070912.2007.429.inception.mp3

Please contact me directly if you require any corrections/modifications to these minutes.
--Boundary_(ID_ooPQBBirVJ0sWiByQTMVcg)-- From sacadmin Fri Oct 5 10:04:51 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95H4oft002090 for ; Fri, 5 Oct 2007 10:04:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95H1U2C006778 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 5 Oct 2007 18:01:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00A037AN0P00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@Sun.COM); Fri, 05 Oct 2007 10:01:35 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG002GX7ANJNA0@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@Sun.COM); Fri, 05 Oct 2007 10:01:35 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l95H1Z1Z019907 for ; Fri, 05 Oct 2007 17:01:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPG008013XIEN00@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for psarc@Sun.COM (ORCPT psarc@Sun.COM); Fri, 05 Oct 2007 11:01:35 -0600 (MDT) Received: from [129.145.154.61] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPG002UL7AEJP30@mail-amer.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Fri, 05 Oct 2007 11:01:27 -0600 (MDT) Date: Fri, 05 Oct 2007 10:01:26 -0700 From: Aarti Pai Subject: Commitment Materials for PSARC/2007/429 - Brussels - enhanced network driver config In-reply-to: <20071005164324.GD26782@quasimodo.East.Sun.COM> Sender: Aarti.Pai@sun.com To: psarc@sun.com Cc: Sowmini.Varadhan@sun.com Reply-to: Aarti.Pai@sun.com Message-id: <47066DE6.3030600@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UxLUtkOjmP5Yo2gbiED67g)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <20071005164324.GD26782@quasimodo.East.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 3892 This is a multi-part message in MIME format. --Boundary_(ID_UxLUtkOjmP5Yo2gbiED67g) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT sac% ls -l commitment.materials total 805 -rw-r--r-- 1 apai sacmail 26352 Oct 5 06:36 20q.txt -rw-r--r-- 1 apai sacmail 1031 Oct 5 08:07 README -rw-r--r-- 1 apai sacmail 13731 Oct 4 15:11 brussels-umbrella.txt -rw-r--r-- 1 apai sacmail 197892 Oct 4 13:05 brussels.pdf -rw-r--r-- 1 apai sacmail 90777 Oct 3 10:15 framework.pdf -rw-r--r-- 1 apai sacmail 5853 Oct 4 13:33 issues.txt drwxr-sr-x 2 apai sacmail 14 Oct 5 06:13 manpages -rw-r--r-- 1 apai sacmail 920 Oct 5 08:06 relnotes-update.txt Sowmini.Varadhan@Sun.COM wrote: >Attached please find a tarball of the following >materials intended for the upcoming commitment review >of PSARC/2007/429 scheduled for Oct 17, 2007. > >The list of unpacked files should be: > >commitment.materials: >20q.txt brussels.pdf manpages >README framework.pdf relnotes-update.txt >brussels-umbrella.txt issues.txt > >commitment.materials/manpages: >bge.7d dladm.1m ieee802.3.5 ndd.1m >bge.7d.diff dladm.1m.diff ieee802.3.5.diff ndd.1m.diff >bge.7d.orig dladm.1m.orig ieee802.3.5.orig ndd.1m.orig > > >The README file provides and overview of updates since >inception review. > >Thanks, >Sowmini > > --Boundary_(ID_UxLUtkOjmP5Yo2gbiED67g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
sac% ls -l commitment.materials
total 805
-rw-r--r--   1 apai     sacmail    26352 Oct 5 06:36 20q.txt
-rw-r--r--   1 apai     sacmail     1031 Oct 5 08:07 README
-rw-r--r--   1 apai     sacmail    13731 Oct 4 15:11 brussels-umbrella.txt
-rw-r--r--   1 apai     sacmail   197892 Oct 4 13:05 brussels.pdf
-rw-r--r--   1 apai     sacmail    90777 Oct 3 10:15 framework.pdf
-rw-r--r--   1 apai     sacmail     5853 Oct 4 13:33 issues.txt
drwxr-sr-x   2 apai     sacmail       14 Oct 5 06:13 manpages
-rw-r--r--   1 apai     sacmail      920 Oct 5 08:06 relnotes-update.txt

Sowmini.Varadhan@Sun.COM wrote:

Attached please find a tarball of the following
materials intended for the upcoming commitment review 
of PSARC/2007/429 scheduled for Oct 17, 2007.

The list of unpacked files should be:

commitment.materials:
20q.txt                brussels.pdf           manpages
README                 framework.pdf          relnotes-update.txt
brussels-umbrella.txt  issues.txt

commitment.materials/manpages:
bge.7d            dladm.1m          ieee802.3.5       ndd.1m
bge.7d.diff       dladm.1m.diff     ieee802.3.5.diff  ndd.1m.diff
bge.7d.orig       dladm.1m.orig     ieee802.3.5.orig  ndd.1m.orig


The README file provides and overview of updates since
inception review.

Thanks,
Sowmini

--Boundary_(ID_UxLUtkOjmP5Yo2gbiED67g)-- From garrett@damore.org Mon Oct 15 08:26:34 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FFQYj3003844 for ; Mon, 15 Oct 2007 08:26:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FFNAhc018587; Mon, 15 Oct 2007 08:23:13 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00905LENR200@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 08:23:11 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY005IHLEFOY30@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 08:23:03 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9FFN2xa000903; Mon, 15 Oct 2007 15:23:03 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-1573130; Mon, 15 Oct 2007 15:23:02 +0000 (Z) Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by mms49es.sun.com with ESMTP id BT-MMP-1600945; Mon, 15 Oct 2007 15:23:02 +0000 (Z) Received: from occp5.ocservers.net ([216.73.122.2] [216.73.122.2]) by relay4i.sun.com with ESMTP id BT-MMP-4989179; Mon, 15 Oct 2007 15:23:02 +0000 (Z) Received: from [192.18.43.225] (helo=[10.7.251.172]) by occp5.ocservers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IhRmY-0004Ky-CQ; Mon, 15 Oct 2007 08:23:02 -0700 Date: Mon, 15 Oct 2007 08:20:20 -0700 From: "Garrett D'Amore" Subject: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <20071015102323.GF12613@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <47138534.4000101@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - occp5.ocservers.net X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - damore.org References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 3032 I was chatting with some folks at the OpenSolaris Developer Summit, and I think the Brussels project needs to consider a possible future enhancement that NIC drivers are likely to make. Specifically, in order to save power, many NIC drivers are likely to want to switch down to a lower speed from 10G or 1G down to 100Mbps or 10Mbps. This is because running at 1G consumes on average about 1W per port. Versus less than 1/10th of that at 100Mbps. As far as Brussels is concerned, I'm interested in the link state and speed properties. Right now the adv_xxx properties indicate both the administrator's desired negotiation parameters, and the actual state of the MII ANAR register on the PHY. We need to break that up in the future. Specifically, we are going to need a way for the administrator to say "I want autonegotiation, and I'm willing to negotiate for everything, but I also want the NIC to downscale the speed when the NIC drops below a certain utilization for a while." And we need a way to be able to see that. But *independently*, we need a way to look at the current state of the ANAR register for debug. When the NIC is running at a lower speed, it may have ANAR register bits cleared that would otherwise be set once the demand for bandwidth increases. Anyway, I'd like the project team to consider how this could be retrofitted in the future without breaking any interfaces that are being presented today. It is possible that the interfaces (properties) that are being proposed today might need either a lower commitment level, or maybe we can imagine a better set of properties or even a simple enhancement to the properties to accommodate this kind of future enhancement. (Perhaps an additional set of properties?) One possible approach (and I'm not sure that this is the best way, but I'm just offering it as a strawman and I'd really like to hear the project team's thoughts!) might be: * change adv_xxx spec to indicate that this is a read-only property indicating the NIC's MII register contents * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties which becomes the administrative *control* point. * and new properties, "cap_link_pm", "enable_link_pm", and "link_pm_state", which are boolean values indicate the ability to do this kind of link power management, whether it is turned on, and the current state (link speed is reduced for power management or not). Note that the above suggestion would require adding new enable_xxx properties even to NICs that don't have link power management. (And yes, it isn't strictly "required", but it would be a lot simpler if all NICs were administered the same way from the first time the project integrated.) And to be clear, I don't think we are going to go very long at all before NIC drivers start looking for this kind of feature... projects like Tesla, laptop suspend/resume, and wake-on-lan demonstrate that power savings features are becoming very important. -- Garrett From sowmini.varadhan@sun.com Mon Oct 15 09:08:37 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FG8aJb005024 for ; Mon, 15 Oct 2007 09:08:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9FG5Ccf008753 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 00:05:15 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY0010TNCPQ000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 10:05:13 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY000MSNCNK840@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 10:05:12 -0600 (MDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9FG5B4K008093 for ; Mon, 15 Oct 2007 12:05:11 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9FFm1a5024009; Mon, 15 Oct 2007 11:48:01 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9FFlqcX024007; Mon, 15 Oct 2007 11:47:52 -0400 (EDT) Date: Mon, 15 Oct 2007 11:47:52 -0400 From: sowmini.varadhan@sun.com Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <47138534.4000101@damore.org> To: "Garrett D'Amore" Cc: brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <20071015154752.GG22510@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.16 (2007-06-11) Status: RO Content-Length: 3000 On (10/15/07 08:20), Garrett D'Amore wrote: > > I was chatting with some folks at the OpenSolaris Developer Summit, and I > think the Brussels project needs to consider a possible future enhancement > that NIC drivers are likely to make. > > Specifically, in order to save power, many NIC drivers are likely to want > to switch down to a lower speed from 10G or 1G down to 100Mbps or 10Mbps. > This is because running at 1G consumes on average about 1W per port. > Versus less than 1/10th of that at 100Mbps. > As far as Brussels is concerned, I'm interested in the link state and speed > properties. Right now the adv_xxx properties indicate both the > administrator's desired negotiation parameters, and the actual state of the > MII ANAR register on the PHY. > > We need to break that up in the future. Specifically, we are going to need > a way for the administrator to say "I want autonegotiation, and I'm willing > to negotiate for everything, but I also want the NIC to downscale the speed > when the NIC drops below a certain utilization for a while." And we need a > way to be able to see that. > > But *independently*, we need a way to look at the current state of the ANAR > register for debug. When the NIC is running at a lower speed, it may have > ANAR register bits cleared that would otherwise be set once the demand for > bandwidth increases. Garrett, Interesting point. It seems to me that the best way to provision for advanced power-management concepts would be to add additional enhanced properties. Thus, we could have the existing adv* properties, plus additional enable_link_pm modifiers (with the associated versions to examine the link state, and set the capability), i.e., the suggestion below: > * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties > which becomes the administrative *control* point. > * and new properties, "cap_link_pm", "enable_link_pm", and > "link_pm_state", which are boolean values indicate the ability to do this > kind of link power management, whether it is turned on, and the current > state (link speed is reduced for power management or not). is the ideal solution. The existing adv* tunables have been around for far too long, so lowering their stability with Brussels would discourage adoption, as Jim points out in http://mail.opensolaris.org/pipermail/brussels-dev/2007-October/000462.html > Note that the above suggestion would require adding new enable_xxx > properties even to NICs that don't have link power management. (And yes, > it isn't strictly "required", but it would be a lot simpler if all NICs > were administered the same way from the first time the project integrated.) Agreed. As you point out, the set of "public" properties is a rapidly changing one. The idea, with PSARC 2007/429, is to offer the bare minimum of interfaces with the framework so that cutting-edge projects like suspend/resume can contribute/modify the set efficiently. --Sowmini From gdamore@sun.com Mon Oct 15 09:29:36 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FGTaxW005134 for ; Mon, 15 Oct 2007 09:29:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FGQCbD017335 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 15 Oct 2007 09:26:15 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00K0HOBPBQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 09:26:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00C7FOBP4RA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 09:26:13 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9FGQDJF009771 for ; Mon, 15 Oct 2007 09:26:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPY00K01O56VW00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 09:26:13 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPY008VWOBH16B0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 09:26:06 -0700 (PDT) Date: Mon, 15 Oct 2007 09:23:28 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <20071015154752.GG22510@quasimodo.East.Sun.COM> Sender: Garrett.Damore@sun.com To: Sowmini.Varadhan@sun.com Cc: "Garrett D'Amore" , brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <47139400.7040200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 5112 Sowmini.Varadhan@Sun.COM wrote: > On (10/15/07 08:20), Garrett D'Amore wrote: > >> I was chatting with some folks at the OpenSolaris Developer Summit, and I >> think the Brussels project needs to consider a possible future enhancement >> that NIC drivers are likely to make. >> >> Specifically, in order to save power, many NIC drivers are likely to want >> to switch down to a lower speed from 10G or 1G down to 100Mbps or 10Mbps. >> This is because running at 1G consumes on average about 1W per port. >> Versus less than 1/10th of that at 100Mbps. >> As far as Brussels is concerned, I'm interested in the link state and speed >> properties. Right now the adv_xxx properties indicate both the >> administrator's desired negotiation parameters, and the actual state of the >> MII ANAR register on the PHY. >> >> We need to break that up in the future. Specifically, we are going to need >> a way for the administrator to say "I want autonegotiation, and I'm willing >> to negotiate for everything, but I also want the NIC to downscale the speed >> when the NIC drops below a certain utilization for a while." And we need a >> way to be able to see that. >> >> But *independently*, we need a way to look at the current state of the ANAR >> register for debug. When the NIC is running at a lower speed, it may have >> ANAR register bits cleared that would otherwise be set once the demand for >> bandwidth increases. >> > > Garrett, > > Interesting point. It seems to me that the best way to provision > for advanced power-management concepts would be to add additional > enhanced properties. > > Thus, we could have the existing adv* properties, plus additional > enable_link_pm modifiers (with the associated versions to examine > the link state, and set the capability), i.e., the suggestion below: > > >> * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties >> which becomes the administrative *control* point. >> * and new properties, "cap_link_pm", "enable_link_pm", and >> "link_pm_state", which are boolean values indicate the ability to do this >> kind of link power management, whether it is turned on, and the current >> state (link speed is reduced for power management or not). >> > > is the ideal solution. > I'm glad you think so! Any chance of getting this into the commitment materials before Wednesday? (I apologize for not getting you this feedback earlier, but I really only considered the impact on Brussels last night.) > The existing adv* tunables have been around for far too long, so > lowering their stability with Brussels would discourage adoption, > as Jim points out in > http://mail.opensolaris.org/pipermail/brussels-dev/2007-October/000462.html > Ah, this is with the ndd API. As a possible (and hideous!) hack, one could imagine doing the following: * start off with the ndd management interface marked Obsolete. * don't enable link pm features via ndd. * the enable_xxx bits might not be really writeable? * if adv_xxx is written via NDD, treat it as a write to the enable_xxx properties. * if adv_xxx is read via NDD, return the value from the ANAR This means that the adv_xxx values would retain their behavior and meaning via the NDD hack, but that would behave slightly differently if using the newer Brussels API. I will confess, the more and more I think about it, the more and more I start to believe that the ndd interfaces really should just be removed outright. Right now the problem is that a few internal consumers of ndd exist. I don't have a problem with breaking most of them (NICDRV is one such, SunVTS is another), but I'd prefer not to break SunVTS. Maybe this means that SunVTS needs to change. What does the project team, and what does ARC think, about just yanking these interfaces in Nevada, and marking them Obsolete in S10u5? Are we willing to deal with the fallout from the breakage from the places that have done their own thing? IMO, this breakage is not very different from the precedent set by SMF... when SMF came out, a bunch of administrative practice surrounding init.d scripts and inetd.conf was "busted". I think folks adapted rather gracefully to it. Furthermore, I think the scope of breakage that would be created by removing the NDD command and underlying ioctls (at least for NIC drivers) is not too bad. Indeed, not every NIC driver even supports these ioctls. -- Garrett > >> Note that the above suggestion would require adding new enable_xxx >> properties even to NICs that don't have link power management. (And yes, >> it isn't strictly "required", but it would be a lot simpler if all NICs >> were administered the same way from the first time the project integrated.) >> > > Agreed. As you point out, the set of "public" properties is a rapidly > changing one. The idea, with PSARC 2007/429, is to offer the bare minimum > of interfaces with the framework so that cutting-edge projects like > suspend/resume can contribute/modify the set efficiently. > > --Sowmini > > > From sowmini.varadhan@sun.com Mon Oct 15 10:15:33 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FHFW0p006722 for ; Mon, 15 Oct 2007 10:15:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9FHC74Q022119; Tue, 16 Oct 2007 01:12:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00I2VQG6TX00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 10:12:06 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY005BHQG1P0D0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 10:12:02 -0700 (PDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9FHC1Ih040225; Mon, 15 Oct 2007 13:12:01 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9FGlLlr024424; Mon, 15 Oct 2007 12:47:21 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9FGlLKc024423; Mon, 15 Oct 2007 12:47:21 -0400 (EDT) Date: Mon, 15 Oct 2007 12:47:21 -0400 From: sowmini.varadhan@sun.com Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <47139400.7040200@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore" , brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <20071015164721.GJ22510@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> <47139400.7040200@sun.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.16 (2007-06-11) Status: RO Content-Length: 3208 On (10/15/07 09:23), Garrett D'Amore wrote: >>> * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties >>> which becomes the administrative *control* point. >>> * and new properties, "cap_link_pm", "enable_link_pm", and >>> "link_pm_state", which are boolean values indicate the ability to do this >>> kind of link power management, whether it is turned on, and the current >>> state (link speed is reduced for power management or not). >>> >> >> is the ideal solution. >> > > I'm glad you think so! Any chance of getting this into the commitment > materials before Wednesday? (I apologize for not getting you this feedback > earlier, but I really only considered the impact on Brussels last night.) I can't update the materials any more, but we can certainly add it to the AI's and make sure it gets addressed prior to cteam reviews. > I will confess, the more and more I think about it, the more and more I > start to believe that the ndd interfaces really should just be removed > outright. Unfortunately, yanking out ndd(1m) has to be done gradually, so the project team has adopted the solution below 1. as part of PSARC 2007/429, attempts to use ndd calls (either via /sbin/ndd, or by issuing the ND_SET/ND_GET ioctls directly) will succeed, but, for each converted driver, a warning message (sample shown below) will be issued: bge: WARNING: The ndd commands are obsolete and may be removed in a future release of Solaris. Use dladm(1M) to manipulate the adv_autoneg_cap property 2. new drivers must not provide any ND_SET/ND_GET ioctl handling code of any sort. 3. the ndd compat component of Brussels will clean up the existing ndd code in drivers so that legacy support for the ndd ioctls will be deflected from the GLDv3 (dld/mac) layers. (for the curious, there's a work-in-progress code review at http://mail.opensolaris.org/pipermail/brussels-dev/2007-October/000488.html) > Right now the problem is that a few internal consumers of ndd exist. I > don't have a problem with breaking most of them (NICDRV is one such, SunVTS > is another), but I'd prefer not to break SunVTS. Maybe this means that > SunVTS needs to change. We are looking into SunVTS, and what changes would be involved. > What does the project team, and what does ARC think, about just yanking > these interfaces in Nevada, and marking them Obsolete in S10u5? > > Are we willing to deal with the fallout from the breakage from the places > that have done their own thing? IMO, this breakage is not very different > from the precedent set by SMF... when SMF came out, a bunch of > administrative practice surrounding init.d scripts and inetd.conf was > "busted". I think folks adapted rather gracefully to it. Furthermore, I > think the scope of breakage that would be created by removing the NDD > command and underlying ioctls (at least for NIC drivers) is not too bad. > Indeed, not every NIC driver even supports these ioctls. While this is all true, I disagree that we should break these interfaces in S10u5 - we can mark them Obsolete and provide legacy support for the ndd paths. --Sowmini From carlsonj@phorcys.east.sun.com Mon Oct 15 10:45:37 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FHja7S007632 for ; Mon, 15 Oct 2007 10:45:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FHfvqf014784; Mon, 15 Oct 2007 18:42:13 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00L17RUCDK00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 10:42:12 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00LCKRU71600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 10:42:08 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9FHYG24017545; Mon, 15 Oct 2007 13:34:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9FHYGQX017542; Mon, 15 Oct 2007 13:34:16 -0400 (EDT) Date: Mon, 15 Oct 2007 13:34:16 -0400 From: James Carlson Subject: Re: [brussels-dev] PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <20071015164721.GJ22510@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org Message-id: <18195.42136.760354.108225@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> <47139400.7040200@sun.com> <20071015164721.GJ22510@quasimodo.East.Sun.COM> Status: RO Content-Length: 815 Sowmini.Varadhan@Sun.COM writes: > > I'm glad you think so! Any chance of getting this into the commitment > > materials before Wednesday? (I apologize for not getting you this feedback > > earlier, but I really only considered the impact on Brussels last night.) > > I can't update the materials any more, but we can certainly add it > to the AI's and make sure it gets addressed prior to cteam reviews. This looks like a smallish change to me. Feel free to bring it up during the commitment review. We'll likely be able to vote anyway, and you'll just owe a final spec after that. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From garrett@damore.org Mon Oct 15 10:56:56 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FHuuRF008404 for ; Mon, 15 Oct 2007 10:56:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FHrYgs061318; Mon, 15 Oct 2007 11:53:34 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY0080DSD9ZZ00@brm-avmta-1.central.sun.com>; Mon, 15 Oct 2007 11:53:33 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY004YNSD7EH70@brm-avmta-1.central.sun.com>; Mon, 15 Oct 2007 11:53:31 -0600 (MDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9FHTit7013722; Mon, 15 Oct 2007 17:53:31 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay41i.sun.com with ESMTP id BT-MMP-82870; Mon, 15 Oct 2007 17:53:27 +0000 (Z) Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by mms49es.sun.com with ESMTP id BT-MMP-30070; Mon, 15 Oct 2007 17:53:27 +0000 (Z) Received: from occp5.ocservers.net ([216.73.122.2] [216.73.122.2]) by relay4i.sun.com with ESMTP id BT-MMP-26000552; Mon, 15 Oct 2007 17:53:26 +0000 (Z) Received: from [192.18.43.225] (helo=[10.7.251.172]) by occp5.ocservers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IhU87-0002sO-V3; Mon, 15 Oct 2007 10:53:28 -0700 Date: Mon, 15 Oct 2007 10:50:44 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <20071015164721.GJ22510@quasimodo.East.Sun.COM> To: sowmini.varadhan@sun.com Cc: "Garrett D'Amore" , brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <4713A874.8050305@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - occp5.ocservers.net X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - damore.org References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> <47139400.7040200@sun.com> <20071015164721.GJ22510@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1022 >> What does the project team, and what does ARC think, about just yanking >> these interfaces in Nevada, and marking them Obsolete in S10u5? >> >> Are we willing to deal with the fallout from the breakage from the places >> that have done their own thing? IMO, this breakage is not very different >> from the precedent set by SMF... when SMF came out, a bunch of >> administrative practice surrounding init.d scripts and inetd.conf was >> "busted". I think folks adapted rather gracefully to it. Furthermore, I >> think the scope of breakage that would be created by removing the NDD >> command and underlying ioctls (at least for NIC drivers) is not too bad. >> Indeed, not every NIC driver even supports these ioctls. >> > > While this is all true, I disagree that we should break these interfaces > in S10u5 - we can mark them Obsolete and provide legacy support for the > ndd paths. > I think that's what I said... mark them obsolete in S10u5, and maybe remove them in Nevada. -- Garrett From randy.fishel@sun.com Mon Oct 15 11:10:34 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FIAXZJ009090 for ; Mon, 15 Oct 2007 11:10:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9FI6gEq016937 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 02:07:11 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00009SZZUK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 11:07:11 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00LXPSZY1C20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 11:07:10 -0700 (PDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9FI7AoK018739; Mon, 15 Oct 2007 11:07:10 -0700 (PDT) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id l9FI6qQt009632; Mon, 15 Oct 2007 11:06:52 -0700 (PDT) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id l9FI6qxl009628; Mon, 15 Oct 2007 11:06:52 -0700 (PDT) Date: Mon, 15 Oct 2007 11:06:52 -0700 (PDT) From: Randy Fishel Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <47138534.4000101@damore.org> X-X-Sender: randyf@grimmy To: "Garrett D'Amore" Cc: sowmini.varadhan@sun.com, brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 3525 On Mon, 15 Oct 2007, Garrett D'Amore wrote: > I was chatting with some folks at the OpenSolaris Developer Summit, and I > think the Brussels project needs to consider a possible future enhancement > that NIC drivers are likely to make. > > Specifically, in order to save power, many NIC drivers are likely to want to > switch down to a lower speed from 10G or 1G down to 100Mbps or 10Mbps. This > is because running at 1G consumes on average about 1W per port. Versus less > than 1/10th of that at 100Mbps. > As far as Brussels is concerned, I'm interested in the link state and speed > properties. Right now the adv_xxx properties indicate both the > administrator's desired negotiation parameters, and the actual state of the > MII ANAR register on the PHY. > > We need to break that up in the future. Specifically, we are going to need a > way for the administrator to say "I want autonegotiation, and I'm willing to > negotiate for everything, but I also want the NIC to downscale the speed when > the NIC drops below a certain utilization for a while." And we need a way to > be able to see that. > > But *independently*, we need a way to look at the current state of the ANAR > register for debug. When the NIC is running at a lower speed, it may have > ANAR register bits cleared that would otherwise be set once the demand for > bandwidth increases. > > Anyway, I'd like the project team to consider how this could be retrofitted in > the future without breaking any interfaces that are being presented today. It > is possible that the interfaces (properties) that are being proposed today > might need either a lower commitment level, or maybe we can imagine a better > set of properties or even a simple enhancement to the properties to > accommodate this kind of future enhancement. (Perhaps an additional set of > properties?) > > One possible approach (and I'm not sure that this is the best way, but I'm > just offering it as a strawman and I'd really like to hear the project team's > thoughts!) might be: > > * change adv_xxx spec to indicate that this is a read-only property > indicating the NIC's MII register contents > * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties > which becomes the administrative *control* point. > * and new properties, "cap_link_pm", "enable_link_pm", and "link_pm_state", > which are boolean values indicate the ability to do this kind of link power > management, whether it is turned on, and the current state (link speed is > reduced for power management or not). One caution is to make sure that these shouldn't be defined, saved, or controlled in the PM framework policy file(s). It is important to make sure that policy has one entry point (and the PM entry point already exists). I do see that this is proposed as the control point (which should be ok), but try and keep away from defining PM policy here. ---- Randy > > Note that the above suggestion would require adding new enable_xxx properties > even to NICs that don't have link power management. (And yes, it isn't > strictly "required", but it would be a lot simpler if all NICs were > administered the same way from the first time the project integrated.) > > And to be clear, I don't think we are going to go very long at all before NIC > drivers start looking for this kind of feature... projects like Tesla, laptop > suspend/resume, and wake-on-lan demonstrate that power savings features are > becoming very important. > > -- Garrett > > From garrett@damore.org Mon Oct 15 11:19:02 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FIJ1Hl009335 for ; Mon, 15 Oct 2007 11:19:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FIFdFl003063; Mon, 15 Oct 2007 12:15:39 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00305TE2DD00@nwk-avmta-2.sfbay.sun.com>; Mon, 15 Oct 2007 11:15:38 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00CZ0TE24TE0@nwk-avmta-2.sfbay.sun.com>; Mon, 15 Oct 2007 11:15:38 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9FI4CRc017561; Mon, 15 Oct 2007 18:15:37 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay41i.sun.com with ESMTP id BT-MMP-84473; Mon, 15 Oct 2007 18:15:37 +0000 (Z) Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-72095; Mon, 15 Oct 2007 18:15:37 +0000 (Z) Received: from occp5.ocservers.net ([216.73.122.2] [216.73.122.2]) by relay4i.sun.com with ESMTP id BT-MMP-26023147; Mon, 15 Oct 2007 18:15:37 +0000 (Z) Received: from [192.18.43.225] (helo=[10.7.251.172]) by occp5.ocservers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IhUTZ-00045Q-Oi; Mon, 15 Oct 2007 11:15:38 -0700 Date: Mon, 15 Oct 2007 11:12:54 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <18195.43857.220929.631665@gargle.gargle.HOWL> To: James Carlson Cc: sowmini.varadhan@sun.com, "Garrett D'Amore" , brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <4713ADA6.6080807@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - occp5.ocservers.net X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - damore.org References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> <47139400.7040200@sun.com> <20071015164721.GJ22510@quasimodo.East.Sun.COM> <4713A874.8050305@damore.org> <18195.43857.220929.631665@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1020 James Carlson wrote: > Garrett D'Amore writes: > >>> While this is all true, I disagree that we should break these interfaces >>> in S10u5 - we can mark them Obsolete and provide legacy support for the >>> ndd paths. >>> >>> >> I think that's what I said... mark them obsolete in S10u5, and maybe >> remove them in Nevada. >> > > That would be a good plan if this project had patch/micro release > binding, but instead it has minor release binding. > > I don't think we should declare something to be "obsolete" in S10u5 > unless users have something to which they can migrate. Otherwise, > we're just saying "don't use this ... but don't use anything else, > either." > Okay, I agree with that logic. There needs to be overlap. I wonder if a simplistic dladm wrapper around ndd can be developed for S10u5, just so that we can obsolete the interfaces.... Perhaps that can be a follow up project, but in the meantime I guess we need Brussels to continue to provide NDD. :-( -- Garrett From carlsonj@phorcys.east.sun.com Mon Oct 15 11:21:49 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FILmmA009437 for ; Mon, 15 Oct 2007 11:21:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9FIIK62022247; Tue, 16 Oct 2007 02:18:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00154TILP000@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 11:18:21 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00LXTTIJ1730@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 11:18:20 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9FI2xCh017723; Mon, 15 Oct 2007 14:02:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9FI2vkt017720; Mon, 15 Oct 2007 14:02:57 -0400 (EDT) Date: Mon, 15 Oct 2007 14:02:57 -0400 From: James Carlson Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <4713A874.8050305@damore.org> To: "Garrett D'Amore" Cc: sowmini.varadhan@sun.com, "Garrett D'Amore" , brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <18195.43857.220929.631665@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> <47139400.7040200@sun.com> <20071015164721.GJ22510@quasimodo.East.Sun.COM> <4713A874.8050305@damore.org> Status: RO Content-Length: 853 Garrett D'Amore writes: > > While this is all true, I disagree that we should break these interfaces > > in S10u5 - we can mark them Obsolete and provide legacy support for the > > ndd paths. > > > > I think that's what I said... mark them obsolete in S10u5, and maybe > remove them in Nevada. That would be a good plan if this project had patch/micro release binding, but instead it has minor release binding. I don't think we should declare something to be "obsolete" in S10u5 unless users have something to which they can migrate. Otherwise, we're just saying "don't use this ... but don't use anything else, either." -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sowmini.varadhan@sun.com Mon Oct 15 11:48:58 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FImwBf009971 for ; Mon, 15 Oct 2007 11:48:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9FIjY4w013188; Mon, 15 Oct 2007 12:45:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY0041PUS0BO00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 11:45:36 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00LIGURZ1760@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Oct 2007 11:45:35 -0700 (PDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9FIjY46006555; Mon, 15 Oct 2007 14:45:34 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9FIKtK4025128; Mon, 15 Oct 2007 14:20:55 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9FIKtvI025127; Mon, 15 Oct 2007 14:20:55 -0400 (EDT) Date: Mon, 15 Oct 2007 14:20:55 -0400 From: sowmini.varadhan@sun.com Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <4713ADA6.6080807@damore.org> To: "Garrett D'Amore" Cc: James Carlson , "Garrett D'Amore" , brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <20071015182055.GR22510@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> <47139400.7040200@sun.com> <20071015164721.GJ22510@quasimodo.East.Sun.COM> <4713A874.8050305@damore.org> <18195.43857.220929.631665@gargle.gargle.HOWL> <4713ADA6.6080807@damore.org> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.16 (2007-06-11) Status: RO Content-Length: 471 On (10/15/07 11:12), Garrett D'Amore wrote: > > Okay, I agree with that logic. There needs to be overlap. > > I wonder if a simplistic dladm wrapper around ndd can be developed for > S10u5, just so that we can obsolete the interfaces.... Perhaps that can be > a follow up project, but in the meantime I guess we need Brussels to > continue to provide NDD. :-( The ndd compat component will provide this, by deflecting the ndd ioctls at the mac layer. --Sowmini From gdamore@sun.com Mon Oct 15 12:16:55 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FJGscf010675 for ; Mon, 15 Oct 2007 12:16:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9FJDKwI016839; Tue, 16 Oct 2007 03:13:30 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPY00DAXW2HX900@brm-avmta-1.central.sun.com>; Mon, 15 Oct 2007 13:13:29 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPY00DFZW0RMZ10@brm-avmta-1.central.sun.com>; Mon, 15 Oct 2007 13:12:27 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9FJCRR9025214; Mon, 15 Oct 2007 12:12:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPY00501T3CJ800@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Mon, 15 Oct 2007 11:12:27 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPY009IFT8NQ150@fe-sfbay-10.sun.com>; Mon, 15 Oct 2007 11:12:23 -0700 (PDT) Date: Mon, 15 Oct 2007 11:09:45 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: Sender: Garrett.Damore@sun.com To: Randy Fishel Cc: "Garrett D'Amore" , Sowmini.Varadhan@sun.com, brussels-dev@opensolaris.org, PSARC-ext@sun.com Message-id: <4713ACE9.9070901@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 4178 Randy Fishel wrote: > On Mon, 15 Oct 2007, Garrett D'Amore wrote: > > >> I was chatting with some folks at the OpenSolaris Developer Summit, and I >> think the Brussels project needs to consider a possible future enhancement >> that NIC drivers are likely to make. >> >> Specifically, in order to save power, many NIC drivers are likely to want to >> switch down to a lower speed from 10G or 1G down to 100Mbps or 10Mbps. This >> is because running at 1G consumes on average about 1W per port. Versus less >> than 1/10th of that at 100Mbps. >> As far as Brussels is concerned, I'm interested in the link state and speed >> properties. Right now the adv_xxx properties indicate both the >> administrator's desired negotiation parameters, and the actual state of the >> MII ANAR register on the PHY. >> >> We need to break that up in the future. Specifically, we are going to need a >> way for the administrator to say "I want autonegotiation, and I'm willing to >> negotiate for everything, but I also want the NIC to downscale the speed when >> the NIC drops below a certain utilization for a while." And we need a way to >> be able to see that. >> >> But *independently*, we need a way to look at the current state of the ANAR >> register for debug. When the NIC is running at a lower speed, it may have >> ANAR register bits cleared that would otherwise be set once the demand for >> bandwidth increases. >> >> Anyway, I'd like the project team to consider how this could be retrofitted in >> the future without breaking any interfaces that are being presented today. It >> is possible that the interfaces (properties) that are being proposed today >> might need either a lower commitment level, or maybe we can imagine a better >> set of properties or even a simple enhancement to the properties to >> accommodate this kind of future enhancement. (Perhaps an additional set of >> properties?) >> >> One possible approach (and I'm not sure that this is the best way, but I'm >> just offering it as a strawman and I'd really like to hear the project team's >> thoughts!) might be: >> >> * change adv_xxx spec to indicate that this is a read-only property >> indicating the NIC's MII register contents >> * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties >> which becomes the administrative *control* point. >> * and new properties, "cap_link_pm", "enable_link_pm", and "link_pm_state", >> which are boolean values indicate the ability to do this kind of link power >> management, whether it is turned on, and the current state (link speed is >> reduced for power management or not). >> > > One caution is to make sure that these shouldn't be defined, saved, > or controlled in the PM framework policy file(s). It is important to > make sure that policy has one entry point (and the PM entry point > already exists). I do see that this is proposed as the control point > (which should be ok), but try and keep away from defining PM policy > here. > Perhaps the "enabling" feature shouldn't be here. I do think that this should ultimately be driven out of a driver's power(9e) entry point, but the problem is an overlap in administration between what is normal for a NIC, and what is normal for power management. I agree that for the most part, policy needs to come from the PM framework. The question is that this will impact other visible parts of the administration, and we need to figure out a way for an administrator to figure out just what is going on. - Garrett > ---- Randy > > >> Note that the above suggestion would require adding new enable_xxx properties >> even to NICs that don't have link power management. (And yes, it isn't >> strictly "required", but it would be a lot simpler if all NICs were >> administered the same way from the first time the project integrated.) >> >> And to be clear, I don't think we are going to go very long at all before NIC >> drivers start looking for this kind of feature... projects like Tesla, laptop >> suspend/resume, and wake-on-lan demonstrate that power savings features are >> becoming very important. >> >> -- Garrett >> >> >> > > From Terry.Whatley@sun.com Mon Oct 15 15:19:02 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FMJ1Ua016792 for ; Mon, 15 Oct 2007 15:19:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9FMFTQM018737 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 06:15:39 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPZ005A14I1EW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 16:15:38 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPZ00KFZ4C62850@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 16:12:45 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9FMC6XS015234 for ; Mon, 15 Oct 2007 15:12:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPY00201PXWUH00@fe-sfbay-09.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 10:12:06 -0700 (PDT) Received: from [129.146.97.132] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPY00AXDQG6PU50@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Oct 2007 10:12:06 -0700 (PDT) Date: Mon, 15 Oct 2007 10:12:06 -0700 From: "Terry (Sarito) Whatley" Subject: Re: PSARC 2007/429 Brussels (another brussels issue...) In-reply-to: <20071015154752.GG22510@quasimodo.East.Sun.COM> Sender: Terry.Whatley@sun.com To: Sowmini.Varadhan@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org Message-id: <47139F66.4010903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47130D31.30703@sun.com> <20071015102323.GF12613@quasimodo.East.Sun.COM> <47138534.4000101@damore.org> <20071015154752.GG22510@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 3667 Sowmini.Varadhan@Sun.COM wrote: > On (10/15/07 08:20), Garrett D'Amore wrote: > >> I was chatting with some folks at the OpenSolaris Developer Summit, and I >> think the Brussels project needs to consider a possible future enhancement >> that NIC drivers are likely to make. >> >> Specifically, in order to save power, many NIC drivers are likely to want >> to switch down to a lower speed from 10G or 1G down to 100Mbps or 10Mbps. >> This is because running at 1G consumes on average about 1W per port. >> Versus less than 1/10th of that at 100Mbps. >> Under the new EnergyStar spec for workstations, NICs are required to reduce speed below 1G when the system enters sleep or standby mode. Reducing speed under low load is also a requirement under the new EPA EnergyStar proposed "Tier 2" rules for workstations, and probably will also show up in the EnergyStar rules for servers when they are hashed out in the next year or so. -sarito >> As far as Brussels is concerned, I'm interested in the link state and speed >> properties. Right now the adv_xxx properties indicate both the >> administrator's desired negotiation parameters, and the actual state of the >> MII ANAR register on the PHY. >> >> We need to break that up in the future. Specifically, we are going to need >> a way for the administrator to say "I want autonegotiation, and I'm willing >> to negotiate for everything, but I also want the NIC to downscale the speed >> when the NIC drops below a certain utilization for a while." And we need a >> way to be able to see that. >> >> But *independently*, we need a way to look at the current state of the ANAR >> register for debug. When the NIC is running at a lower speed, it may have >> ANAR register bits cleared that would otherwise be set once the demand for >> bandwidth increases. >> > > Garrett, > > Interesting point. It seems to me that the best way to provision > for advanced power-management concepts would be to add additional > enhanced properties. > > Thus, we could have the existing adv* properties, plus additional > enable_link_pm modifiers (with the associated versions to examine > the link state, and set the capability), i.e., the suggestion below: > > >> * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties >> which becomes the administrative *control* point. >> * and new properties, "cap_link_pm", "enable_link_pm", and >> "link_pm_state", which are boolean values indicate the ability to do this >> kind of link power management, whether it is turned on, and the current >> state (link speed is reduced for power management or not). >> > > is the ideal solution. > > The existing adv* tunables have been around for far too long, so > lowering their stability with Brussels would discourage adoption, > as Jim points out in > http://mail.opensolaris.org/pipermail/brussels-dev/2007-October/000462.html > > >> Note that the above suggestion would require adding new enable_xxx >> properties even to NICs that don't have link power management. (And yes, >> it isn't strictly "required", but it would be a lot simpler if all NICs >> were administered the same way from the first time the project integrated.) >> > > Agreed. As you point out, the set of "public" properties is a rapidly > changing one. The idea, with PSARC 2007/429, is to offer the bare minimum > of interfaces with the framework so that cutting-edge projects like > suspend/resume can contribute/modify the set efficiently. > > --Sowmini > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From garrett@damore.org Wed Oct 17 10:33:09 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHX9eG013883 for ; Wed, 17 Oct 2007 10:33:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHTj5o011655 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 11:29:47 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C0PGLM1A00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:29:46 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2006EAGLLWC50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:29:45 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HHTjWe027181 for ; Wed, 17 Oct 2007 17:29:45 +0000 (GMT) Received: from mmp14es.sun.com ([160.41.209.24] [160.41.209.24]) by relay12i.sun.com with ESMTP id BT-MMP-402121 for PSARC-ext@sun.com; Wed, 17 Oct 2007 17:29:44 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp14es.sun.com with ESMTP id BT-MMP-111248 for PSARC-ext@sun.com; Wed, 17 Oct 2007 17:29:44 +0000 (Z) Received: from occp5.ocservers.net ([216.73.122.2] [216.73.122.2]) by relay1ib.sun.com with ESMTP id BT-MMP-1484674 for PSARC-ext@sun.com; Wed, 17 Oct 2007 17:29:44 +0000 (Z) Received: from [192.18.43.225] (helo=[10.7.251.172]) by occp5.ocservers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IiCiH-0003KA-DF for PSARC-ext@sun.com; Wed, 17 Oct 2007 10:29:46 -0700 Date: Wed, 17 Oct 2007 10:26:56 -0700 From: "Garrett D'Amore" Subject: PSARC 2007/429 (brussels) To: PSARC-ext@sun.com Message-id: <471645E0.7020806@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - occp5.ocservers.net X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - damore.org User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 948 A few quick comments on the Brussels case. 20q, question #8. I think the answer here should have been Yes, because Brussels provides a consistent interface to NIC management, thereby improving Serviceability. (Not impacting the R and A components of RAS, though.) 20q, question #9. It appears that kstats are a Phase II deliverable. Does it deserve mention here? 20q, question #10. I think that the security implication here is that Brussels uses RBAC to control access to NIC configuration. That's not precisely the same as "none". The rest of it looks good. I still want to address my issue of power management that I raised separately earlier this week, during the review. I'm not sure whether it is fair to edit the issues file in the commitment materials directory or not? (Sorry, Brussels folk, you have the dubious distinction of being the first case I've interned on to go for commitment review.) -- Garrett From carlsonj@phorcys.east.sun.com Wed Oct 17 10:44:30 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHiU6W014693 for ; Wed, 17 Oct 2007 10:44:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHf8AG014350 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 10:41:08 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200I01H4K5S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:41:08 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20090CH4JPX70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:41:07 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HHXGhR027149; Wed, 17 Oct 2007 13:33:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HHXEM7027146; Wed, 17 Oct 2007 13:33:14 -0400 (EDT) Date: Wed, 17 Oct 2007 13:33:14 -0400 From: James Carlson Subject: Re: PSARC 2007/429 (brussels) In-reply-to: <471645E0.7020806@damore.org> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <18198.18266.554477.330461@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471645E0.7020806@damore.org> Status: RO Content-Length: 697 Garrett D'Amore writes: > I still want to address my issue of power management that I raised > separately earlier this week, during the review. I'm not sure whether > it is fair to edit the issues file in the commitment materials directory > or not? (Sorry, Brussels folk, you have the dubious distinction of > being the first case I've interned on to go for commitment review.) Don't edit the team's supplied materials. Add to the top-level 'issues' file instead. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Wed Oct 17 10:56:16 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHuGIU015687 for ; Wed, 17 Oct 2007 10:56:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHqs2E018123 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 10:52:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200E0JHO6DH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:52:54 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2006QHHO0WD60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:52:52 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HHqmIC014201 for ; Wed, 17 Oct 2007 10:52:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200E01HHSA300@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:52:48 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200KQIHNZUL40@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:52:47 -0700 (PDT) Date: Wed, 17 Oct 2007 10:50:02 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2007/429 (brussels) In-reply-to: <18198.18266.554477.330461@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47164B4A.6000605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471645E0.7020806@damore.org> <18198.18266.554477.330461@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 897 James Carlson wrote: > Garrett D'Amore writes: > >> I still want to address my issue of power management that I raised >> separately earlier this week, during the review. I'm not sure whether >> it is fair to edit the issues file in the commitment materials directory >> or not? (Sorry, Brussels folk, you have the dubious distinction of >> being the first case I've interned on to go for commitment review.) >> > > Don't edit the team's supplied materials. Add to the top-level > 'issues' file instead. > > Hmm... my sac-staff membership seems to have gone away. I can't edit the file. Can I talk you into putting in the following issue for me? Please? :-) ged-05 What about power management of link interfaces? (e.g. switching down to 100Mbps when traffic conditions permit it.) This will require some new properties, and maybe changes to the proposed adv_xxx properties. From sowmini.varadhan@sun.com Wed Oct 17 11:08:07 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HI86tF016068 for ; Wed, 17 Oct 2007 11:08:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HI4gd9023081 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 12:04:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200D0BI7UHR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:04:42 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004Y5I7TVAB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:04:41 -0700 (PDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9HI4eih044976 for ; Wed, 17 Oct 2007 14:04:41 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9HHlTcp015397; Wed, 17 Oct 2007 13:47:29 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9HHlTeY015396; Wed, 17 Oct 2007 13:47:29 -0400 (EDT) Date: Wed, 17 Oct 2007 13:47:29 -0400 From: sowmini.varadhan@sun.com Subject: Re: PSARC 2007/429 (brussels) In-reply-to: <471645E0.7020806@damore.org> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <20071017174729.GD14177@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <471645E0.7020806@damore.org> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.16 (2007-06-11) Status: RO Content-Length: 1774 On (10/17/07 10:26), Garrett D'Amore wrote: > > A few quick comments on the Brussels case. > > 20q, question #8. I think the answer here should have been Yes, because > Brussels provides a consistent interface to NIC management, thereby > improving Serviceability. (Not impacting the R and A components of RAS, > though.) Accept, and some of that is implied by the answer to the subsequent question on diagnosing failures. > 20q, question #9. It appears that kstats are a Phase II deliverable. > Does it deserve mention here? The Phase II deliverables have not been scoped out to fine granularity, but so far, the main objective there is to change the "under-the-hood" implementation of kstats themselves, rather than to export any new kstats. We may end up doing the latter, but those details will be provided by the PSARC case associated with this work. > 20q, question #10. I think that the security implication here is that > Brussels uses RBAC to control access to NIC configuration. That's not > precisely the same as "none". right- Gary and I had an earlier discussion about this; we are planning to leverage on the same RBAC infrastructure currently used by dladm for managing wifi and aggr interfaces. Perhaps I should mention this explicitly? > I still want to address my issue of power management that I raised > separately earlier this week, during the review. I'm not sure whether it > is fair to edit the issues file in the commitment materials directory or > not? (Sorry, Brussels folk, you have the dubious distinction of being the > first case I've interned on to go for commitment review.) I think (other PSARC members can confirm) the usuual procedure is to add to the issues file, and bring it up during review. --Sowmini From carlsonj@phorcys.east.sun.com Wed Oct 17 11:11:19 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HIBIKi016281 for ; Wed, 17 Oct 2007 11:11:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HI7lQg026542; Thu, 18 Oct 2007 02:07:53 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200D07ID4O700@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:07:52 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004XQID3VLC0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:07:52 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HHxxYF027401; Wed, 17 Oct 2007 13:59:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HHxxrx027398; Wed, 17 Oct 2007 13:59:59 -0400 (EDT) Date: Wed, 17 Oct 2007 13:59:59 -0400 From: James Carlson Subject: Re: PSARC 2007/429 (brussels) In-reply-to: <47164B4A.6000605@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <18198.19871.333065.820680@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471645E0.7020806@damore.org> <18198.18266.554477.330461@gargle.gargle.HOWL> <47164B4A.6000605@sun.com> Status: RO Content-Length: 575 Garrett D'Amore writes: > Hmm... my sac-staff membership seems to have gone away. I can't edit the > file. I checked, and you should at least have that privilege locally on sac.sfbay. The NIS maps may be out of whack, though. We sometimes have to trouble with that. > Can I talk you into putting in the following issue for me? Please? :-) Done. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Wed Oct 17 11:15:58 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HIFvl9016424 for ; Wed, 17 Oct 2007 11:15:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HICXBj028738 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 02:12:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200K0RIKX8O00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 12:12:33 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20098GIKXQ690@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 12:12:33 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HICWfD017157 for ; Wed, 17 Oct 2007 11:12:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200801GLKY800@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:12:32 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2007QYIKV5NE0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:12:31 -0700 (PDT) Date: Wed, 17 Oct 2007 11:09:47 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2007/429 (brussels) In-reply-to: <18198.19871.333065.820680@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47164FEB.9060908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <471645E0.7020806@damore.org> <18198.18266.554477.330461@gargle.gargle.HOWL> <47164B4A.6000605@sun.com> <18198.19871.333065.820680@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 511 James Carlson wrote: > Garrett D'Amore writes: > >> Hmm... my sac-staff membership seems to have gone away. I can't edit the >> file. >> > > I checked, and you should at least have that privilege locally on > sac.sfbay. The NIS maps may be out of whack, though. We sometimes > have to trouble with that. > > >> Can I talk you into putting in the following issue for me? Please? :-) >> > > Done. > > Thanks. And I was the idjit that was logged into onnv instead of sac. Sorry. -- Garrett From gdamore@sun.com Wed Oct 17 19:26:45 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I2QjmY002868 for ; Wed, 17 Oct 2007 19:26:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9I2NNGH002791 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 19:23:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ3005035AXGC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 19:23:21 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ3002V45AXXA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 19:23:21 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9I2NLDP008645 for ; Wed, 17 Oct 2007 19:23:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ300E0157PWS00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 19:23:21 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ3000I05AWBU70@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 19:23:21 -0700 (PDT) Date: Wed, 17 Oct 2007 19:20:35 -0700 From: "Garrett D'Amore" Subject: PSARC 2007/429 brussels Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <4716C2F3.50909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 136 This case was approved at today's meeting, with a single TCA. I'll be sending out a draft opinion statement shortly. -- Garrett From garrett@damore.org Wed Oct 17 22:25:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I5PrQW005525 for ; Wed, 17 Oct 2007 22:25:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9I5MRoR016367 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 13:22:30 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ300J0FDLHU800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 23:22:29 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300LJXDLFX5D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 23:22:28 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9I5MRCv026858 for ; Thu, 18 Oct 2007 05:22:27 +0000 (GMT) Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay11i.sun.com with ESMTP id BT-MMP-426489 for PSARC-ext@sun.com; Thu, 18 Oct 2007 05:22:27 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.sun.com with ESMTP id BT-MMP-58964 for PSARC-ext@sun.com; Thu, 18 Oct 2007 05:22:27 +0000 (Z) Received: from occp5.ocservers.net ([216.73.122.2] [216.73.122.2]) by relay1i.sun.com with ESMTP id BT-MMP-2259900 for PSARC-ext@sun.com; Thu, 18 Oct 2007 05:22:26 +0000 (Z) Received: from [192.18.43.225] (helo=[10.7.251.172]) by occp5.ocservers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IiNq2-00030c-Qe for PSARC-ext@sun.com; Wed, 17 Oct 2007 22:22:30 -0700 Date: Wed, 17 Oct 2007 22:19:29 -0700 From: "Garrett D'Amore" Subject: PSARC 2007/429 brussels To: PSARC-ext@sun.com Message-id: <4716ECE1.3060205@damore.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Dnv2T22YnE+HoAqhcDhTHg)" X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - occp5.ocservers.net X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - damore.org User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 9093 This is a multi-part message in MIME format. --Boundary_(ID_Dnv2T22YnE+HoAqhcDhTHg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Here is the draft opinion for the Brussels case. I've also placed draftopinion.{ms,txt,ps} in the case directory, in case anyone wants a different format. I'm not sure what the process is to take a draft opinion and make it formal. What's next? -- Garrett --Boundary_(ID_Dnv2T22YnE+HoAqhcDhTHg) Content-type: text/plain; name=draftopinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=draftopinion.txt sun _________________________________________________________________ Subject: Brussels - enhanced network driver configura- tion via dladm Submitted by: Sowmini Varadhan File: PSARC/2007/429/opinion.ms Date: October 17, 2007 Committee: James D. Carlson (opinion written by Garrett D'Amore), Kais Belgaied, Glenn Skinner Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Brussels is a project to enhance and standardize network interface configuration through properties. It extends the GLDv3 driver interface to make it easy for drivers to expose device properties to Solaris, and provides normalized access to these properties via the dladm(1m) command line applica- tion. The intent of the Brussels project is to replace the legacy ndd(1m) for the use of configuration of parameters such as link speed, 802.3x flow control, etc. Brussels will provide a compatibility layer for legacy applications which make use of the ndd ioctls, and scripts (or administrators) which continue to use the ndd CLI, but it makes the use of NDD (either at the CLI or ioctl layer) Obsolete. Brussels also introduces persistence to network device con- figuration. That is, configuration settings can be made such that the setting will survive across a reboot of the system. This is a new feature, that was lacking from NDD. Brussels also includes support for devices to define their own properties, as well as including a predefined list of common properties. This is the first phase of a multiphase project. Future PSARC/2007/429 Copyright 2007 Sun Microsystems - 2 - phases are expected to address similar issues, such as the use of kernel statistics, support for diagnostic SunVTS ioctls, etc. 2. Decision & Precedence Information The project is is approved as specified in reference [1]. The committee has made one technical recommendation as listed in Appendix B below. The project may be delivered in a minor release of Solaris. 3. Interfaces The project exports the following interfaces. _____________________________________________________________________________ |___________________________________________________________________________| |Interface | Classification | Comments | |_________________________|________________________|________________________| |mac_register | Consolidation Private | (modified)| |mac_callbacks_t | Consolidation Private | (modified)| |MC_SETPROP | Consolidation Private | Section 2.1 of [3] | |MC_GETPROP | Consolidation Private | Section 2.1 of [3] | |mc_setprop | Consolidation Private | Section 2.2 of [3] | |mc_getprop | Consolidation Private | Section 2.3 of [3] | |dld_ioc_prop_val_t | Consolidation Private | Section 3.2 of [3] | |DLDIOCSETPROP | Consolidation Private | | |DLDIOCGETPROP | Consolidation Private | | |DLD_PROP_PRIVATE | Consolidation Private | | |DLD_PROP_* | Consolidation Private | Prefix for properties.| |dladm_is_wlan_prop | Consolidation Private | | |dladm_get_single_mac_stat| Consolidation Private | | |default_mtu | Committed | Property name | |flowctrl | Volatile | Property name | |ifspeed | Committed | Property name | |link_duplex | Committed | Property name | |link_up | Committed | | |adv_autoneg_cap | Committed | PSARC/2003/581 | |adv_asmpause_cap | Committed | PSARC/2003/581 | |adv_pause_cap | Committed | PSARC/2003/581 | |adv_1000fdx_cap | Committed | PSARC/2003/581 | |adv_1000hdx_cap | Committed | PSARC/2003/581 | |adv_100fdx_cap | Committed | PSARC/2003/581 | |adv_100hdx_cap | Committed | PSARC/2003/581 | |adv_10fdx_cap | Committed | PSARC/2003/581 | |adv_10hdx_cap | Committed | PSARC/2003/581 | |_________________________|________________________|________________________| PSARC/2007/429 Copyright 2007 Sun Microsystems - 3 - The project imports the following interfaces. _______________________________________________________________________ |_____________________________________________________________________| |Interface | Classification | Comments | |____________________|_______________________|________________________| |GLDv3 MAC interfaces| Consolidation Private| PSARC 2006/249 | |libdladm API | Cons. Private | PSARC 2004/471 | |____________________|_______________________|________________________| 4. Opinion 4.1. Link Capabililties The ARC discussed a desire to to have the ability to enable or disable certain kinds of offload capabilties (hardware checksum being one example). The ARC would like to see an enhancement of this kind. However, as this feature is mostly used to work around hardware/software bugs that the customer should not see, the ARC agreed that this is not in-scope for this project. 4.2. Obsolete NDD The ARC discussed two issues surrounding NDD. The first issue is that the documentation should be marked to indicate use of NDD to configure network devices is Obsolete upon integration of the project, not at some arbitrary time later. The project team agreed with this. The second issue surrounding NDD was brought forth with the idea that in the future it might be possible to make a separate case to either backport Brussels to Solaris 10, or to provide at least CLI compatibility (via some kind of wrapper around NDD) in Solaris 10, so as to facilitate remo- val of the NDD compatibility layer sooner. The ARC ulti- mately decided that this is not in scope for this project. 4.3. Crossbow The project materials make some reference to properties that are not being approved at this time, but which are antici- pated to be brought before ARC as part of the Crossbow pro- ject. Only the properties that are called out in [1] are approved as public properties at this time. 4.4. Power Management of Link Interfaces The committee discussed the problem of link power PSARC/2007/429 Copyright 2007 Sun Microsystems - 4 - management, where power management policy may result in a link advertising a different set of bits via the MII regis- ter (normally a subset) than was administratively configured via the adv_* bits. The problems surrounding this have resulted in a TCA, which is documented more fully in Appendix B. 5. Minority Opinion(s) None. 6. Advisory Information The ARC would like to see a project enhancement to configure link NIC offload capabilities proposed. One example is hardware checksum, but there are other possibilities as well. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised 1 Separate out the configuration tunable for administration of MII ethernet link bits into a separate writable knob (such as enable_100fdx_cap), and a read-only value indicat- ing the actual state of the bit as it is being exposed over the wire (i.e. adv_100fdx_cap). 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/429. 1. 20 Questions File: commitment.materials/20q.txt 2. Brussels - NIC configuration Design Specification File: commitment.materials/brussels.pdf 3. Brussels Framework Interfaces Specification File: commitment.materials/framework.pdf 4. Brussels Umbrella Overview File: commitment.materials/umbrella.txt 5. Release Notes Update PSARC/2007/429 Copyright 2007 Sun Microsystems - 5 - File: commitment.materials/relnotes-update.txt 6. bge(7d) File: commitment.materials/manpages/bge.7d 7. dladm(1m) File: commitment.materials/manpages/dladm.1m 7. ieee802.3(5) File: commitment.materials/manpages/ieee802.3.5 8. ndd(1m) File: commitment.materials/manpages/ndd.1m PSARC/2007/429 Copyright 2007 Sun Microsystems --Boundary_(ID_Dnv2T22YnE+HoAqhcDhTHg)-- From garrett@damore.org Thu Oct 18 11:35:13 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9IIZCud021026 for ; Thu, 18 Oct 2007 11:35:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9IIVjKZ012911 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 12:31:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ400B1JE4ZSY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Oct 2007 11:31:48 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ4009XIE4ZAE10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Oct 2007 11:31:47 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9IIVk7s004294 for ; Thu, 18 Oct 2007 18:31:47 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay41i.sun.com with ESMTP id BT-MMP-344193 for PSARC-ext@sun.com; Thu, 18 Oct 2007 18:31:46 +0000 (Z) Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by mms49es.sun.com with ESMTP id BT-MMP-1905301 for PSARC-ext@sun.com; Thu, 18 Oct 2007 18:31:46 +0000 (Z) Received: from occp5.ocservers.net ([216.73.122.2] [216.73.122.2]) by relay4i.sun.com with ESMTP id BT-MMP-8343003 for PSARC-ext@sun.com; Thu, 18 Oct 2007 18:31:46 +0000 (Z) Received: from [192.18.43.225] (helo=[10.7.251.172]) by occp5.ocservers.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Iia9q-0007We-9g for PSARC-ext@sun.com; Thu, 18 Oct 2007 11:31:46 -0700 Date: Thu, 18 Oct 2007 11:28:53 -0700 From: "Garrett D'Amore" Subject: PSARC 2007/429 brussels draft opinion updates To: PSARC-ext@sun.com Message-id: <4717A5E5.7020707@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - occp5.ocservers.net X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - damore.org User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 228 I've incorporated some feedback from Glenn and Jim, and renamed the files per Plocher's suggestion to opinion-draft.{ms,txt,ps}. The files are located in the case directory. Further feedback appreciated. :-) -- Garrett From sac-owner Tue Nov 13 11:40:51 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lADJeptx012363 for ; Tue, 13 Nov 2007 11:40:51 -0800 (PST) Received: from newsunmail1brm.central.sun.com (localhost [127.0.0.1]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lADJeoWK039446 for ; Tue, 13 Nov 2007 12:40:50 -0700 (MST) Received: (from noaccess@localhost) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/Submit) id lADJeo9w039445 for sac-opinion-not-2b-used-directly; Tue, 13 Nov 2007 12:40:50 -0700 (MST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lADJemET039417; Tue, 13 Nov 2007 12:40:50 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRG00D0RMO1NI00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Nov 2007 11:40:49 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRG006J7MNVEE20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Nov 2007 11:40:43 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lADJeh6l019136; Tue, 13 Nov 2007 11:40:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRG00601MBLI700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Tue, 13 Nov 2007 11:40:43 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRG003NWMNIQZC0@fe-sfbay-09.sun.com>; Tue, 13 Nov 2007 11:40:30 -0800 (PST) Date: Tue, 13 Nov 2007 11:36:14 -0800 From: "Garrett D'Amore" Subject: PSARC/2007/429 - Brussels (opinion) Sender: Garrett.Damore@sun.com To: solaris-pac-opinion@sun.com, sac-opinion@sun.com Message-id: <4739FCAE.8010203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 7990 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Brussels - enhanced network driver configura- tion via dladm Submitted by: Sowmini Varadhan File: PSARC/2007/429/opinion.ms Date: October 17, 2007 Committee: James D. Carlson (opinion written by Garrett D'Amore), Kais Belgaied, Glenn Skinner, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Brussels is a project to enhance and standardize network interface configuration through properties. It extends the GLDv3 driver interface to allow drivers to expose device properties to Solaris, provides normalized access to these properties via the dladm(1m) command line application, and provides for persistence of said configuration across reboots. A compatibility layer for ndd(1m) is included. 2. Decision & Precedence Information The project is is approved as specified in reference [1]. The members have made one technical recommendation as listed in Appendix B below. The project may be delivered in a minor release of Solaris. 3. Interfaces PSARC/2007/429 Copyright 2007 Sun Microsystems - 2 - The project exports the following interfaces. _______________________________________________________________________ | Interfaces Exported | |_________________________|__________________|________________________| |Interface | Classification | Comments | |_________________________|__________________|________________________| |mac_register | Consol. Private | (modified)| |mac_callbacks_t | Consol. Private | (modified)| |MC_SETPROP | Consol. Private | Sect. 2.1 of [3] | |MC_GETPROP | Consol. Private | Sect. 2.1 of [3] | |mc_setprop | Consol. Private | Sect. 2.2 of [3] | |mc_getprop | Consol. Private | Sect. 2.3 of [3] | |dld_ioc_prop_val_t | Consol. Private | Sect. 3.2 of [3] | |DLDIOCSETPROP | Consol. Private | | |DLDIOCGETPROP | Consol. Private | | |DLD_PROP_PRIVATE | Consol. Private | | |DLD_PROP_* | Consol. Private | Property prefix. | |dladm_is_wlan_prop | Consol. Private | | |dladm_get_single_mac_stat| Consol. Private | | |default_mtu | Committed | Property name | |flowctrl | Volatile | Property name | |ifspeed | Committed | Property name | |link_duplex | Committed | Property name | |link_up | Committed | | |adv_autoneg_cap | Committed | PSARC/2003/581 | |adv_asmpause_cap | Committed | PSARC/2003/581 | |adv_pause_cap | Committed | PSARC/2003/581 | |adv_1000fdx_cap | Committed | PSARC/2003/581 | |adv_1000hdx_cap | Committed | PSARC/2003/581 | |adv_100fdx_cap | Committed | PSARC/2003/581 | |adv_100hdx_cap | Committed | PSARC/2003/581 | |adv_10fdx_cap | Committed | PSARC/2003/581 | |adv_10hdx_cap | Committed | PSARC/2003/581 | |ndd on data-link drivers | Obsolete | Replace with dladm | |_________________________|__________________|________________________| The project imports the following interfaces. _______________________________________________________________________ | Interfaces Imported | |____________________|_______________________|________________________| |Interface | Classification | Comments | |____________________|_______________________|________________________| |GLDv3 MAC interfaces| Consolidation Private| PSARC 2006/249 | |libdladm API | Consol. Private | PSARC 2004/471 | |mac_maxsdu_update | Consol. Private | Clearview IP Tunneling| |____________________|_______________________|________________________| 4. Opinion PSARC/2007/429 Copyright 2007 Sun Microsystems - 3 - 4.1. Link Capabililties Several members discussed a desire to to have the ability to enable or disable offload capabilties (hardware checksum being one example). However, as this feature is mostly used to work around bugs that the customer should not see, it was agreed that this is not in-scope for this project. 4.2. Obsolete NDD The members discussed two issues surrounding NDD. First, the documentation should be changed to indicate use of NDD to configure network devices is Obsolete. The project team agreed with this correction. Second is the idea that in the future it might be possible to make a separate case to either backport Brussels to Solaris 10, or to provide at least CLI compatibility (via some kind of wrapper around NDD) in Solaris 10, so as to facilitate removal of the NDD compatibility layer sooner. The members ultimately decided that this is not in scope for this project. 4.3. Crossbow The project materials refer to properties that are not being approved at this time, but that will will be reviewed as part of the Crossbow project. Only the properties that are called out in [1] are approved as public properties at this time. 4.4. Power Management of Link Interfaces One participant discussed the problem of link power manage- ment, where power management policy may result in a link advertising a different set of bits via the MII register (normally a subset) than was administratively configured via the adv_* bits. The problems surrounding this have resulted in a technical change advised, which is documented more fully in Appendix B. 5. Minority Opinion(s) None. 6. Advisory Information The members would like to see a project enhancement to con- figure link NIC offload capabilities proposed. One example PSARC/2007/429 Copyright 2007 Sun Microsystems - 4 - is hardware checksum, but there are other possibilities as well. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised 1 Separate out the configuration tunable for administration of MII ethernet link bits into a separate writable knob (such as enable_100fdx_cap), and a read-only value indicat- ing the actual state of the bit as it is being exposed over the wire (i.e. adv_100fdx_cap). 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/429. 1. 20 Questions File: commitment.materials/20q.txt 2. Brussels - NIC configuration Design Specification File: commitment.materials/brussels.pdf 3. Brussels Framework Interfaces Specification File: commitment.materials/framework.pdf 4. Brussels Umbrella Overview File: commitment.materials/umbrella.txt 5. Release Notes Update File: commitment.materials/relnotes-update.txt 6. bge(7d) File: commitment.materials/manpages/bge.7d 7. dladm(1m) File: commitment.materials/manpages/dladm.1m 7. ieee802.3(5) File: commitment.materials/manpages/ieee802.3.5 8. ndd(1m) File: commitment.materials/manpages/ndd.1m PSARC/2007/429 Copyright 2007 Sun Microsystems