From Sebastien.Roy@Sun.COM Wed Sep 12 09:12:08 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 l8CGC7Zr025454 for ; Wed, 12 Sep 2007 09:12:07 -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 l8CG8cQ2039204 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Sep 2007 10:08:38 -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 <0JO900J05JJEA000@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 09:09:14 -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 <0JO900F4WJJDG570@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 09:09:13 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8CG9Dne018482 for ; Wed, 12 Sep 2007 16:09:13 +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 <0JO900G01J7S0700@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 10:09:13 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO900GW8JJCGL01@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 10:09:13 -0600 (MDT) Date: Wed, 12 Sep 2007 12:09:12 -0400 From: Sebastien Roy Subject: 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification Sender: Sebastien.Roy@Sun.COM To: psarc-ext@Sun.COM Cc: clearview-discuss Message-id: <46E80F28.2080506@sun.com> Organization: Sun Microsystems 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/20070814) Status: RO Content-Length: 11203 I'm sponsoring this fast-track request for Cathy Zhou and the Clearview team. The timer is set for 09/19/2007. Note that this case addresses some technical issues raised during the review of 2007/484, which was itself closed withdrawn. Addendum for Clearview Vanity Naming and Nemo Unification Release binding: patch Problem area ============ Among various goals of the Clearview Vanity naming and Nemo unification project (PSARC 2006/499), one important goal is to provide VLAN support for all Ethernet network devices. There is one potential problem when deploying VLAN network over certain legacy devices: such legacy devices simply assume that the maximum payload size they can handle is 1500 bytes, and if they receive (or are requested to send) any payload whose size is greater than it, the driver will silently drop the packets. As a result, the maximum packet size such devices can handle is 1514 bytes (1500 bytes of payload and 14 bytes of Ethernet header), and it does not leave any room for extra 4 bytes of VLAN tags. In order to make the VLAN deployment successful, in such circumstance, we require administrators to create VLANs explicitly using the "-f" option, and they would also have to carefully configure the MTU of each node on the VLAN to be lower. To enforce that requirement, a mechanism will be needed to query each Ethernet network device whether such problem exists, i.e., whether the device can handle extra 4 bytes of payload for VLAN tags besides the maximum SDU size that is reported in DL_INFO_ACK. Further, although some legacy drivers do not have the MTU issue mentioned above, they still can not support VLAN PPA access themselves. Specifically, such drivers do not recognize the semantics related to the VLAN PPA attachment (A DL_ATTACH_REQ whose PPA number is calculated by multiplying the VLAN ID by 1000 and adding the hardware PPA). For those legacy drivers, a shim layer (softmac) will have to process such attachment request on their behalves, and encode/demultiplex VLAN packets for them. On the other hand, for legacy drivers who support VLAN PPA access themselves, all control and data messages (including the VLAN PPA DL_ATTACH_REQ message) will be directly exchanged between the upper layer DLPI clients (such as IP) and the legacy drivers. This is especially important for performance reasons. As a result, a mechanism will be also needed to tell whether VLAN PPA access is supported for specific network devices. In summary, a mechanism is needed to query specific network device whether it: - leaves extra room in the payload section besides the maximum SDU size reported in DL_INFO_ACK. The extra room (margin) can be used to provide additional headers. - supports the VLAN PPA access. Proposal overview ================= * The issues with the old proposal - DLIOCVLANINFO ioctl A DLIOCVLANINFO ioctl was originally proposed by PSARC 2006/499 to report device's "VLAN capability". With this ioctl, we would be able to know whether or not a DLPI provider is capable of handling extra 4 bytes for VLAN tags (see more in PSARC 2006/499). Although this proposal is sufficient for general VLAN support, it can not satisify similiar needs from other features that involves packets of uncommon size (e.g., nested VLAN, RBridges). It is because the DLIOCVLANINFO does not report the exact "margin" size one device can tolerate. * DLIOCMARGININFO ioctl To address issues of the old proposal, we would like to introduce a new DLIOCMARGININFO ioctl and obsolete the old DLIOCVLANINFO ioctl. Note that the new ioctl is no longer specific to Ethernet DLPI providers. Specifically, the DLIOCMARGININFO ioctl takes a 32 bit integer argument which is used for each network DLPI provider to return the margin size it supports. For example, if an Ethernet DLPI provider cannot handle packets whose payload section are not greater than 1522 bytes, and the maximum SDU size it reports through DL_INFO_ACK is 1500. Then the margin size of this DLPI provider is 22 (1522-1500), and the maximum packets size it can handle is 1536 (1522+14, where 14 is the Ethernet header). Commitment level: Committed * GLDv3 changes ** m_margin field in mac_register_t A new m_margin field will be added to the mac_register_t structure. GLDv3 MACs that can handle non-zero margin size will need to fill in the m_margin field before it registers to the GLDv3 framework. ** mi_margin field in mac_info_t A new mi_margin field will be added to the mac_info_t structure. The GLDv3 framework will fill in this field for each MAC once it registers to the GLDv3 framework. Therefore, other modules will be able to know specific MAC's margin size information by accessing the value of mi_margin. For example, the dls module will be able to determine whether VLANs can be created over a specific MAC without specifying "-f", by comparing mi_margin with 4 (extra size for VLAN tags). The mi_margin value will also be reported in the acknowledgment of the DLIOCMARGININFO ioctl. ** MAC_CAPAB_NO_NATIVEVLAN A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the GLDv3 framework to indicate that a specific MAC cannot support VLAN PPA access by itself. Commitment level: Consolidation Private * GLDv2 changes ** gldm_margin field in gld_mac_info_t A new gldm_margin field will be added to the gld_mac_info_t structure (a previous uint32_t reserved field will be used). GLDv2 MACs that can handle non-zero margin size will need to fill in the gldm_margin field before it registers to the GLDv2 framework. A GLDv2 Ethernet device which registers its gldm_send_tagged() callback will be considered as capable of VLAN PPA access, and its margin will be corrected as 4 if the registered gldm_margin value is 0. The GLDv2 MAC's margin size will then be reported in the acknowledgment of the DLIOCMARGININFO ioctl. Commitment level: Committed Deliverables ============ The deliverables of this case will include the header files that define the above interfaces (specifically, , and ), and the changes needed in the GLDv2 and GLDv3 framework. The logic that makes use of these interfaces for general VLAN support will be integrated separately as part of PSARC 2006/499. We will also coordinate with other teams to report the correct margin value for each driver, to avoid potential problems caused by integration of PSARC 2006/499. Specifically, each DLPI driver (firstly ce) will be changed to acknowledge the DLIOCMARGININFO ioctl with the correct margin value; each GLDv2 and GLDv3 driver will need to be updated to register its margin value. Before going through every GLDv2/GLDv3 drivers, we will first change each GLDv3 Ethernet driver in ON to register its m_margin as 4, to allow backward compatibility of VLAN support. For the same reason, we will also change GLDv2 drivers that have their gldm_send_tagged() callbacks implemented to register their margin value as 4. Documentation Impact ==================== * dlpi(7p) - Committed $ diff -u /tmp/dlpi.man /tmp/dlpi.man.new --- /tmp/dlpi.man Mon Sep 3 22:05:58 2007 +++ /tmp/dlpi.man.new Mon Sep 3 22:24:29 2007 @@ -340,7 +340,23 @@ erate responses with dl_mac_type set to the native DLPI type. + Margin Size + The margin size represents the extra payload size a DLPI + provider can handle, aside from the maximum SDU size + reported in DL_INFO_ACK. For example, assuming an Ethernet + DLPI provider reports its maximum SDU size as 1500, but + it leaves room for extra payload, so that the maximum payload + it allows to send or pass up is 1522, then the margin size + of this specific DLPI provider is 22. Margin can be used + to carry additional headers. + + DLIOCMARGININFO ioctl is used to query specific DLPI provider + of its margin size. In particular, this ioctl takes a 32 + bit integer argument which is used for each DLPI provider + to return its margin size. + DL_ETHER-SPECIFIC DLPI SEMANTICS VLAN Support VLAN PPA Access * gld_mac_info(9S) - Committed $ diff -u /tmp/gld_mac_info.man /tmp/gld_mac_info.man.new --- /tmp/gld_mac_info.man Mon Sep 3 22:27:41 2007 +++ /tmp/gld_mac_info.man.new Mon Sep 3 22:44:31 2007 @@ -50,6 +50,8 @@ /* accepted by driver */ uint32_t gldm_maxpkt; /* Maximum packet size */ /* accepted by driver */ + uint32_t gldm_margin; /* Margin size */ + /* accepted by driver */ uint32_t gldm_addrlen; /* Physical address */ /* length */ int32_t gldm_saplen; /* SAP length for */ @@ -177,19 +179,22 @@ gldm_minpkt Minimum Service Data Unit size - - the minimum packet size, not - including the MAC header, that the - device will transmit. This can be + the minimum size of SDU (service data + unit) that the device will transmit. + SDU represents the payload data sent + by the upper layer, which does not + includes the MAC header. gldm_minpkt + can be zero if the device-specific driver can handle any required padding. gldm_maxpkt Maximum Service Data Unit size - - the maximum size of packet, not - including the MAC header, that can - be transmitted by the device. For + the maximum size of SDU that can be + transmitted by the device. For Ethernet, this number is 1500. + gldm_margin The margin size that can be handled + by the device. See dlpi(7P). SunOS 5.11 Last change: 7 June 2004 3 References ========== [1] Vanity Naming and Nemo Unification High-Level Design Specification http://sac.sfbay/PSARC/2006/499/commitment.materials/uv-design.pdf From Kais.Belgaied@sun.com Fri Sep 14 12:24:14 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 l8EJOEKn004052 for ; Fri, 14 Sep 2007 12:24:14 -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 l8EJKbQu061477; Fri, 14 Sep 2007 13:20:41 -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 <0JOD00A0RHRJA200@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Sep 2007 12:21:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOD003QMHRI2G60@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Sep 2007 12:21:18 -0700 (PDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8EJLHkp961500; Fri, 14 Sep 2007 12:21:17 -0700 (PDT) Date: Fri, 14 Sep 2007 12:21:17 -0700 From: Kais Belgaied Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46E80F28.2080506@sun.com> To: Sebastien Roy Cc: psarc-ext@sun.com, clearview-discuss Reply-to: Kais.Belgaied@sun.com Message-id: <46EADF2D.6090302@Sun.COM> 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 References: <46E80F28.2080506@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) Status: RO Content-Length: 549 > ** MAC_CAPAB_NO_NATIVEVLAN > > A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the > GLDv3 framework to indicate that a specific MAC cannot support > VLAN PPA access by itself. > this sounds a little upside-down. A driver has to advertise a negative capability, essentially saying "Hey, I can't handle this feature" as opposed to the more intuitive approach: drivers that can handle native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), and those who don't do not. Any reason for this choice? Kais. From Garrett.Damore@sun.com Fri Sep 14 12:58:04 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 l8EJw3ZN004612 for ; Fri, 14 Sep 2007 12:58:04 -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 l8EJt8Ct010310 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 15 Sep 2007 03:55:11 +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 <0JOD00B19JBVYO00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Sep 2007 12:55:07 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOD003SQJBR2E70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Sep 2007 12:55:03 -0700 (PDT) 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 l8EJt3HY013712 for ; Fri, 14 Sep 2007 12:55:03 -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 <0JOD00I01J02KA00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Sep 2007 12:55:03 -0700 (PDT) Received: from [192.168.251.21] ([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 <0JOD00988JBQT360@fe-sfbay-09.sun.com>; Fri, 14 Sep 2007 12:55:03 -0700 (PDT) Date: Fri, 14 Sep 2007 12:50:01 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EADF2D.6090302@Sun.COM> Sender: Garrett.Damore@sun.com To: Kais.Belgaied@sun.com Cc: Sebastien Roy , psarc-ext@sun.com, clearview-discuss Message-id: <46EAE5E9.3080202@sun.com> Organization: Sun Microsystems 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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 1146 Kais Belgaied wrote: > >> ** MAC_CAPAB_NO_NATIVEVLAN >> >> A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the >> GLDv3 framework to indicate that a specific MAC cannot support >> VLAN PPA access by itself. >> > > this sounds a little upside-down. > A driver has to advertise a negative capability, essentially saying > "Hey, I can't handle this feature" > as opposed to the more intuitive approach: drivers that can handle > native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), > and those who don't do not. > Any reason for this choice? It sounds really odd-ball to me, too. Plus, it would require touching all the existing GLDv3 driver. Yech. Far, far better to add MAC_CAPAB_NATIVEVLAN (or even better, MAC_CAPAB_VLAN_PPA, which more accurately describes the feature.) Of course, IMO, this is really, really weird, because *today* Nemo drivers are totally ignorant of PPAs, as such. I'm not sure how a Nemo driver with this feature would act... what causes a VLAN PPA attach to happen. But there is lot about clearview that I don't completely understand. -- Garrett > > Kais. From Cathy.Zhou@Sun.COM Sun Sep 16 20:58:45 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 l8H3wi9e013710 for ; Sun, 16 Sep 2007 20:58:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8H3tmhl029042 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Sep 2007 04:55:48 +0100 (BST) 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 <0JOH00L05UWZ6A00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:55:47 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOH00KLLUWXL1D0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:55:46 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8H3tjNa003729 for ; Mon, 17 Sep 2007 03:55:45 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JOH00I01UQTN700@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 11:55:45 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JOH002XQUWT5MV4@mail-apac.sun.com>; Mon, 17 Sep 2007 11:55:43 +0800 (SGT) Date: Mon, 17 Sep 2007 11:55:37 +0800 From: Cathy Zhou Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EAE5E9.3080202@sun.com> Sender: Cathy.Zhou@Sun.COM To: "Garrett D'Amore" Cc: Kais.Belgaied@Sun.COM, psarc-ext@Sun.COM, clearview-discuss , Sebastien Roy Message-id: <46EDFAB9.1080009@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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 1786 Garrett D'Amore wrote: > Kais Belgaied wrote: >>> ** MAC_CAPAB_NO_NATIVEVLAN >>> >>> A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the >>> GLDv3 framework to indicate that a specific MAC cannot support >>> VLAN PPA access by itself. >>> >> this sounds a little upside-down. >> A driver has to advertise a negative capability, essentially saying >> "Hey, I can't handle this feature" >> as opposed to the more intuitive approach: drivers that can handle >> native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), >> and those who don't do not. >> Any reason for this choice? > > It sounds really odd-ball to me, too. Plus, it would require touching > all the existing GLDv3 driver. No. We introduce MAC_CAPAB_NO_NATIVEVLAN exactly for the reason that we do not want to touch most of the GLDv3 driver. MAC_CAPAB_NO_NATIVEVLAN means that this driver cannot handle VLAN PPA access itself (therefore, it might also implies that this driver does not handle the hardware checksum for VLAN packets). Existing GLDv3 drivers should *not* advertise this capability, except the aggr driver, which might based on the underlying aggregated drivers. - Cathy Yech. Far, far better to add > MAC_CAPAB_NATIVEVLAN (or even better, MAC_CAPAB_VLAN_PPA, which more > accurately describes the feature.) > > Of course, IMO, this is really, really weird, because *today* Nemo > drivers are totally ignorant of PPAs, as such. I'm not sure how a Nemo > driver with this feature would act... what causes a VLAN PPA attach to > happen. But there is lot about clearview that I don't completely > understand. > > -- Garrett >> Kais. > > > _________________________________ > clearview-discuss mailing list > clearview-discuss@opensolaris.org From Garrett.Damore@sun.com Sun Sep 16 21:37:38 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 l8H4bb5i013884 for ; Sun, 16 Sep 2007 21:37:38 -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 l8H4YZPL000955 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Sep 2007 12:34:41 +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 <0JOH00G03WPS3M00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:34:41 -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 <0JOH00BIEWPS31E0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:34:40 -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 l8H4YeJm011473 for ; Sun, 16 Sep 2007 21:34:40 -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 <0JOH00L01WID6T00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:34:40 -0700 (PDT) Received: from [192.168.251.21] ([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 <0JOH00HT7WPRCAC0@fe-sfbay-10.sun.com>; Sun, 16 Sep 2007 21:34:40 -0700 (PDT) Date: Sun, 16 Sep 2007 21:29:31 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EDFAB9.1080009@sun.com> Sender: Garrett.Damore@sun.com To: Cathy Zhou Cc: Kais.Belgaied@sun.com, psarc-ext@sun.com, clearview-discuss , Sebastien Roy Message-id: <46EE02AB.6090101@sun.com> Organization: Sun Microsystems 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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 3914 Cathy Zhou wrote: > Garrett D'Amore wrote: >> Kais Belgaied wrote: >>>> ** MAC_CAPAB_NO_NATIVEVLAN >>>> >>>> A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the >>>> GLDv3 framework to indicate that a specific MAC cannot support >>>> VLAN PPA access by itself. >>>> >>> this sounds a little upside-down. >>> A driver has to advertise a negative capability, essentially saying >>> "Hey, I can't handle this feature" >>> as opposed to the more intuitive approach: drivers that can handle >>> native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), >>> and those who don't do not. >>> Any reason for this choice? >> >> It sounds really odd-ball to me, too. Plus, it would require >> touching all the existing GLDv3 driver. > > No. We introduce MAC_CAPAB_NO_NATIVEVLAN exactly for the reason that > we do not want to touch most of the GLDv3 driver. > MAC_CAPAB_NO_NATIVEVLAN means that this driver cannot handle VLAN PPA > access itself (therefore, it might also implies that this driver does > not handle the hardware checksum for VLAN packets). Existing GLDv3 > drivers should *not* advertise this capability, except the aggr > driver, which might based on the underlying aggregated drivers. > > - Cathy > > Yech. Far, far better to add >> MAC_CAPAB_NATIVEVLAN (or even better, MAC_CAPAB_VLAN_PPA, which more >> accurately describes the feature.) >> >> Of course, IMO, this is really, really weird, because *today* Nemo >> drivers are totally ignorant of PPAs, as such. I'm not sure how a >> Nemo driver with this feature would act... what causes a VLAN PPA >> attach to happen. But there is lot about clearview that I don't >> completely understand. Okay, I'm confused. GLDv3 drivers do *not* handle PPAs at all. They are totally ignorant of the DLPI, and even of VLANs... the only things a GLDv3 driver knows directly about (normally) is a) instance numbers... each driver normally knows that it has a common instance number (which ultimately gets translated to the PPA for untagged packets, but that is incidental) b) tagged packets (which might be for VLANs, or might be for QoS tagging) are bigger. All GLDv3 drivers *today* can cope with the extra 4 bytes required for tagging. What exactly does MAC_CAPAB_NO_NATIVELAN convey? Put another way, if *all* current GLDv3 NICs qualify as having a "native vlan support" (which right now most just support a bigger packet size), then it is, IMO, silly to try to emulate above them. In otherwords, what will UV do with devices that have MAC_CAPAB_NO_NATIVEVLAN? Will they get "something special" (some different kind of VLAN emulation layer?) Why? I think it makes far far more sense for UV (and not just UV, but Nemo) to just have MAC_CAPAB_NO_TAGGING which covers all legacy drivers that lack full support for tag insertion. This means that those drivers won't support VLANs at all (and I don't think your -F workaround is a good idea, because it will be a call generator and because I think such hardware is now so old to be uninteresting, especially given the readily available options... the only common PCI legacy NICs I know with that problem are 3Com elxl, which is, AFAIK, due to be EOL'd. All the "interesting" legacy NICs (which is, IIUC, 90% for ce at this point, because most of the others are already converted, excepting perhaps a few rarer 3rd party NICs) are already converted to GLD. (There are mostly uninteresting ones, like pcelx, which hasn't been on the market for a very long time....) I'll convert the rest of the NIC drivers in ON as soon as I have a way to express the equivalent of MAC_CAPAB_NO_TAGGING. Then only the 3rd party ones... and ce and gem... will matter. (And I'll probably do gem soon as well, once I get access to the hardware... Its almost identical to the work I've already done for eri. :-) -- Garrett From peter.memishian@sun.com Sun Sep 16 21:42: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 l8H4gsbC013917 for ; Sun, 16 Sep 2007 21:42:55 -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 l8H4dnI7003349; Mon, 17 Sep 2007 12:39:53 +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 <0JOH00009WYEM700@brm-avmta-1.central.sun.com>; Sun, 16 Sep 2007 22:39:50 -0600 (MDT) Received: from dhcp-cbjs05-219-93.PRC.Sun.COM ([129.158.219.217]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOH00KEAWYBL1F0@brm-avmta-1.central.sun.com>; Sun, 16 Sep 2007 22:39:48 -0600 (MDT) Received: from dhcp-cbjs05-219-93.PRC.Sun.COM (localhost [127.0.0.1]) by dhcp-cbjs05-219-93.PRC.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l8H4ddEV002134; Mon, 17 Sep 2007 12:39:39 +0800 (CST) Received: (from meem@localhost) by dhcp-cbjs05-219-93.PRC.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8H4dc2L002131; Mon, 17 Sep 2007 12:39:38 +0800 (CST) Date: Mon, 17 Sep 2007 12:39:38 +0800 From: Peter Memishian Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EE02AB.6090101@sun.com> To: "Garrett D'Amore" Cc: Cathy Zhou , Kais.Belgaied@sun.com, clearview-discuss , Sebastien Roy , psarc-ext@sun.com Reply-to: peter.memishian@sun.com Message-id: <18158.1290.455823.164139@dhcp-cbjs05-219-93.PRC.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> X-Authentication-warning: dhcp-cbjs05-219-93.PRC.Sun.COM: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 366 > All the "interesting" legacy NICs (which is, IIUC, 90% for ce at this > point, because most of the others are already converted, excepting > perhaps a few rarer 3rd party NICs) are already converted to GLD. Keep in mind that our architecture needs to consider Solaris 10, not just Nevada. Most Solaris 10 networking drivers are not GLDv3-based. -- meem From Garrett.Damore@sun.com Sun Sep 16 21:59:09 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 l8H4x8pa014288 for ; Sun, 16 Sep 2007 21:59:08 -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 l8H4u5H4012187 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Sep 2007 12:56: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 <0JOH00I03XPMDF00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:56:10 -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 <0JOH00G3OXPLTX30@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:56:10 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l8H4u99W012117 for ; Sun, 16 Sep 2007 21:56:09 -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 <0JOH00L01XENV300@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 21:56:09 -0700 (PDT) Received: from [192.168.251.21] ([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 <0JOH00I3FXPJC3C0@fe-sfbay-09.sun.com>; Sun, 16 Sep 2007 21:56:08 -0700 (PDT) Date: Sun, 16 Sep 2007 21:51:01 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <18158.1290.455823.164139@dhcp-cbjs05-219-93.PRC.Sun.COM> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: Cathy Zhou , Kais.Belgaied@sun.com, clearview-discuss , Sebastien Roy , psarc-ext@sun.com Message-id: <46EE07B5.3090706@sun.com> Organization: Sun Microsystems 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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> <18158.1290.455823.164139@dhcp-cbjs05-219-93.PRC.Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 2369 Peter Memishian wrote: > > All the "interesting" legacy NICs (which is, IIUC, 90% for ce at this > > point, because most of the others are already converted, excepting > > perhaps a few rarer 3rd party NICs) are already converted to GLD. > > Keep in mind that our architecture needs to consider Solaris 10, not just > Nevada. Most Solaris 10 networking drivers are not GLDv3-based. > Good point. I didn't realize that UV was targeting S10. However, I wonder what the expense of this effort is, compared to the effort of backporting the GLDv3 work. All of the GLDv2 NICs that have been converted should be able to be backported without any customer or ARC impact. (Ok, there might be tiny impact related to a few kstats, because GLDv2 and v3 keep track of "driver private" statistics differently... but that's such a minor nit and undocumented that it can probably get patch binding trivially.) That takes care of *all* the x86 NICs, and even one of the SPARC ones (dmfe). The bigger question is the DLPI nics. Of those: * eri and hme can be backported, but there is the "ndd" problem. Fixable with a hack in the "ndd" program itself to cope/workaround administration using style 2 instead of style 1 nodes. Non-zero ARC impact, but fairly small engineering impact. * qfe. This has the ndd problem, but also has the additional problem of dealing with Sun Trunking, which is totally incompatible with GLDv3 aggregation. (Btw, how does UV plan to deal with this problem? What are the expected interactions?) We cannot support Sun Trunking in any qfe backport. This may be a total stopper. * ge. This would have the same problems as qfe, except that the *Nevada* conversion hasn't been done yet. It *could* be done fairly easily... only about a week of engineering effort is required. (Possibly quite a bit less.) * ce. This is the *big* problem. And I suspect UV is going to have to cope with it somehow. It has all the problems of qfe and ge, plus a bunch of tuning hints, and other things that are going to bite people in the arse. And its a political minefield. Interestingly enough, there is talk of Joyce Yu doing work to make it work with IP instances without UV. I don't know what the precise details are, though. You should talk to Erik, as I think he is involved. -- Garrett > -- > meem > From Cathy.Zhou@sun.com Sun Sep 16 22:10:09 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 l8H5A81U014394 for ; Sun, 16 Sep 2007 22:10:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8H57ABW028854 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Sep 2007 06:07:12 +0100 (BST) 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 <0JOH00209Y7YIS00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 23:07:10 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOH001ACY7XXJ00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 23:07:10 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8H578Y8007432 for ; Mon, 17 Sep 2007 05:07:08 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JOH00L01Y41ML00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 13:07:08 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JOH002TNY7TS6PB@mail-apac.sun.com>; Mon, 17 Sep 2007 13:07:07 +0800 (SGT) Date: Mon, 17 Sep 2007 13:07:01 +0800 From: Cathy Zhou Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EE02AB.6090101@sun.com> Sender: Cathy.Zhou@sun.com To: "Garrett D'Amore" Cc: Kais.Belgaied@sun.com, psarc-ext@sun.com, clearview-discuss , Sebastien Roy Message-id: <46EE0B75.7030902@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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 4527 Garrett D'Amore wrote: > Cathy Zhou wrote: >> Garrett D'Amore wrote: >>> Kais Belgaied wrote: >>>>> ** MAC_CAPAB_NO_NATIVEVLAN >>>>> >>>>> A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the >>>>> GLDv3 framework to indicate that a specific MAC cannot support >>>>> VLAN PPA access by itself. >>>>> >>>> this sounds a little upside-down. >>>> A driver has to advertise a negative capability, essentially saying >>>> "Hey, I can't handle this feature" >>>> as opposed to the more intuitive approach: drivers that can handle >>>> native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), >>>> and those who don't do not. >>>> Any reason for this choice? >>> >>> It sounds really odd-ball to me, too. Plus, it would require >>> touching all the existing GLDv3 driver. >> >> No. We introduce MAC_CAPAB_NO_NATIVEVLAN exactly for the reason that >> we do not want to touch most of the GLDv3 driver. >> MAC_CAPAB_NO_NATIVEVLAN means that this driver cannot handle VLAN PPA >> access itself (therefore, it might also implies that this driver does >> not handle the hardware checksum for VLAN packets). Existing GLDv3 >> drivers should *not* advertise this capability, except the aggr >> driver, which might based on the underlying aggregated drivers. >> >> - Cathy >> >> Yech. Far, far better to add >>> MAC_CAPAB_NATIVEVLAN (or even better, MAC_CAPAB_VLAN_PPA, which more >>> accurately describes the feature.) >>> >>> Of course, IMO, this is really, really weird, because *today* Nemo >>> drivers are totally ignorant of PPAs, as such. I'm not sure how a >>> Nemo driver with this feature would act... what causes a VLAN PPA >>> attach to happen. But there is lot about clearview that I don't >>> completely understand. > > Okay, I'm confused. > > GLDv3 drivers do *not* handle PPAs at all. They are totally ignorant of > the DLPI, and even of VLANs... the only things a GLDv3 driver knows > directly about (normally) is > a) instance numbers... each driver normally knows that it has a common > instance number (which ultimately gets translated to the PPA for > untagged packets, but that is incidental) > > b) tagged packets (which might be for VLANs, or might be for QoS > tagging) are bigger. All GLDv3 drivers *today* can cope with the extra > 4 bytes required for tagging. > > What exactly does MAC_CAPAB_NO_NATIVELAN convey? Put another way, if > *all* current GLDv3 NICs qualify as having a "native vlan support" > (which right now most just support a bigger packet size), then it is, > IMO, silly to try to emulate above them. > > In otherwords, what will UV do with devices that have > MAC_CAPAB_NO_NATIVEVLAN? Will they get "something special" (some > different kind of VLAN emulation layer?) Why? > We handle MAC_CAPAB_NO_NATIVEVLAN differently in two places: a. If mac_open() is for a VLAN PPA accessed stream, and the underlying MAC supports MAC_CAPAB_PERSTREAM, but *not* MAC_CAPAB_NO_NATIVEVLAN, we can open the underlying driver directly using its native VLAN PPA access. b. If the MAC is MAC_CAPAB_NO_NATIVEVLAN, then do not advertise its HW_CKSUM capability on VLAN streams even the MAC claims it is capable of doing HW CKSUM. - Cathy > I think it makes far far more sense for UV (and not just UV, but Nemo) > to just have > > MAC_CAPAB_NO_TAGGING > > which covers all legacy drivers that lack full support for tag > insertion. > This means that those drivers won't support VLANs at all > (and I don't think your -F workaround is a good idea, because it will be > a call generator and because I think such hardware is now so old to be > uninteresting, especially given the readily available options... the > only common PCI legacy NICs I know with that problem are 3Com elxl, > which is, AFAIK, due to be EOL'd. > > All the "interesting" legacy NICs (which is, IIUC, 90% for ce at this > point, because most of the others are already converted, excepting > perhaps a few rarer 3rd party NICs) are already converted to GLD. > (There are mostly uninteresting ones, like pcelx, which hasn't been on > the market for a very long time....) I'll convert the rest of the NIC > drivers in ON as soon as I have a way to express the equivalent of > MAC_CAPAB_NO_TAGGING. Then only the 3rd party ones... and ce and gem... > will matter. (And I'll probably do gem soon as well, once I get access > to the hardware... Its almost identical to the work I've already done > for eri. :-) > > -- Garrett > > From peter.memishian@sun.com Sun Sep 16 23:25:09 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 l8H6P87u015142 for ; Sun, 16 Sep 2007 23:25:08 -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 l8H6M5GY001961; Mon, 17 Sep 2007 07:22:06 +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 <0JOI006051OTGV00@nwk-avmta-2.sfbay.sun.com>; Sun, 16 Sep 2007 23:22:05 -0700 (PDT) Received: from dhcp-cbjs05-219-93.PRC.Sun.COM ([129.158.219.217]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOI0021K1OQJ830@nwk-avmta-2.sfbay.sun.com>; Sun, 16 Sep 2007 23:22:03 -0700 (PDT) Received: from dhcp-cbjs05-219-93.PRC.Sun.COM (localhost [127.0.0.1]) by dhcp-cbjs05-219-93.PRC.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l8H6Lr8a002326; Mon, 17 Sep 2007 14:21:53 +0800 (CST) Received: (from meem@localhost) by dhcp-cbjs05-219-93.PRC.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8H6Lrbi002323; Mon, 17 Sep 2007 14:21:53 +0800 (CST) Date: Mon, 17 Sep 2007 14:21:53 +0800 From: Peter Memishian Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EE07B5.3090706@sun.com> To: "Garrett D'Amore" Cc: peter.memishian@sun.com, Cathy Zhou , Kais.Belgaied@sun.com, clearview-discuss , Sebastien Roy , psarc-ext@sun.com Reply-to: peter.memishian@sun.com Message-id: <18158.7425.150756.959634@dhcp-cbjs05-219-93.PRC.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> <18158.1290.455823.164139@dhcp-cbjs05-219-93.PRC.Sun.COM> <46EE07B5.3090706@sun.com> X-Authentication-warning: dhcp-cbjs05-219-93.PRC.Sun.COM: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 791 > > Keep in mind that our architecture needs to consider Solaris 10, not just > > Nevada. Most Solaris 10 networking drivers are not GLDv3-based. > > > Good point. I didn't realize that UV was targeting S10. > > However, I wonder what the expense of this effort is, compared to the > effort of backporting the GLDv3 work. There are other dimensions besides GLDv3 driver support -- e.g., Crossbow will make use of the Vanity Naming feature to provide administratively chosen names for VNICs. Also if we didn't backport UV, the GLDv3 codebases for S10 and Nevada would become significantly different, which also greatly impacts Crossbow (since the Crossbow S10 backport would become more of a reimplementation than a backport -- with commensurate impact on testing). -- meem From peter.memishian@sun.com Sun Sep 16 23:27: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 l8H6R6L4015156 for ; Sun, 16 Sep 2007 23:27:07 -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 l8H6NP9M059489; Mon, 17 Sep 2007 00:23:25 -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 <0JOI004011S7AC00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 16 Sep 2007 23:24:07 -0700 (PDT) Received: from dhcp-cbjs05-219-93.PRC.Sun.COM ([129.158.219.217]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOI000VF1S5GM40@nwk-avmta-1.sfbay.Sun.COM>; Sun, 16 Sep 2007 23:24:06 -0700 (PDT) Received: from dhcp-cbjs05-219-93.PRC.Sun.COM (localhost [127.0.0.1]) by dhcp-cbjs05-219-93.PRC.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l8H6NuDR002336; Mon, 17 Sep 2007 14:23:56 +0800 (CST) Received: (from meem@localhost) by dhcp-cbjs05-219-93.PRC.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8H6NuAO002333; Mon, 17 Sep 2007 14:23:56 +0800 (CST) Date: Mon, 17 Sep 2007 14:23:56 +0800 From: Peter Memishian Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <18158.7425.150756.959634@dhcp-cbjs05-219-93.PRC.Sun.COM> To: peter.memishian@sun.com Cc: "Garrett D'Amore" , Cathy Zhou , Kais.Belgaied@sun.com, clearview-discuss , Sebastien Roy , psarc-ext@sun.com Reply-to: peter.memishian@sun.com Message-id: <18158.7548.353646.970144@dhcp-cbjs05-219-93.PRC.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> <18158.1290.455823.164139@dhcp-cbjs05-219-93.PRC.Sun.COM> <46EE07B5.3090706@sun.com> <18158.7425.150756.959634@dhcp-cbjs05-219-93.PRC.Sun.COM> X-Authentication-warning: dhcp-cbjs05-219-93.PRC.Sun.COM: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 528 > There are other dimensions besides GLDv3 driver support -- e.g., Crossbow > will make use of the Vanity Naming feature to provide administratively > chosen names for VNICs. Also if we didn't backport UV, the GLDv3 > codebases for S10 and Nevada would become significantly different, which > also greatly impacts Crossbow (since the Crossbow S10 backport would > become more of a reimplementation than a backport -- with commensurate > impact on testing). BTW, this all seems off-topic for this PSARC case. -- meem From Garrett.Damore@Sun.COM Sun Sep 16 23:39:54 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 l8H6dst2015192 for ; Sun, 16 Sep 2007 23:39:54 -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 l8H6awhN009004 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sun, 16 Sep 2007 23:36:58 -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 <0JOI007012DM4Q00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 23:36:58 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOI002I32DMJD30@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 23:36:58 -0700 (PDT) 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 l8H6aw11019624 for ; Sun, 16 Sep 2007 23:36:58 -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 <0JOI009012DKLG00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 23:36:58 -0700 (PDT) Received: from [192.168.251.21] ([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 <0JOI006OT2DLPW90@fe-sfbay-10.sun.com>; Sun, 16 Sep 2007 23:36:57 -0700 (PDT) Date: Sun, 16 Sep 2007 23:31:51 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <18158.7425.150756.959634@dhcp-cbjs05-219-93.PRC.Sun.COM> Sender: Garrett.Damore@Sun.COM To: Peter.Memishian@Sun.COM Cc: Cathy Zhou , Kais.Belgaied@Sun.COM, clearview-discuss , Sebastien Roy , psarc-ext@Sun.COM Message-id: <46EE1F57.80506@sun.com> Organization: Sun Microsystems 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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> <18158.1290.455823.164139@dhcp-cbjs05-219-93.PRC.Sun.COM> <46EE07B5.3090706@sun.com> <18158.7425.150756.959634@dhcp-cbjs05-219-93.PRC.Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 951 Peter Memishian wrote: > > > Keep in mind that our architecture needs to consider Solaris 10, not just > > > Nevada. Most Solaris 10 networking drivers are not GLDv3-based. > > > > > Good point. I didn't realize that UV was targeting S10. > > > > However, I wonder what the expense of this effort is, compared to the > > effort of backporting the GLDv3 work. > > There are other dimensions besides GLDv3 driver support -- e.g., Crossbow > will make use of the Vanity Naming feature to provide administratively > chosen names for VNICs. I understand that. The "V" portion is still important, obviously. > Also if we didn't backport UV, the GLDv3 > codebases for S10 and Nevada would become significantly different, which > also greatly impacts Crossbow (since the Crossbow S10 backport would > become more of a reimplementation than a backport -- with commensurate > impact on testing). > Sure. - Garrett > -- > meem > From Garrett.Damore@Sun.COM Sun Sep 16 23:40:27 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 l8H6eRtI015206 for ; Sun, 16 Sep 2007 23:40:27 -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 l8H6bVmY008928 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sun, 16 Sep 2007 23:37:31 -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 <0JOI008012EI0C00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 00:37:31 -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 <0JOI001T52EHXB30@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 00:37:30 -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 l8H6bTgh014808 for ; Sun, 16 Sep 2007 23:37:29 -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 <0JOI009012DKLG00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 23:37:29 -0700 (PDT) Received: from [192.168.251.21] ([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 <0JOI006RS2EHPW90@fe-sfbay-10.sun.com>; Sun, 16 Sep 2007 23:37:29 -0700 (PDT) Date: Sun, 16 Sep 2007 23:32:23 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <18158.7425.150756.959634@dhcp-cbjs05-219-93.PRC.Sun.COM> Sender: Garrett.Damore@Sun.COM To: Peter.Memishian@Sun.COM Cc: Cathy Zhou , Kais.Belgaied@Sun.COM, clearview-discuss , Sebastien Roy , psarc-ext@Sun.COM Message-id: <46EE1F77.4000501@sun.com> Organization: Sun Microsystems 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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> <18158.1290.455823.164139@dhcp-cbjs05-219-93.PRC.Sun.COM> <46EE07B5.3090706@sun.com> <18158.7425.150756.959634@dhcp-cbjs05-219-93.PRC.Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 927 Peter Memishian wrote: > > > Keep in mind that our architecture needs to consider Solaris 10, not just > > > Nevada. Most Solaris 10 networking drivers are not GLDv3-based. > > > > > Good point. I didn't realize that UV was targeting S10. > > > > However, I wonder what the expense of this effort is, compared to the > > effort of backporting the GLDv3 work. > > There are other dimensions besides GLDv3 driver support -- e.g., Crossbow > will make use of the Vanity Naming feature to provide administratively > chosen names for VNICs. Also if we didn't backport UV, the GLDv3 > codebases for S10 and Nevada would become significantly different, which > also greatly impacts Crossbow (since the Crossbow S10 backport would > become more of a reimplementation than a backport -- with commensurate > impact on testing). > > -- > meem > Sorry, I forgot the context of being in the ARC case. :-) -- Garrett From Garrett.Damore@sun.com Sun Sep 16 23:54:14 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 l8H6sDWH015623 for ; Sun, 16 Sep 2007 23:54:14 -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 l8H6p7Mv013041 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Sep 2007 14:51:17 +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 <0JOI0080X31FYD00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 00:51:15 -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 <0JOI001DS31EXD40@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 00:51:14 -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 l8H6pEhG019889 for ; Sun, 16 Sep 2007 23:51:14 -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 <0JOI00C012YRNU00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 16 Sep 2007 23:51:14 -0700 (PDT) Received: from [192.168.251.21] ([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 <0JOI0060R31DPWB0@fe-sfbay-10.sun.com>; Sun, 16 Sep 2007 23:51:13 -0700 (PDT) Date: Sun, 16 Sep 2007 23:46:07 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EE0B75.7030902@sun.com> Sender: Garrett.Damore@sun.com To: Cathy Zhou Cc: Kais.Belgaied@sun.com, psarc-ext@sun.com, clearview-discuss , Sebastien Roy Message-id: <46EE22AF.9050906@sun.com> Organization: Sun Microsystems 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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> <46EE0B75.7030902@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 6317 Cathy Zhou wrote: > Garrett D'Amore wrote: >> Cathy Zhou wrote: >>> Garrett D'Amore wrote: >>>> Kais Belgaied wrote: >>>>>> ** MAC_CAPAB_NO_NATIVEVLAN >>>>>> >>>>>> A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to >>>>>> the >>>>>> GLDv3 framework to indicate that a specific MAC cannot >>>>>> support >>>>>> VLAN PPA access by itself. >>>>>> >>>>> this sounds a little upside-down. >>>>> A driver has to advertise a negative capability, essentially >>>>> saying "Hey, I can't handle this feature" >>>>> as opposed to the more intuitive approach: drivers that can handle >>>>> native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), >>>>> and those who don't do not. >>>>> Any reason for this choice? >>>> >>>> It sounds really odd-ball to me, too. Plus, it would require >>>> touching all the existing GLDv3 driver. >>> >>> No. We introduce MAC_CAPAB_NO_NATIVEVLAN exactly for the reason that >>> we do not want to touch most of the GLDv3 driver. >>> MAC_CAPAB_NO_NATIVEVLAN means that this driver cannot handle VLAN >>> PPA access itself (therefore, it might also implies that this driver >>> does not handle the hardware checksum for VLAN packets). Existing >>> GLDv3 drivers should *not* advertise this capability, except the >>> aggr driver, which might based on the underlying aggregated drivers. >>> >>> - Cathy >>> >>> Yech. Far, far better to add >>>> MAC_CAPAB_NATIVEVLAN (or even better, MAC_CAPAB_VLAN_PPA, which >>>> more accurately describes the feature.) >>>> >>>> Of course, IMO, this is really, really weird, because *today* Nemo >>>> drivers are totally ignorant of PPAs, as such. I'm not sure how a >>>> Nemo driver with this feature would act... what causes a VLAN PPA >>>> attach to happen. But there is lot about clearview that I don't >>>> completely understand. >> >> Okay, I'm confused. >> >> GLDv3 drivers do *not* handle PPAs at all. They are totally ignorant >> of the DLPI, and even of VLANs... the only things a GLDv3 driver >> knows directly about (normally) is >> a) instance numbers... each driver normally knows that it has a >> common instance number (which ultimately gets translated to the PPA >> for untagged packets, but that is incidental) >> >> b) tagged packets (which might be for VLANs, or might be for QoS >> tagging) are bigger. All GLDv3 drivers *today* can cope with the >> extra 4 bytes required for tagging. >> >> What exactly does MAC_CAPAB_NO_NATIVELAN convey? Put another way, >> if *all* current GLDv3 NICs qualify as having a "native vlan support" >> (which right now most just support a bigger packet size), then it is, >> IMO, silly to try to emulate above them. >> >> In otherwords, what will UV do with devices that have >> MAC_CAPAB_NO_NATIVEVLAN? Will they get "something special" (some >> different kind of VLAN emulation layer?) Why? >> > We handle MAC_CAPAB_NO_NATIVEVLAN differently in two places: > > a. If mac_open() is for a VLAN PPA accessed stream, and the underlying > MAC supports MAC_CAPAB_PERSTREAM, but *not* MAC_CAPAB_NO_NATIVEVLAN, > we can open the underlying driver directly using its native VLAN PPA > access. > > b. If the MAC is MAC_CAPAB_NO_NATIVEVLAN, then do not advertise its > HW_CKSUM capability on VLAN streams even the MAC claims it is capable > of doing HW CKSUM. Why bother exposing "MAC_CAPAB_PERSTREAM" anywhere? (This was what I *thought* would have been implied by MAC_CAPAB_NATIVEVLAN). It seems that that capability is (or should be, IMO) exclusively internal to the Mac and Driver layer, and never exposed above. Furthermore, since normal (not legacy) GLDv3 drivers have no way to implement CAPAB_PERSTREAM (not ever getting a chance to intercept the calls to xxx_open()), I don't think we need it. What you need, is a way (in the UV framework) to detect legacy drivers that have this attribute. Populating it where others can see it isn't terribly helpful. I think *only* one bit should be needed, MAC_CAPAB_NOTAGGING, which indicates to mac clients that the underlying driver (or driver/nemo/UV combination) cannot support hardware tagging. UV can elect to export this bit on any legacy device which lacks support for the legacy VLAN PPAs. For legacy devices that don't support PPA access to VLANs, I'd just give them pass on VLAN support altogether. They didn't have it on S10 (or S8 or S9...) until now, so they must not need it that badly. :-) And if they're going to do something to enable it for Nevada, they might as well do a GLDv3 conversion properly. Certainly, I'd really, really hope that VLAN PPA access methods could go away in the not-distant-future. Frankly, the only NICs that I think really need this VLAN support are ce and ge, and I wouldn't complain if we did what we could to avoid encouraging GLDv2 drivers from relying on it. (Once S11 ships, or GLDv3 becomes public, we're going to be pushing driver folks hard to avoid GLDv2.) -- Garrett > > - Cathy > >> I think it makes far far more sense for UV (and not just UV, but >> Nemo) to just have >> >> MAC_CAPAB_NO_TAGGING >> >> which covers all legacy drivers that lack full support for tag >> insertion. > > > This means that those drivers won't support VLANs at all >> (and I don't think your -F workaround is a good idea, because it will >> be a call generator and because I think such hardware is now so old >> to be uninteresting, especially given the readily available >> options... the only common PCI legacy NICs I know with that problem >> are 3Com elxl, which is, AFAIK, due to be EOL'd. >> >> All the "interesting" legacy NICs (which is, IIUC, 90% for ce at this >> point, because most of the others are already converted, excepting >> perhaps a few rarer 3rd party NICs) are already converted to GLD. >> (There are mostly uninteresting ones, like pcelx, which hasn't been >> on the market for a very long time....) I'll convert the rest of the >> NIC drivers in ON as soon as I have a way to express the equivalent >> of MAC_CAPAB_NO_TAGGING. Then only the 3rd party ones... and ce and >> gem... will matter. (And I'll probably do gem soon as well, once I >> get access to the hardware... Its almost identical to the work I've >> already done for eri. :-) >> >> -- Garrett >> >> > From Cathy.Zhou@sun.com Mon Sep 17 01:20:17 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 l8H8KG8Q017533 for ; Mon, 17 Sep 2007 01:20:16 -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 l8H8H7xu008561 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 17 Sep 2007 16:17:19 +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 <0JOI00B0B70TQM00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 01:17:17 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOI0021L70QJA70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 01:17:16 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8H8HEg7003595 for ; Mon, 17 Sep 2007 08:17:14 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JOI008016YW7V00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 16:17:14 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JOI002GV70O5DV6@mail-apac.sun.com>; Mon, 17 Sep 2007 16:17:14 +0800 (SGT) Date: Mon, 17 Sep 2007 16:17:09 +0800 From: Cathy Zhou Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EE22AF.9050906@sun.com> Sender: Cathy.Zhou@sun.com To: "Garrett D'Amore" Cc: Kais.Belgaied@sun.com, psarc-ext@sun.com, clearview-discuss , Sebastien Roy Message-id: <46EE3805.5080403@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: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46EAE5E9.3080202@sun.com> <46EDFAB9.1080009@sun.com> <46EE02AB.6090101@sun.com> <46EE0B75.7030902@sun.com> <46EE22AF.9050906@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 6517 Garrett D'Amore wrote: > Cathy Zhou wrote: >> Garrett D'Amore wrote: >>> Cathy Zhou wrote: >>>> Garrett D'Amore wrote: >>>>> Kais Belgaied wrote: >>>>>>> ** MAC_CAPAB_NO_NATIVEVLAN >>>>>>> >>>>>>> A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to >>>>>>> the >>>>>>> GLDv3 framework to indicate that a specific MAC cannot >>>>>>> support >>>>>>> VLAN PPA access by itself. >>>>>>> >>>>>> this sounds a little upside-down. >>>>>> A driver has to advertise a negative capability, essentially >>>>>> saying "Hey, I can't handle this feature" >>>>>> as opposed to the more intuitive approach: drivers that can handle >>>>>> native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), >>>>>> and those who don't do not. >>>>>> Any reason for this choice? >>>>> >>>>> It sounds really odd-ball to me, too. Plus, it would require >>>>> touching all the existing GLDv3 driver. >>>> >>>> No. We introduce MAC_CAPAB_NO_NATIVEVLAN exactly for the reason that >>>> we do not want to touch most of the GLDv3 driver. >>>> MAC_CAPAB_NO_NATIVEVLAN means that this driver cannot handle VLAN >>>> PPA access itself (therefore, it might also implies that this driver >>>> does not handle the hardware checksum for VLAN packets). Existing >>>> GLDv3 drivers should *not* advertise this capability, except the >>>> aggr driver, which might based on the underlying aggregated drivers. >>>> >>>> - Cathy >>>> >>>> Yech. Far, far better to add >>>>> MAC_CAPAB_NATIVEVLAN (or even better, MAC_CAPAB_VLAN_PPA, which >>>>> more accurately describes the feature.) >>>>> >>>>> Of course, IMO, this is really, really weird, because *today* Nemo >>>>> drivers are totally ignorant of PPAs, as such. I'm not sure how a >>>>> Nemo driver with this feature would act... what causes a VLAN PPA >>>>> attach to happen. But there is lot about clearview that I don't >>>>> completely understand. >>> >>> Okay, I'm confused. >>> >>> GLDv3 drivers do *not* handle PPAs at all. They are totally ignorant >>> of the DLPI, and even of VLANs... the only things a GLDv3 driver >>> knows directly about (normally) is >>> a) instance numbers... each driver normally knows that it has a >>> common instance number (which ultimately gets translated to the PPA >>> for untagged packets, but that is incidental) >>> >>> b) tagged packets (which might be for VLANs, or might be for QoS >>> tagging) are bigger. All GLDv3 drivers *today* can cope with the >>> extra 4 bytes required for tagging. >>> >>> What exactly does MAC_CAPAB_NO_NATIVELAN convey? Put another way, >>> if *all* current GLDv3 NICs qualify as having a "native vlan support" >>> (which right now most just support a bigger packet size), then it is, >>> IMO, silly to try to emulate above them. >>> >>> In otherwords, what will UV do with devices that have >>> MAC_CAPAB_NO_NATIVEVLAN? Will they get "something special" (some >>> different kind of VLAN emulation layer?) Why? >>> >> We handle MAC_CAPAB_NO_NATIVEVLAN differently in two places: >> >> a. If mac_open() is for a VLAN PPA accessed stream, and the underlying >> MAC supports MAC_CAPAB_PERSTREAM, but *not* MAC_CAPAB_NO_NATIVEVLAN, >> we can open the underlying driver directly using its native VLAN PPA >> access. >> >> b. If the MAC is MAC_CAPAB_NO_NATIVEVLAN, then do not advertise its >> HW_CKSUM capability on VLAN streams even the MAC claims it is capable >> of doing HW CKSUM. > > Why bother exposing "MAC_CAPAB_PERSTREAM" anywhere? (This was what I > *thought* would have been implied by MAC_CAPAB_NATIVEVLAN). It seems > that that capability is (or should be, IMO) exclusively internal to the > Mac and Driver layer, and never exposed above. > This capability is only known to the Nemo ((including mac and dld) and driver layer . But MAC_CAPAB_PERSTREAM cannot be inferred directly from the MAC_CAPAB_NO_NATIVEVLAN capability, because a) the exception of the aggr driver, b) some other drivers which are able to support "per-stream" open, but only for non-VLAN streams. The only alternative proposal I can think of is to have MAC_CAPAB_PERSTREAM capability to take a value, which indicates whether it can support VLAN as well. *Further*, we need a bit in the hardware checksum capability to indicate whether the HW CHKSUM can be supported for VLAN or not. But as we discussed in another thread, there seems a lot of work other than this is needed to be done in the HW checksum area, I am not going to touch that area in this fast-track yet. > Furthermore, since normal (not legacy) GLDv3 drivers have no way to > implement CAPAB_PERSTREAM (not ever getting a chance to intercept the > calls to xxx_open()), I don't think we need it. > > What you need, is a way (in the UV framework) to detect legacy drivers > that have this attribute. Populating it where others can see it isn't > terribly helpful. > Note that only the GLDv3 framework can see it, and it needs to see it because it will behave differently for mac_open(), proto_capability_req() etc. DLPI clients don't need to know about this at all. > I think *only* one bit should be needed, MAC_CAPAB_NOTAGGING, which > indicates to mac clients that the underlying driver (or driver/nemo/UV > combination) cannot support hardware tagging. > Can you tell me how this can help for per-stream-open of the VLAN streams? > UV can elect to export this bit on any legacy device which lacks support > for the legacy VLAN PPAs. > > For legacy devices that don't support PPA access to VLANs, I'd just give > them pass on VLAN support altogether. They didn't have it on S10 (or > S8 or S9...) until now, so they must not need it that badly. :-) And if > they're going to do something to enable it for Nevada, they might as > well do a GLDv3 conversion properly. > But that is contradictory to what UV (specifically, the U part) tries to accomplish. Also, I don't quite understand why this is related to the MAC_CAPAB_NO_NATIVEVLAN discussion. > Certainly, I'd really, really hope that VLAN PPA access methods could go > away in the not-distant-future. Frankly, the only NICs that I think > really need this VLAN support are ce and ge, and I wouldn't complain if > we did what we could to avoid encouraging GLDv2 drivers from relying on > it. (Once S11 ships, or GLDv3 becomes public, we're going to be pushing > driver folks hard to avoid GLDv2.) > I agree. But I disagree that Nemo unification is trying to encourage more GLDv2 drivers. Thanks - Cathy From Sebastien.Roy@Sun.COM Tue Sep 18 11:43:11 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 l8IIhBjb004543 for ; Tue, 18 Sep 2007 11:43:11 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8IIeF27002878 for ; Tue, 18 Sep 2007 11:40:15 -0700 (PDT) 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 l8IIeFlh028927 for ; Tue, 18 Sep 2007 18:40:15 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 <0JOK00J01RB8HW00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Sep 2007 12:40:15 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOK0008JUIQQU70@mail-amer.sun.com>; Tue, 18 Sep 2007 12:40:02 -0600 (MDT) Date: Tue, 18 Sep 2007 14:40:02 -0400 From: Sebastien Roy Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46EADF2D.6090302@Sun.COM> Sender: Sebastien.Roy@Sun.COM To: Kais.Belgaied@Sun.COM Cc: psarc-ext@Sun.COM, clearview-discuss Message-id: <46F01B82.9090005@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 786 Kais Belgaied wrote: > > this sounds a little upside-down. > A driver has to advertise a negative capability, essentially saying > "Hey, I can't handle this feature" > as opposed to the more intuitive approach: drivers that can handle > native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), > and those who don't do not. > Any reason for this choice? This discussion veered off a little bit, and I want to bring it back on-topic and make sure that progress is being made on this case. Kais, was your original question answered? To summarize, the only driver expected to implement this is the softmac driver introduced by UV (PSARC/2006/499). The capability's semantics were defined in such a way to not require every other driver from having to care about its existence. -Seb From Kais.Belgaied@Sun.COM Wed Sep 19 10:02: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 l8JH2pF6008386 for ; Wed, 19 Sep 2007 10:02:51 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8JGxpcN029960; Wed, 19 Sep 2007 17:59:51 +0100 (BST) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8JGxoXO252348; Wed, 19 Sep 2007 09:59:50 -0700 (PDT) Message-ID: <46F15586.8030702@Sun.COM> Date: Wed, 19 Sep 2007 09:59:50 -0700 From: Kais Belgaied Reply-To: Kais.Belgaied@Sun.COM User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: Sebastien Roy CC: psarc-ext@Sun.COM, clearview-discuss Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46F01B82.9090005@sun.com> In-Reply-To: <46F01B82.9090005@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2649 Sebastien Roy wrote: > Kais Belgaied wrote: >> >> this sounds a little upside-down. >> A driver has to advertise a negative capability, essentially saying >> "Hey, I can't handle this feature" >> as opposed to the more intuitive approach: drivers that can handle >> native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN), >> and those who don't do not. >> Any reason for this choice? > > This discussion veered off a little bit, and I want to bring it back > on-topic and make sure that progress is being made on this case. > Kais, was your original question answered? well, not really. I'm not sure I understand the following argument: > It sounds really odd-ball to me, too. Plus, it would require > >>>> touching all the existing GLDv3 driver. > >>> >>> No. We introduce MAC_CAPAB_NO_NATIVEVLAN exactly for the reason that >>> we do not want to touch most of the GLDv3 driver. >>> MAC_CAPAB_NO_NATIVEVLAN means that this driver cannot handle VLAN >>> PPA access itself (therefore, it might also implies that this driver >>> does not handle the hardware checksum for VLAN packets). Existing >>> GLDv3 drivers should *not* advertise this capability, except the >>> aggr driver, which might based on the underlying aggregated drivers. does it mean that by default *all* GLDv3 drivers do or are assumed to support native VLAN, with the exception of only a few? another two unclear points that were brought up by the discussion is the interaction of the proposed capab with with the HW Checksum capability, and with the MAC_CAPAB_PERSTREAM: > We handle MAC_CAPAB_NO_NATIVEVLAN differently in two places: > > a. If mac_open() is for a VLAN PPA accessed stream, and the underlying > MAC supports MAC_CAPAB_PERSTREAM, but *not* MAC_CAPAB_NO_NATIVEVLAN, > we can open the underlying driver directly using its native VLAN PPA > access. > > b. If the MAC is MAC_CAPAB_NO_NATIVEVLAN, then do not advertise its > HW_CKSUM capability on VLAN streams even the MAC claims it is capable > of doing HW CKSUM. > > To summarize, the only driver expected to implement this is the > softmac driver introduced by UV (PSARC/2006/499). The capability's > semantics were defined in such a way to not require every other driver > from having to care about its existence. Ah! in this case, it seems just an internal interface between Nemo and itself. If that's true then it's an implemetnation choice and shouldn't be exposed to device driver writers as part of the MAC_CAPAB* interface maturing to soon become committed, and the case can just be withdrawn as it turns out to be below the radar for an ARC review. Kais. > > -Seb > From John.Plocher@Sun.COM Wed Sep 19 10:19:02 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 l8JHJ2VO010608 for ; Wed, 19 Sep 2007 10:19:02 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8JHG3X4007991 for ; Wed, 19 Sep 2007 18:16:03 +0100 (BST) 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 l8JHFvR2011253 for ; Wed, 19 Sep 2007 10:15:57 -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 <0JOM00C01L7H1M00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Sep 2007 10:15:57 -0700 (PDT) Received: from wp668.sfbay.sun.com ([129.146.58.87]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOM00GU8LA5WNG0@fe-sfbay-10.sun.com>; Wed, 19 Sep 2007 10:15:41 -0700 (PDT) Date: Wed, 19 Sep 2007 10:15:39 -0700 From: John Plocher Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46F15586.8030702@Sun.COM> Sender: John.Plocher@Sun.COM To: Kais.Belgaied@Sun.COM Cc: Sebastien Roy , psarc-ext@Sun.COM, clearview-discuss Message-id: <46F1593B.1070204@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46F01B82.9090005@sun.com> <46F15586.8030702@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 587 Kais Belgaied wrote: > Ah! in this case, it seems just an internal interface between Nemo and > itself. If that's true then it's an implemetnation choice and shouldn't be > exposed to device driver writers as part of the MAC_CAPAB* interface > maturing to soon become committed, and the case can just be withdrawn as > it turns out to be below the radar for an ARC review. Probably better to change it to closed approved automatic - the project isn't being withdrawn, it /is/ going into the product, it just doesn't need the ARCs to do anything formal along the way :-) -John From Cathy.Zhou@Sun.COM Thu Sep 20 00:45:56 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 l8K7juUJ000864 for ; Thu, 20 Sep 2007 00:45:56 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8K7guL9011782 for ; Thu, 20 Sep 2007 00:42:57 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8K7gpGR000137 for ; Thu, 20 Sep 2007 07:42:51 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JON00L01P48W100@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 20 Sep 2007 15:42:51 +0800 (SGT) Received: from [129.158.219.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JON00HVQPFBYHP1@mail-apac.sun.com>; Thu, 20 Sep 2007 15:42:50 +0800 (SGT) Date: Thu, 20 Sep 2007 15:42:42 +0800 From: Cathy Zhou Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46F1593B.1070204@Sun.Com> Sender: Cathy.Zhou@Sun.COM To: John Plocher Cc: Kais.Belgaied@Sun.COM, psarc-ext@Sun.COM, clearview-discuss , Sebastien Roy Message-id: <46F22472.4040205@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46F01B82.9090005@sun.com> <46F15586.8030702@Sun.COM> <46F1593B.1070204@Sun.Com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) Status: RO Content-Length: 829 John Plocher wrote: > Kais Belgaied wrote: >> Ah! in this case, it seems just an internal interface between Nemo and >> itself. If that's true then it's an implemetnation choice and shouldn't be >> exposed to device driver writers as part of the MAC_CAPAB* interface >> maturing to soon become committed, and the case can just be withdrawn as >> it turns out to be below the radar for an ARC review. > > > Probably better to change it to closed approved automatic - the project > isn't being withdrawn, it /is/ going into the product, it just doesn't > need the ARCs to do anything formal along the way :-) > Please be noted that other than the MAC_CAPAB_NO_NATIVEVLAN interface, this case also proposed other interfaces (DLIOCMARGININFO ioctl, m_margin etc.) that would be exposed to the device drivers. Thanks - Cathy From Kais.Belgaied@Sun.COM Fri Sep 21 12:47:21 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 l8LJlKnT014326 for ; Fri, 21 Sep 2007 12:47:21 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8LJiG1e016691; Fri, 21 Sep 2007 20:44:16 +0100 (BST) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8LJiFnY710856; Fri, 21 Sep 2007 12:44:15 -0700 (PDT) Message-ID: <46F41F0F.3020407@Sun.COM> Date: Fri, 21 Sep 2007 12:44:15 -0700 From: Kais Belgaied Reply-To: Kais.Belgaied@Sun.COM User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: Cathy Zhou CC: John Plocher , psarc-ext@Sun.COM, clearview-discuss , Sebastien Roy Subject: Re: [clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification References: <46E80F28.2080506@sun.com> <46EADF2D.6090302@Sun.COM> <46F01B82.9090005@sun.com> <46F15586.8030702@Sun.COM> <46F1593B.1070204@Sun.Com> <46F22472.4040205@sun.com> In-Reply-To: <46F22472.4040205@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1028 Cathy Zhou wrote: > John Plocher wrote: >> Kais Belgaied wrote: >>> Ah! in this case, it seems just an internal interface between Nemo >>> and itself. If that's true then it's an implemetnation choice and >>> shouldn't be >>> exposed to device driver writers as part of the MAC_CAPAB* interface >>> maturing to soon become committed, and the case can just be >>> withdrawn as it turns out to be below the radar for an ARC review. >> >> >> Probably better to change it to closed approved automatic - the project >> isn't being withdrawn, it /is/ going into the product, it just doesn't >> need the ARCs to do anything formal along the way :-) >> > Please be noted that other than the MAC_CAPAB_NO_NATIVEVLAN interface, > this case also proposed other interfaces (DLIOCMARGININFO ioctl, > m_margin etc.) that would be exposed to the device drivers. noted. The DLIOCMARGININFOand the gldm_margin field in gld_mac_info_t (from a an existing reserved field) seemed non controversial to me. Kais > > Thanks > - Cathy > From Sebastien.Roy@sun.com Mon Sep 24 12:14:59 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 l8OJEwSq009299 for ; Mon, 24 Sep 2007 12:14:58 -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 l8OJBtUf014448 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 24 Sep 2007 20:11:55 +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 <0JOV00L01ZZSDM00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Sep 2007 12:11:52 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOV00K9MZZS3Z20@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Sep 2007 12:11:52 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8OJBqTp015383 for ; Mon, 24 Sep 2007 19:11:52 +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 <0JOV00F01ZTDMQ00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Sep 2007 13:11:52 -0600 (MDT) Received: from [192.168.1.3] ([72.93.204.238]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOV00EPLZZBPS20@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Sep 2007 13:11:36 -0600 (MDT) Date: Mon, 24 Sep 2007 15:11:35 -0400 From: Sebastien Roy Subject: Re: 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification In-reply-to: <46E80F28.2080506@sun.com> Sender: Sebastien.Roy@sun.com To: Sebastien Roy Cc: psarc-ext@sun.com, clearview-discuss Message-id: <46F80BE7.10105@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: <46E80F28.2080506@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 381 Sebastien Roy wrote: > I'm sponsoring this fast-track request for Cathy Zhou and the Clearview > team. The timer is set for 09/19/2007. While the timer for this case officially expired last Wednesday, more time was needed to let the ongoing discussion converge. There are no more outstanding issues with the spec as-is, thus I'm marking the case approved as of today. -Seb