From Sebastien.Roy@sun.com Mon Apr 7 15:39:53 2008 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 m37MdqYK004768 for ; Mon, 7 Apr 2008 15:39:53 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37MdowG016060 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 7 Apr 2008 23:39:52 +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 <0JYZ00A258AERS00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 07 Apr 2008 16:39:50 -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 <0JYZ00I188ADC0E0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 07 Apr 2008 16:39:49 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m37Mdngb024219 for ; Mon, 07 Apr 2008 22:39:49 +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 <0JYZ0010189CW000@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 07 Apr 2008 16:39:49 -0600 (MDT) Received: from [192.168.1.3] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYZ0054O8ACDIB0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 07 Apr 2008 16:39:49 -0600 (MDT) Date: Mon, 07 Apr 2008 18:39:47 -0400 From: Sebastien Roy Subject: 2008/242 Data Fast-Path for Softmac Sender: Sebastien.Roy@sun.com To: PSARC-ext@sun.com Cc: Clearview Discuss Message-id: <47FAA2B3.2080900@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 10369 I'm submitting this fast-track for Cathy Zhou. The timer is set for April 14th, 2008. Data Fast-Path for Softmac ========================== Release binding: Patch Summary ======= This case introduces a GLDv3 fast-path architecture for softmac devices. The softmac architecture defined by PSARC/2006/499 initially contained a fast-path which was not delivered with Clearview UV as discussed in section 2.1 of PSARC/2008/002. PSARC/2008/002 states that an alternative fast-path architecture would be defined in a future case, and that is this case. Details ======= - Data fast-path and slow-path Currently, the softmac module discovers each legacy network device and registers (soft)MACs to the GLDv3 framework on behalf of these legacy devices. Whenever a softMAC is used, the softmac module opens a DLIOCRAW stream over the legacy device, and enables DL_PROMISC_SAP promiscuous mode on the stream. This DLIOCRAW stream is then shared by all data packets sent and received over this softMAC. We call this DLIOCRAW stream "shared lower stream". Although the above is consistent with the existing GLDv3 model and requires less changes to the GLDv3 framework, it introduces unacceptable performance regression over legacy devices, because of the extra data demultiplexing and filtering processing in the GLDv3 DLS/MAC layer. Therefore, this case proposes a softmac data fast-path architecture which is less intrusive to the current Solaris network architecture and will address the performance issue of the above approach: Specifically, when the fast-path is used, a dedicated lower-stream will be opened over the legacy device for each IP/ARP (upper-)stream over the softMAC, and all DLPI messages (including control messages and data messages) will be exchanged between the upper-stream and the corresponding lower-stream directly. Therefore, the data demultiplexing, filtering and classification processing will be done by the lower-stream, and the GLDv3 DLS/MAC layer processing will be no longer needed. Note that some GLDv3 features requires the GLDv3 DLS/MAC layer processing to not be bypassed to assure its function correctness. For example, softmac fast-path must be disabled to support GLDv3 VNIC functionality. As the result, we propose: By default, the softmac fast-path mode will be used to assure the performance; MAC clients will be able to request to disable the softmac fast-path mode to support certain features, and if that succeeds, the system will fallback to the existing softmac data-path model (called slow-path). The details of the new softmac data fast-path model is stated as below (note that the softmac fast-path will only be used for the IP/ARP streams over softMACs, which is the case performance matters most): 1. When a stream (including a VLAN stream) is opened on a softMAC, the softmac module will takes over the DLPI processing on this stream; 2. For IP/ARP streams over a softMAC, softmac data fast-path will be used by default, unless fast-path is disabled by any MAC client explicitly. The softmac module first identifies an IP/ARP stream by seeing whether there is a SIOCSLIFNAME ioctl sent from upstream, if there is one, this stream is either an IP or an ARP stream and will use fast-path potentially; 3. When the softmac fast-path is used, an dedicated lower-stream will be setup for each IP/ARP stream (1-1 mapping). From that point on, all control and data messages will be exchanged between the IP/ARP upper-stream and the legacy device through this dedicated lower-stream. As a result, the DLS/MAC layer processing in GLDv3 will be skipped, and this greatly improves the performance; 4. When the softmac data fast-path is disabled by a MAC client (e.g., by a VNIC), all the IP/ARP upper streams will try to switch from the fast-path to the slow-path. The dedicated lower-stream will be destroyed, and all the control and data-messages will go through the existing GLDv3 code path and (in the end) the shared lower-stream; 5. On the other hand, when the last MAC client cancels its fast-path disable request, all the IP/ARP streams will try to switch back to the fast-path mode; Step 5 and 6 both rely on the data-path mode switching process described below: 1) To switch the softmac data-path mode (between fast-path and slow-path), softmac will first send a DL_NOTE_REPLUMB DL_NOTIFY_IND message upstream over each IP/ARP streams that needs data-path mode switching; 2) When IP receives this DL_NOTE_REPLUMB message, it will bring down all the IP interfaces on the corresponding ill (IP Lower level structure), and bring up those interfaces over again; this will in turn cause the ARP to "replumb" the interface. During the replumb process, both IP and ARP will send downstream the necessary DL_DISABMULTI_REQ and DL_UNBIND_REQ messages and cleanup the old state of the underlying softMAC, following with the necessary DL_BIND_REQ and DL_ENABMULTI_REQ messages to setup the new state. Between the cleanup and re-setup process, IP/ARP will also send down a DL_NOTE_REPLUMB_DONE DL_NOTIFY_CONF messages to the softMAC to indicate the *switching point*; 3) When softmac receives the DL_NOTE_REPLUMB_DONE message, it either creates or destroys the dedicated lower-stream (depending on which data-path mode the softMAC switches to), and change the softmac data-path mode. From then on, softmac will process all the succeeding control messages (including the DL_BIND_REQ and DL_ENABMULTI_REQ messages) and data messages based on new data-path mode. Interfaces ========== - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation Private) Two MAC client interfaces will be added: int mac_fastpath_disable(mac_handle_t); This function will be called when a mac client requires to disable the softmac data fast-path over a specific mac. It will return errno in case that the fast-path is failed to be disabled. If the given mac is a mac over a GLDv3 device, 0 (success) will be directly returned. void mac_fastpath_enable(mac_handle_t); The mac_fastpath_enable() function will be called when a mac client cancels its softmac fast-path disabling requests over a specific mac. When the last fast-path disabling request is canceled, the underlying softmac will try to reenable the data fast-path. It is not considered as a failure if fast-path fails to be reenabled, as that will only have performance impact. - dld_str_open()/dld_str_close()/dld_str_private() (Project Private) Three new dls interfaces will be added: int dld_str_open(queue_t *, dev_t *, void *opaque); This function will be called by softmac to setup the dld stream related structures, which will be used when softmac fast-path is not used. An opaque pointer will be passed into this function to keep softmac specific state associated with the given stream. int dld_str_close(queue_t *); This function will be called by softmac to finish up the dld stream operation and destroy dld related structures. void *dld_str_private(queue_t *); This function will be called to query the opaque pointer associated with the given stream. - the mac_capab_legacy_t structure (Project Private) The mac_capab_legacy_t structure was introduced by PSARC/2008/002, it is the data pointer of the MAC_CAPAB_LEGACY MAC capability. This case proposes to add the following fields to the data structure: /* * Info and callbacks of legacy devices. */ typedef struct mac_capab_legacy_s { ... int (*ml_fastpath_disable)(void *); void (*ml_fastpath_enable)(void *); boolean_t (*ml_active_set)(void *); void (*ml_active_clear)(void *); } mac_capab_legacy_t; The ml_fastpath_enable() and ml_fastpath_disable() callbacks will be called as the result of first mac_fastpath_disable() and last mac_fastpath_enable() request on a particular softMAC. Further, to assure there is at most one exclusive active MAC consumer at a time (see [3]), we must prevent other exclusive active MAC consumers when there is already IP/ARP stream on a softMAC, and prevent IP/ARP streams if there is already exclusive active MAC consumers. This is done by the mac module calling the ml_active_set() and ml_active_clear() callbacks to inform softmac the existence and disappearance of an exclusive active MAC consumer. - the DL_NOTIFY_CONF primitive (M_PROTO type) (Project Private) The DL_NOTIFY_CONF primitive is similar to DL_NOTIFY_IND, but it is notification sent from upstream (from a DLPI consumer to a DLPI provider). DL_NOTIFY_CONF is a M_PROTO message with the following payload: typedef struct { t_uscalar_t dl_primitive; /* set to DL_NOTIFY_CONF */ uint32_t dl_notification; /* Which notification? */ } dl_notify_conf_t; The only dl_notification type we will support is DL_NOTE_REPLUMB_DONE. - the DL_NOTE_REPLUMB DL_NOTIFY_IND message (Project Private) As described above, the DL_NOTE_REPLUMB message is sent by softmac to inform the IP/ARP upstream to "replumb" the stream. References ========== [1] PSARC 2006/499 Clearview Nemo unification and vanity naming - http://sac.sfbay/PSARC/2006/499/ [2] PSARC 2008/002 Clearview UV Updates - http://sac.sfbay/PSARC/2008/002/ [3] PSARC 2005/207 Clearview for Nemo - http://sac.sfbay/PSARC/2005/207/ From Darren.Reed@sun.com Mon Apr 7 18:22:33 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m381MXv9009488 for ; Mon, 7 Apr 2008 18:22:33 -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 m381MXps023452 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Apr 2008 18:22:33 -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 <0JYZ00201FTLP000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 18:22:33 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYZ002JMFTJ6I10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 18:22:32 -0700 (PDT) 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 m381Mxlh005935 for ; Tue, 08 Apr 2008 01:22:59 +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 <0JYZ00A01FP72300@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 09:22:00 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYZ00BLNFSNRFP4@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 09:22:00 +0800 (SGT) Date: Mon, 07 Apr 2008 18:22:29 -0700 From: Darren Reed Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAA2B3.2080900@sun.com> Sender: Darren.Reed@sun.com To: Sebastien Roy , Cathy Zhou Cc: PSARC-ext@sun.com Message-id: <47FAC8D5.2010205@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1966 Sebastien Roy wrote: ... > Note that some GLDv3 features requires the GLDv3 DLS/MAC layer > processing to not be bypassed to assure its function correctness. > For example, softmac fast-path must be disabled to support GLDv3 > VNIC functionality. As the result, we propose: By default, the > softmac fast-path mode will be used to assure the performance; MAC > clients will be able to request to disable the softmac fast-path > mode to support certain features, and if that succeeds, the system > will fallback to the existing softmac data-path model (called > slow-path). Does VNIC here only refer to the vni* interfaces or does it also to the VLAN network interfaces, such as ce132000? Can the architecture of this project be changed or expanded to include dealing with the VNIC functionality problem? > 2. For IP/ARP streams over a softMAC, softmac data fast-path > will be > used by default, unless fast-path is disabled by any MAC client > explicitly. The softmac module first identifies an IP/ARP > stream > by seeing whether there is a SIOCSLIFNAME ioctl sent from > upstream, > if there is one, this stream is either an IP or an ARP stream > and will use fast-path potentially; Why are you looking at the SIOCSLIFNAME ioctl rather than the bind? As defined, SIOCSLIFNAME does not appear to be IP specific at all, aside from our implementation and use. > 4. When the softmac data fast-path is disabled by a MAC client > (e.g., > by a VNIC), all the IP/ARP upper streams will try to switch > from > the fast-path to the slow-path. ... > 5. On the other hand, when the last MAC client cancels its fast-path > disable request, all the IP/ARP streams will try to switch back to > the fast-path mode; In both cases 4 & 5, what happens if they fail to switch over? Darren From Cathy.Zhou@sun.com Mon Apr 7 20:19:01 2008 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 m383J0PZ012338 for ; Mon, 7 Apr 2008 20:19:01 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m383Iu7X016847 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Apr 2008 04:18:59 +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 <0JYZ00F0BL7MYN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 20:18:58 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYZ007ONL7K5350@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 20:18:57 -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 m383J9Oq017564 for ; Tue, 08 Apr 2008 03:19:09 +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 <0JYZ00M01L0YAU00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 11:18:51 +0800 (SGT) Received: from [129.146.105.122] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYZ004SSL7BPGG3@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 11:18:49 +0800 (SGT) Date: Mon, 07 Apr 2008 20:18:45 -0700 From: Cathy Zhou Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAC8D5.2010205@Sun.COM> Sender: Cathy.Zhou@sun.com To: Darren Reed Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <47FAE415.5050501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAC8D5.2010205@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 2840 Darren Reed wrote: > Sebastien Roy wrote: > ... > >> Note that some GLDv3 features requires the GLDv3 DLS/MAC layer >> processing to not be bypassed to assure its function correctness. >> For example, softmac fast-path must be disabled to support GLDv3 >> VNIC functionality. As the result, we propose: By default, the >> softmac fast-path mode will be used to assure the performance; MAC >> clients will be able to request to disable the softmac fast-path >> mode to support certain features, and if that succeeds, the system >> will fallback to the existing softmac data-path model (called >> slow-path). > > > Does VNIC here only refer to the vni* interfaces or does > it also to the VLAN network interfaces, such as ce132000? > No, the VNIC functionality here only refers to the VNICs required by the xVM networking for now. > Can the architecture of this project be changed or expanded > to include dealing with the VNIC functionality problem? > I am not clear what your question is. Note that VNIC is going to be supported on legacy device as part of this case. But once VNIC is configured, fastpath will be disabled. > >> 2. For IP/ARP streams over a softMAC, softmac data fast-path >> will be >> used by default, unless fast-path is disabled by any MAC client >> explicitly. The softmac module first identifies an IP/ARP >> stream >> by seeing whether there is a SIOCSLIFNAME ioctl sent from >> upstream, >> if there is one, this stream is either an IP or an ARP stream >> and will use fast-path potentially; > > > Why are you looking at the SIOCSLIFNAME ioctl rather than > the bind? As defined, SIOCSLIFNAME does not appear to be > IP specific at all, aside from our implementation and use. > I thought SIOCSLIFNAME is a private ioctl and should not be used by others other than IP. Please correct me if I am wrong. > >> 4. When the softmac data fast-path is disabled by a MAC client >> (e.g., >> by a VNIC), all the IP/ARP upper streams will try to switch >> from >> the fast-path to the slow-path. > > ... > > 5. On the other hand, when the last MAC client cancels its > fast-path > > disable request, all the IP/ARP streams will try to switch > back to > > the fast-path mode; > > > In both cases 4 & 5, what happens if they fail to switch over? In case 4, mac_fastpath_disable() will return failure and whoever calls this function (e.g., VNIC) should discontinue and fail the current operation too. Case 5 is different as it does not matter if fastpath fails to be reenabled, as it only affects performance. This is described in mac_fastpath_disable()/mac_fastpath_enable() interface section. Thanks - Cathy > > Darren > From Darren.Reed@sun.com Mon Apr 7 20:50:57 2008 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 m383ouM1012496 for ; Mon, 7 Apr 2008 20:50:56 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m383onFR025787 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Apr 2008 04:50:55 +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 <0JYZ00K03MOUSG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 20:50:54 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYZ00JSIMOT1210@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 20:50:54 -0700 (PDT) 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 m383pLOf016681 for ; Tue, 08 Apr 2008 03:51:21 +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 <0JYZ00J01MJ3O200@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 11:50:47 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYZ00469MOMPGO3@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 11:50:47 +0800 (SGT) Date: Mon, 07 Apr 2008 20:50:50 -0700 From: Darren Reed Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAE415.5050501@sun.com> Sender: Darren.Reed@sun.com To: Cathy Zhou Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <47FAEB9A.90808@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAC8D5.2010205@Sun.COM> <47FAE415.5050501@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2393 Cathy Zhou wrote: > Darren Reed wrote: > >> Sebastien Roy wrote: >> ... >> >>> Note that some GLDv3 features requires the GLDv3 DLS/MAC layer >>> processing to not be bypassed to assure its function >>> correctness. >>> For example, softmac fast-path must be disabled to support GLDv3 >>> VNIC functionality. As the result, we propose: By default, the >>> softmac fast-path mode will be used to assure the >>> performance; MAC >>> clients will be able to request to disable the softmac fast-path >>> mode to support certain features, and if that succeeds, the >>> system >>> will fallback to the existing softmac data-path model (called >>> slow-path). >> ... >> Can the architecture of this project be changed or expanded >> to include dealing with the VNIC functionality problem? >> > I am not clear what your question is. Note that VNIC is going to be > supported on legacy device as part of this case. But once VNIC is > configured, fastpath will be disabled. Let me approach this from a different angle... What sort of architectural problems exist that prevent this fast-path project from being extended to supporting VNICs? >>> 2. For IP/ARP streams over a softMAC, softmac data fast-path >>> will be >>> used by default, unless fast-path is disabled by any MAC >>> client >>> explicitly. The softmac module first identifies an IP/ARP >>> stream >>> by seeing whether there is a SIOCSLIFNAME ioctl sent from >>> upstream, >>> if there is one, this stream is either an IP or an ARP stream >>> and will use fast-path potentially; >> >> >> >> Why are you looking at the SIOCSLIFNAME ioctl rather than >> the bind? As defined, SIOCSLIFNAME does not appear to be >> IP specific at all, aside from our implementation and use. >> > I thought SIOCSLIFNAME is a private ioctl and should not be used by > others other than IP. Please correct me if I am wrong. Let me approach this from a different angle... Architecturally, you seem to have chosen to use a private ioctl that has some predefined characteristics that _imply_ IP rather than a public one (the bind) which informs you exactly about whether or not it is IP, ARP, etc. That is the choice to use SIOCSLIFNAME as the trigger appears weaker than using the bind. Why did you make this choice? Darren From gdamore@sun.com Mon Apr 7 21:16:04 2008 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 m384G382014014 for ; Mon, 7 Apr 2008 21:16:04 -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 m384G3PP062467 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Apr 2008 22:16:03 -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 <0JYZ00C0BNURBK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 22:16:03 -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 <0JYZ00BLANUQ49C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 22:16:02 -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 m384G2Ms006293 for ; Mon, 07 Apr 2008 21:16:02 -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 <0JYZ00701NQJ9Z00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 21:16:02 -0700 (PDT) Received: from [192.168.251.106] ([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 <0JYZ00ICQNUP4150@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Apr 2008 21:16:02 -0700 (PDT) Date: Mon, 07 Apr 2008 21:12:07 -0700 From: "Garrett D'Amore" Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAA2B3.2080900@sun.com> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: PSARC-ext@sun.com, Clearview Discuss Message-id: <47FAF097.1030402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 11513 As a general architectural comment here, I want to point out that I feel that this case introduces additional complexity, that should be unnecessary -- performance critical NICs should be written to GLDv3. (The fact that GLDv3's API is still private is another matter altogether -- but I believe introducing this code to address a "performance issue" with a certain NIC product, is the wrong way to go here.) Far far better, IMO, is to "fix" the main driver this case is for (cassini), which architecturally could easily be converted to GLDv3 and bundled into Nevada, and then spend effort to wrap up GLDv3 enough to publish it for 3rd parties. -- Garrett Sebastien Roy wrote: > I'm submitting this fast-track for Cathy Zhou. The timer is set for > April 14th, 2008. > > Data Fast-Path for Softmac > ========================== > > Release binding: Patch > > Summary > ======= > > This case introduces a GLDv3 fast-path architecture for softmac > devices. > The softmac architecture defined by PSARC/2006/499 initially > contained > a fast-path which was not delivered with Clearview UV as discussed in > section 2.1 of PSARC/2008/002. PSARC/2008/002 states that an > alternative > fast-path architecture would be defined in a future case, and that is > this case. > > Details > ======= > > - Data fast-path and slow-path > > Currently, the softmac module discovers each legacy network device > and registers (soft)MACs to the GLDv3 framework on behalf of these > legacy devices. Whenever a softMAC is used, the softmac module > opens > a DLIOCRAW stream over the legacy device, and enables > DL_PROMISC_SAP > promiscuous mode on the stream. This DLIOCRAW stream is then shared > by all data packets sent and received over this softMAC. We call > this > DLIOCRAW stream "shared lower stream". > > Although the above is consistent with the existing GLDv3 model and > requires less changes to the GLDv3 framework, it introduces > unacceptable performance regression over legacy devices, because of > the extra data demultiplexing and filtering processing in the GLDv3 > DLS/MAC layer. > > Therefore, this case proposes a softmac data fast-path architecture > which is less intrusive to the current Solaris network architecture > and will address the performance issue of the above approach: > > Specifically, when the fast-path is used, a dedicated lower-stream > will be opened over the legacy device for each IP/ARP > (upper-)stream > over the softMAC, and all DLPI messages (including control messages > and data messages) will be exchanged between the upper-stream and > the corresponding lower-stream directly. Therefore, the data > demultiplexing, filtering and classification processing will be > done > by the lower-stream, and the GLDv3 DLS/MAC layer processing will be > no longer needed. > > Note that some GLDv3 features requires the GLDv3 DLS/MAC layer > processing to not be bypassed to assure its function correctness. > For example, softmac fast-path must be disabled to support GLDv3 > VNIC functionality. As the result, we propose: By default, the > softmac fast-path mode will be used to assure the performance; MAC > clients will be able to request to disable the softmac fast-path > mode to support certain features, and if that succeeds, the system > will fallback to the existing softmac data-path model (called > slow-path). > > The details of the new softmac data fast-path model is stated as > below > (note that the softmac fast-path will only be used for the IP/ARP > streams over softMACs, which is the case performance matters most): > > 1. When a stream (including a VLAN stream) is opened on a softMAC, > the softmac module will takes over the DLPI processing on this > stream; > > 2. For IP/ARP streams over a softMAC, softmac data fast-path > will be > used by default, unless fast-path is disabled by any MAC client > explicitly. The softmac module first identifies an IP/ARP stream > by seeing whether there is a SIOCSLIFNAME ioctl sent from > upstream, > if there is one, this stream is either an IP or an ARP stream > and will use fast-path potentially; > > 3. When the softmac fast-path is used, an dedicated lower-stream > will > be setup for each IP/ARP stream (1-1 mapping). From that > point on, > all control and data messages will be exchanged between the > IP/ARP > upper-stream and the legacy device through this dedicated > lower-stream. As a result, the DLS/MAC layer processing in GLDv3 > will be skipped, and this greatly improves the performance; > > 4. When the softmac data fast-path is disabled by a MAC client > (e.g., > by a VNIC), all the IP/ARP upper streams will try to switch from > the fast-path to the slow-path. The dedicated lower-stream > will be > destroyed, and all the control and data-messages will go through > the existing GLDv3 code path and (in the end) the shared > lower-stream; > > 5. On the other hand, when the last MAC client cancels its > fast-path > disable request, all the IP/ARP streams will try to switch > back to > the fast-path mode; > > Step 5 and 6 both rely on the data-path mode switching process > described below: > > 1) To switch the softmac data-path mode (between fast-path and > slow-path), softmac will first send a DL_NOTE_REPLUMB > DL_NOTIFY_IND message upstream over each IP/ARP streams that > needs data-path mode switching; > > 2) When IP receives this DL_NOTE_REPLUMB message, it will bring > down all the IP interfaces on the corresponding ill (IP Lower > level structure), and bring up those interfaces over again; > this will in turn cause the ARP to "replumb" the interface. > > During the replumb process, both IP and ARP will send > downstream the necessary DL_DISABMULTI_REQ and DL_UNBIND_REQ > messages and cleanup the old state of the underlying softMAC, > following with the necessary DL_BIND_REQ and DL_ENABMULTI_REQ > messages to setup the new state. Between the cleanup and > re-setup > process, IP/ARP will also send down a DL_NOTE_REPLUMB_DONE > DL_NOTIFY_CONF messages to the softMAC to indicate the > *switching point*; > > 3) When softmac receives the DL_NOTE_REPLUMB_DONE message, it > either creates or destroys the dedicated lower-stream > (depending > on which data-path mode the softMAC switches to), and change > the softmac data-path mode. From then on, softmac will > process > all the succeeding control messages (including the > DL_BIND_REQ and > DL_ENABMULTI_REQ messages) and data messages based on new > data-path mode. > > Interfaces > ========== > > - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation > Private) > > Two MAC client interfaces will be added: > > int mac_fastpath_disable(mac_handle_t); > > This function will be called when a mac client requires to disable > the softmac data fast-path over a specific mac. It will return > errno > in case that the fast-path is failed to be disabled. If the > given mac > is a mac over a GLDv3 device, 0 (success) will be directly > returned. > > void mac_fastpath_enable(mac_handle_t); > > The mac_fastpath_enable() function will be called when a mac client > cancels its softmac fast-path disabling requests over a specific > mac. > When the last fast-path disabling request is canceled, the > underlying > softmac will try to reenable the data fast-path. It is not > considered > as a failure if fast-path fails to be reenabled, as that will only > have performance impact. > > - dld_str_open()/dld_str_close()/dld_str_private() (Project Private) > > Three new dls interfaces will be added: > > int dld_str_open(queue_t *, dev_t *, void *opaque); > > This function will be called by softmac to setup the dld stream > related structures, which will be used when softmac fast-path is > not used. An opaque pointer will be passed into this function > to keep softmac specific state associated with the given stream. > > int dld_str_close(queue_t *); > > This function will be called by softmac to finish up the dld stream > operation and destroy dld related structures. > > void *dld_str_private(queue_t *); > > This function will be called to query the opaque pointer associated > with the given stream. > > - the mac_capab_legacy_t structure (Project Private) > > The mac_capab_legacy_t structure was introduced by PSARC/2008/002, > it is the data pointer of the MAC_CAPAB_LEGACY MAC capability. > > This case proposes to add the following fields to the data > structure: > > /* > * Info and callbacks of legacy devices. > */ > typedef struct mac_capab_legacy_s { > ... > int (*ml_fastpath_disable)(void *); > void (*ml_fastpath_enable)(void *); > boolean_t (*ml_active_set)(void *); > void (*ml_active_clear)(void *); > } mac_capab_legacy_t; > > The ml_fastpath_enable() and ml_fastpath_disable() callbacks > will be > called as the result of first mac_fastpath_disable() and last > mac_fastpath_enable() request on a particular softMAC. > > Further, to assure there is at most one exclusive active MAC > consumer > at a time (see [3]), we must prevent other exclusive active MAC > consumers when there is already IP/ARP stream on a softMAC, and > prevent > IP/ARP streams if there is already exclusive active MAC consumers. > This is done by the mac module calling the ml_active_set() and > ml_active_clear() callbacks to inform softmac the existence and > disappearance of an exclusive active MAC consumer. > > - the DL_NOTIFY_CONF primitive (M_PROTO type) (Project Private) > > The DL_NOTIFY_CONF primitive is similar to DL_NOTIFY_IND, but it is > notification sent from upstream (from a DLPI consumer to a DLPI > provider). > > DL_NOTIFY_CONF is a M_PROTO message with the following payload: > > typedef struct { > t_uscalar_t dl_primitive; /* set to DL_NOTIFY_CONF */ > uint32_t dl_notification; /* Which notification? */ > } dl_notify_conf_t; > > The only dl_notification type we will support is > DL_NOTE_REPLUMB_DONE. > > - the DL_NOTE_REPLUMB DL_NOTIFY_IND message (Project Private) > > As described above, the DL_NOTE_REPLUMB message is sent by softmac > to inform the IP/ARP upstream to "replumb" the stream. > > References > ========== > > [1] PSARC 2006/499 Clearview Nemo unification and vanity naming - > http://sac.sfbay/PSARC/2006/499/ > [2] PSARC 2008/002 Clearview UV Updates - > http://sac.sfbay/PSARC/2008/002/ > [3] PSARC 2005/207 Clearview for Nemo - > http://sac.sfbay/PSARC/2005/207/ From pdurrant@gmail.com Tue Apr 8 02:03:58 2008 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 m3893vZE020899 for ; Tue, 8 Apr 2008 02:03:57 -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 m3893biZ017214 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Apr 2008 17:03:56 +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 <0JZ00051316JLU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 02:03:55 -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 <0JZ0006QI16IWE70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 02:03:54 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m388w3VZ014785 for ; Tue, 08 Apr 2008 09:03:54 +0000 (GMT) Received: from mmp14es.sun.com ([160.41.209.24] [160.41.209.24]) by relay14i.sun.com with ESMTP id BT-MMP-499770 for PSARC-ext@sun.com; Tue, 08 Apr 2008 09:03:54 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.sun.com with ESMTP id BT-MMP-225436 for PSARC-ext@sun.com; Tue, 08 Apr 2008 09:03:53 +0000 (Z) Received: from nf-out-0910.google.com ([64.233.182.189] [64.233.182.189]) by relay1ib.sun.com with ESMTP id BT-MMP-5306817 for PSARC-ext@sun.com; Tue, 08 Apr 2008 09:03:53 +0000 (Z) Received: by nf-out-0910.google.com with SMTP id b11so826207nfh.48 for ; Tue, 08 Apr 2008 02:02:58 -0700 (PDT) Received: by 10.78.161.4 with SMTP id j4mr140609hue.86.1207645378033; Tue, 08 Apr 2008 02:02:58 -0700 (PDT) Received: from ?10.17.20.48? ( [82.69.137.158]) by mx.google.com with ESMTPS id f6sm5899781nfh.21.2008.04.08.02.02.56 (version=TLSv1/SSLv3 cipher=RC4-MD5) ; Tue, 08 Apr 2008 02:02:56 -0700 (PDT) Date: Tue, 08 Apr 2008 10:02:55 +0100 From: Paul Durrant Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAF097.1030402@sun.com> To: "Garrett D'Amore" Cc: Sebastien Roy , PSARC-ext@sun.com, Clearview Discuss Message-id: <47FB34BF.9020405@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=sn5gdgVi5C9xhry1AzkMJwOOjlTsm6dGdtca2ELpqfY=; b=L/Anvg9ZdGGhIMeKb30dHpVPYtFDELYIIdQairYBM81IlhqdIAO4gmzsnQygr08riGMHuuSktJmMCgf+XRQQ2vhKF5+pHbV26zlYv4bJeihhBf3h/4FpKxqleQb+TaRxc4/nk2S9kZ7eEL9HHOP5Bl1b6JCX28hZjvGdKNifIGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Pajgc3j/5NVAbDKA6EPCFHgN1Uk0XhNjzc+f6HhWldfzWMVliofjDPJ8bQmP8Tqc8kp+y6NleLsBqAgY5TiRBr0pGKe5AxkWEpholaQNtslhQ10UYZoZ0PSDA8TInWVDJCQ7l5TEJ7uo0CUKzA1zsAk+YixarhmHEOzyt6jmHG8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.047sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 422 Garrett D'Amore wrote: > > Far far better, IMO, is to "fix" the main driver this case is for > (cassini), which architecturally could easily be converted to GLDv3 and > bundled into Nevada, and then spend effort to wrap up GLDv3 enough to > publish it for 3rd parties. > Completely agree. Adding complexity to GLDv3 to work around a performance issue that exists for one driver seems completely backwards. Paul From Darren.Reed@Sun.COM Tue Apr 8 15:04:38 2008 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 m38M4bvF012721 for ; Tue, 8 Apr 2008 15:04: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 m38M4ZN0018687 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Apr 2008 06:04:36 +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 <0JZ100G091BLFS00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 Apr 2008 16:04:33 -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 <0JZ1007KN1BJBH60@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 Apr 2008 16:04:32 -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 m38M51VK001304 for ; Tue, 08 Apr 2008 22:05:01 +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 <0JZ100G0112A5Z00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 06:04:00 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ100BCO1AMRGU4@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Apr 2008 06:04:00 +0800 (SGT) Date: Tue, 08 Apr 2008 15:04:28 -0700 From: Darren Reed Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAF097.1030402@sun.com> Sender: Darren.Reed@Sun.COM To: "Garrett D'Amore" Cc: Sebastien Roy , PSARC-EXT Message-id: <47FBEBEC.6050506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 12210 Garrett D'Amore wrote: > As a general architectural comment here, I want to point out that I > feel that this case introduces additional complexity, that should be > unnecessary -- performance critical NICs should be written to GLDv3. > (The fact that GLDv3's API is still private is another matter > altogether -- but I believe introducing this code to address a > "performance issue" with a certain NIC product, is the wrong way to go > here.) > > Far far better, IMO, is to "fix" the main driver this case is for > (cassini), which architecturally could easily be converted to GLDv3 > and bundled into Nevada, and then spend effort to wrap up GLDv3 enough > to publish it for 3rd parties. And this would be the second or third "hack" (with PSARC case) to support cassini with special code because it isn't a GLDv3 driver? You've got to wonder if/when the rot will stop at the management (or business) level that fails to understand what the correct direction is here. Darren > > > -- Garrett > > Sebastien Roy wrote: > >> I'm submitting this fast-track for Cathy Zhou. The timer is set for >> April 14th, 2008. >> >> Data Fast-Path for Softmac >> ========================== >> >> Release binding: Patch >> >> Summary >> ======= >> >> This case introduces a GLDv3 fast-path architecture for softmac >> devices. >> The softmac architecture defined by PSARC/2006/499 initially >> contained >> a fast-path which was not delivered with Clearview UV as >> discussed in >> section 2.1 of PSARC/2008/002. PSARC/2008/002 states that an >> alternative >> fast-path architecture would be defined in a future case, and >> that is >> this case. >> >> Details >> ======= >> >> - Data fast-path and slow-path >> >> Currently, the softmac module discovers each legacy network device >> and registers (soft)MACs to the GLDv3 framework on behalf of these >> legacy devices. Whenever a softMAC is used, the softmac module >> opens >> a DLIOCRAW stream over the legacy device, and enables >> DL_PROMISC_SAP >> promiscuous mode on the stream. This DLIOCRAW stream is then >> shared >> by all data packets sent and received over this softMAC. We >> call this >> DLIOCRAW stream "shared lower stream". >> >> Although the above is consistent with the existing GLDv3 model and >> requires less changes to the GLDv3 framework, it introduces >> unacceptable performance regression over legacy devices, >> because of >> the extra data demultiplexing and filtering processing in the >> GLDv3 >> DLS/MAC layer. >> >> Therefore, this case proposes a softmac data fast-path >> architecture >> which is less intrusive to the current Solaris network >> architecture >> and will address the performance issue of the above approach: >> >> Specifically, when the fast-path is used, a dedicated lower-stream >> will be opened over the legacy device for each IP/ARP >> (upper-)stream >> over the softMAC, and all DLPI messages (including control >> messages >> and data messages) will be exchanged between the upper-stream and >> the corresponding lower-stream directly. Therefore, the data >> demultiplexing, filtering and classification processing will be >> done >> by the lower-stream, and the GLDv3 DLS/MAC layer processing >> will be >> no longer needed. >> >> Note that some GLDv3 features requires the GLDv3 DLS/MAC layer >> processing to not be bypassed to assure its function correctness. >> For example, softmac fast-path must be disabled to support GLDv3 >> VNIC functionality. As the result, we propose: By default, the >> softmac fast-path mode will be used to assure the performance; MAC >> clients will be able to request to disable the softmac fast-path >> mode to support certain features, and if that succeeds, the system >> will fallback to the existing softmac data-path model (called >> slow-path). >> >> The details of the new softmac data fast-path model is stated >> as below >> (note that the softmac fast-path will only be used for the IP/ARP >> streams over softMACs, which is the case performance matters >> most): >> >> 1. When a stream (including a VLAN stream) is opened on a softMAC, >> the softmac module will takes over the DLPI processing on this >> stream; >> >> 2. For IP/ARP streams over a softMAC, softmac data fast-path >> will be >> used by default, unless fast-path is disabled by any MAC client >> explicitly. The softmac module first identifies an IP/ARP >> stream >> by seeing whether there is a SIOCSLIFNAME ioctl sent from >> upstream, >> if there is one, this stream is either an IP or an ARP stream >> and will use fast-path potentially; >> >> 3. When the softmac fast-path is used, an dedicated >> lower-stream will >> be setup for each IP/ARP stream (1-1 mapping). From that >> point on, >> all control and data messages will be exchanged between the >> IP/ARP >> upper-stream and the legacy device through this dedicated >> lower-stream. As a result, the DLS/MAC layer processing in >> GLDv3 >> will be skipped, and this greatly improves the performance; >> >> 4. When the softmac data fast-path is disabled by a MAC client >> (e.g., >> by a VNIC), all the IP/ARP upper streams will try to switch >> from >> the fast-path to the slow-path. The dedicated lower-stream >> will be >> destroyed, and all the control and data-messages will go >> through >> the existing GLDv3 code path and (in the end) the shared >> lower-stream; >> >> 5. On the other hand, when the last MAC client cancels its >> fast-path >> disable request, all the IP/ARP streams will try to switch >> back to >> the fast-path mode; >> >> Step 5 and 6 both rely on the data-path mode switching process >> described below: >> >> 1) To switch the softmac data-path mode (between fast-path and >> slow-path), softmac will first send a DL_NOTE_REPLUMB >> DL_NOTIFY_IND message upstream over each IP/ARP streams that >> needs data-path mode switching; >> >> 2) When IP receives this DL_NOTE_REPLUMB message, it will bring >> down all the IP interfaces on the corresponding ill (IP >> Lower >> level structure), and bring up those interfaces over again; >> this will in turn cause the ARP to "replumb" the interface. >> >> During the replumb process, both IP and ARP will send >> downstream the necessary DL_DISABMULTI_REQ and DL_UNBIND_REQ >> messages and cleanup the old state of the underlying >> softMAC, >> following with the necessary DL_BIND_REQ and >> DL_ENABMULTI_REQ >> messages to setup the new state. Between the cleanup and >> re-setup >> process, IP/ARP will also send down a DL_NOTE_REPLUMB_DONE >> DL_NOTIFY_CONF messages to the softMAC to indicate the >> *switching point*; >> >> 3) When softmac receives the DL_NOTE_REPLUMB_DONE message, it >> either creates or destroys the dedicated lower-stream >> (depending >> on which data-path mode the softMAC switches to), and change >> the softmac data-path mode. From then on, softmac will >> process >> all the succeeding control messages (including the >> DL_BIND_REQ and >> DL_ENABMULTI_REQ messages) and data messages based on new >> data-path mode. >> >> Interfaces >> ========== >> >> - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation >> Private) >> >> Two MAC client interfaces will be added: >> >> int mac_fastpath_disable(mac_handle_t); >> >> This function will be called when a mac client requires to disable >> the softmac data fast-path over a specific mac. It will return >> errno >> in case that the fast-path is failed to be disabled. If the >> given mac >> is a mac over a GLDv3 device, 0 (success) will be directly >> returned. >> >> void mac_fastpath_enable(mac_handle_t); >> >> The mac_fastpath_enable() function will be called when a mac >> client >> cancels its softmac fast-path disabling requests over a >> specific mac. >> When the last fast-path disabling request is canceled, the >> underlying >> softmac will try to reenable the data fast-path. It is not >> considered >> as a failure if fast-path fails to be reenabled, as that will only >> have performance impact. >> >> - dld_str_open()/dld_str_close()/dld_str_private() (Project Private) >> >> Three new dls interfaces will be added: >> >> int dld_str_open(queue_t *, dev_t *, void *opaque); >> >> This function will be called by softmac to setup the dld stream >> related structures, which will be used when softmac fast-path is >> not used. An opaque pointer will be passed into this function >> to keep softmac specific state associated with the given stream. >> >> int dld_str_close(queue_t *); >> >> This function will be called by softmac to finish up the dld >> stream >> operation and destroy dld related structures. >> >> void *dld_str_private(queue_t *); >> >> This function will be called to query the opaque pointer >> associated >> with the given stream. >> >> - the mac_capab_legacy_t structure (Project Private) >> >> The mac_capab_legacy_t structure was introduced by PSARC/2008/002, >> it is the data pointer of the MAC_CAPAB_LEGACY MAC capability. >> >> This case proposes to add the following fields to the data >> structure: >> >> /* >> * Info and callbacks of legacy devices. >> */ >> typedef struct mac_capab_legacy_s { >> ... >> int (*ml_fastpath_disable)(void *); >> void (*ml_fastpath_enable)(void *); >> boolean_t (*ml_active_set)(void *); >> void (*ml_active_clear)(void *); >> } mac_capab_legacy_t; >> >> The ml_fastpath_enable() and ml_fastpath_disable() callbacks >> will be >> called as the result of first mac_fastpath_disable() and last >> mac_fastpath_enable() request on a particular softMAC. >> >> Further, to assure there is at most one exclusive active MAC >> consumer >> at a time (see [3]), we must prevent other exclusive active MAC >> consumers when there is already IP/ARP stream on a softMAC, and >> prevent >> IP/ARP streams if there is already exclusive active MAC consumers. >> This is done by the mac module calling the ml_active_set() and >> ml_active_clear() callbacks to inform softmac the existence and >> disappearance of an exclusive active MAC consumer. >> >> - the DL_NOTIFY_CONF primitive (M_PROTO type) (Project Private) >> >> The DL_NOTIFY_CONF primitive is similar to DL_NOTIFY_IND, but >> it is >> notification sent from upstream (from a DLPI consumer to a DLPI >> provider). >> >> DL_NOTIFY_CONF is a M_PROTO message with the following payload: >> >> typedef struct { >> t_uscalar_t dl_primitive; /* set to DL_NOTIFY_CONF */ >> uint32_t dl_notification; /* Which notification? */ >> } dl_notify_conf_t; >> >> The only dl_notification type we will support is >> DL_NOTE_REPLUMB_DONE. >> >> - the DL_NOTE_REPLUMB DL_NOTIFY_IND message (Project Private) >> >> As described above, the DL_NOTE_REPLUMB message is sent by softmac >> to inform the IP/ARP upstream to "replumb" the stream. >> >> References >> ========== >> >> [1] PSARC 2006/499 Clearview Nemo unification and vanity naming - >> http://sac.sfbay/PSARC/2006/499/ >> [2] PSARC 2008/002 Clearview UV Updates - >> http://sac.sfbay/PSARC/2008/002/ >> [3] PSARC 2005/207 Clearview for Nemo - >> http://sac.sfbay/PSARC/2005/207/ > > From Cathy.Zhou@sun.com Tue Apr 8 16:06:34 2008 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 m38N6Xg5016843 for ; Tue, 8 Apr 2008 16:06:33 -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 m38N6VjK009803 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 07:06:32 +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 <0JZ100J0946VOR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 16:06:31 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ100D8Z46KJOA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 16:06:30 -0700 (PDT) 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 m38N6oVb002395 for ; Tue, 08 Apr 2008 23:06:50 +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 <0JZ100G0140IL700@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:05:49 +0800 (SGT) Received: from [129.146.105.122] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ100B1O45NRFH9@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:05:48 +0800 (SGT) Date: Tue, 08 Apr 2008 16:06:09 -0700 From: Cathy Zhou Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <47FB34BF.9020405@gmail.com> Sender: Cathy.Zhou@sun.com To: Paul Durrant Cc: "Garrett D'Amore" , Sebastien Roy , PSARC-ext@sun.com, Clearview Discuss Message-id: <47FBFA61.7030706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 1159 Paul Durrant wrote: > Garrett D'Amore wrote: >> >> Far far better, IMO, is to "fix" the main driver this case is for >> (cassini), which architecturally could easily be converted to GLDv3 >> and bundled into Nevada, and then spend effort to wrap up GLDv3 enough >> to publish it for 3rd parties. >> > > Completely agree. Adding complexity to GLDv3 to work around a > performance issue that exists for one driver seems completely backwards. > I agree with you to some extend. Unfortunately cassini (ce) is still a very popular legacy driver that is used on lots of Solaris system. Further, our GLDv3 driver APIs are not made public yet. Before that happens, we will have to make the legacy driver performs well enough. Also, please note that the proposal we proposed here is not invasive to the current GLDv3 framework at all. Most of the fastpath enhancement is in softmac itself. We do introduced the new DL_NOTE_REPLUMB and DL_NOTE_REPLUMB_DONE message, but how IP handling those new messages are mostly existing code path, and it will be very easy to remove them if it proves there is no legacy driver requires this one day. Thanks - Cathy From peter.memishian@sun.com Tue Apr 8 16:12:24 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m38NCOC9017497 for ; Tue, 8 Apr 2008 16:12:24 -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 m38NCMHV010253; Tue, 8 Apr 2008 16:12: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 <0JZ100B074GMPJ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 Apr 2008 16:12:22 -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 <0JZ10043H4G5SM50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 Apr 2008 16:12:06 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m38NC4QS060572; Tue, 08 Apr 2008 19:12:04 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m38NC4W2553040; Tue, 08 Apr 2008 19:12:04 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m38NC4tm553037; Tue, 08 Apr 2008 19:12:04 -0400 (EDT) Date: Tue, 08 Apr 2008 19:12:04 -0400 From: Peter Memishian Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <47FB34BF.9020405@gmail.com> To: Paul Durrant Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Clearview Discuss , Sebastien Roy Reply-to: peter.memishian@sun.com Message-id: <18427.64452.346068.124867@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 828 > > Far far better, IMO, is to "fix" the main driver this case is for > > (cassini), which architecturally could easily be converted to GLDv3 and > > bundled into Nevada, and then spend effort to wrap up GLDv3 enough to > > publish it for 3rd parties. > > Completely agree. Adding complexity to GLDv3 to work around a > performance issue that exists for one driver seems completely backwards. It's not just one driver -- until GLDv3 is published, other third-party drivers, such as the Fujitsu ones and the SysKonnect ones will need this fastpath to preserve performance. This code is seperable and we will be happy to remove it when it is no longer needed. However, until the GLDv3 API is public (which cannot happen at least until Crossbow integrates), we need this to preserve performance in Nevada. -- meem From peter.memishian@sun.com Tue Apr 8 16:15:55 2008 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 m38NFtXx017734 for ; Tue, 8 Apr 2008 16:15:55 -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 m38NFoUa016226; Tue, 8 Apr 2008 17:15:54 -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 <0JZ100K1T4MH5900@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Apr 2008 16:15:53 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ100DLQ4MHJUA0@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Apr 2008 16:15:53 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m38NFpcH001763; Tue, 08 Apr 2008 19:15:51 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m38NFpZn553575; Tue, 08 Apr 2008 19:15:51 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m38NFpES553572; Tue, 08 Apr 2008 19:15:51 -0400 (EDT) Date: Tue, 08 Apr 2008 19:15:51 -0400 From: Peter Memishian Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <18427.64452.346068.124867@gargle.gargle.HOWL> To: peter.memishian@sun.com Cc: Paul Durrant , PSARC-ext@sun.com, Clearview Discuss , Sebastien Roy , "Garrett D'Amore" Reply-to: peter.memishian@sun.com Message-id: <18427.64679.62354.530919@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> <18427.64452.346068.124867@gargle.gargle.HOWL> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 247 > It's not just one driver -- until GLDv3 is published, other third-party > drivers, such as the Fujitsu ones and the SysKonnect ones will need this > fastpath to preserve performance. Sorry, I meant to say "gigabit drivers" above. -- meem From Cathy.Zhou@sun.com Tue Apr 8 16:16:19 2008 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 m38NGI0B017772 for ; Tue, 8 Apr 2008 16:16:19 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m38NG7WH024685 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 00:16:17 +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 <0JZ100C2L4N31F00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 16:16:15 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ1004O04N0SC40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Apr 2008 16:16:13 -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 m38NGOBO007005 for ; Tue, 08 Apr 2008 23:16:24 +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 <0JZ1009014GUI700@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:16:04 +0800 (SGT) Received: from [129.146.105.122] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ1004CO4MQPGQ9@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:16:04 +0800 (SGT) Date: Tue, 08 Apr 2008 16:16:01 -0700 From: Cathy Zhou Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAEB9A.90808@Sun.COM> Sender: Cathy.Zhou@sun.com To: Darren Reed Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <47FBFCB1.6050301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAC8D5.2010205@Sun.COM> <47FAE415.5050501@sun.com> <47FAEB9A.90808@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 2503 Darren Reed wrotecture of this project be changed or expanded >>> to include dealing with the VNIC functionality problem? >>> >> I am not clear what your question is. Note that VNIC is going to be >> supported on legacy device as part of this case. But once VNIC is >> configured, fastpath will be disabled. > > > Let me approach this from a different angle... > > What sort of architectural problems exist that prevent this > fast-path project from being extended to supporting VNICs? > I can give an example here: assumes there is a VNIC (vnic0) configured on legacy device (say, ce0), we could plumb vnic0 and ce0, and the traffic sent over ce0 needs to loopback by the MAC layer if the traffic is destined to vnic0. In the case that fast-path is used, traffic sent over ce0 will directly passed to the softmac and will skip the MAC layer, and cannot be looped back to vnic0. > >>>> 2. For IP/ARP streams over a softMAC, softmac data fast-path >>>> will be >>>> used by default, unless fast-path is disabled by any MAC >>>> client >>>> explicitly. The softmac module first identifies an IP/ARP >>>> stream >>>> by seeing whether there is a SIOCSLIFNAME ioctl sent from >>>> upstream, >>>> if there is one, this stream is either an IP or an ARP stream >>>> and will use fast-path potentially; >>> >>> >>> >>> Why are you looking at the SIOCSLIFNAME ioctl rather than >>> the bind? As defined, SIOCSLIFNAME does not appear to be >>> IP specific at all, aside from our implementation and use. >>> >> I thought SIOCSLIFNAME is a private ioctl and should not be used by >> others other than IP. Please correct me if I am wrong. > > > Let me approach this from a different angle... > > Architecturally, you seem to have chosen to use a private > ioctl that has some predefined characteristics that _imply_ > IP rather than a public one (the bind) which informs you > exactly about whether or not it is IP, ARP, etc. That is > the choice to use SIOCSLIFNAME as the trigger appears weaker > than using the bind. Why did you make this choice? > Because we needs to determine whether the upstream is a "fastpath candidate" at the very early phase when the upstream is plumbed. Each DLPI control messages (including the ones comes before DL_BIND_REQ) will then be directly passed to the underlying dedicated lower-stream, or be passed to the normal GLDv3 processing, based on whether fast-path is used or not. Thanks - Cathy From gdamore@sun.com Wed Apr 9 07:52:32 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m39EqWZ9012366 for ; Wed, 9 Apr 2008 07:52:32 -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 m39EqUk1025613 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 07:52:32 -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 <0JZ200C2RBZJOQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:52:31 -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 <0JZ200B4BBZIIM20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:52:30 -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 m39EqTX3009921 for ; Wed, 09 Apr 2008 07:52:29 -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 <0JZ200201BPUDY00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:52:29 -0700 (PDT) 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 <0JZ2008JCBZH8I30@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 07:52:29 -0700 (PDT) Date: Wed, 09 Apr 2008 07:48:30 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <18427.64452.346068.124867@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: Paul Durrant , PSARC-ext@sun.com, Clearview Discuss , Sebastien Roy Message-id: <47FCD73E.2090401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> <18427.64452.346068.124867@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1797 Peter Memishian wrote: > > > Far far better, IMO, is to "fix" the main driver this case is for > > > (cassini), which architecturally could easily be converted to GLDv3 and > > > bundled into Nevada, and then spend effort to wrap up GLDv3 enough to > > > publish it for 3rd parties. > > > > Completely agree. Adding complexity to GLDv3 to work around a > > performance issue that exists for one driver seems completely backwards. > > It's not just one driver -- until GLDv3 is published, other third-party > drivers, such as the Fujitsu ones and the SysKonnect ones will need this > fastpath to preserve performance. > > This code is seperable and we will be happy to remove it when it is no > longer needed. However, until the GLDv3 API is public (which cannot > happen at least until Crossbow integrates), we need this to preserve > performance in Nevada. > Once it goes in, it will essentially *never* be removable. Because it will cause regressions for *some* driver (most likely that NSN driver....) The other vendors will probably be *happy* to convert to GLDv3, if we just publish the damned API. And I think we're close to it. Btw, maybe its time to either look at versioning the API, or at least look at the impact that Crossbow will have on it. I'm not worried about things that add features, but will Crossbow create incompatible changes to the driver API (not just enhancements)? Obviously, I'm not a member of NSN nor of networking (anymore), so my vote counts for little. But I really think we need to be spending our time trying to get everyone to use GLDv3. "Enabling" those legacy APIs means that no one is incentivized to to update, and we'll be carrying around the baggage until the next major release of Solaris. (SunOS 6.x) -- Garrett From peter.memishian@sun.com Wed Apr 9 14:23:02 2008 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 m39LN2cQ004410 for ; Wed, 9 Apr 2008 14:23:02 -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 m39LN0dt057938; Wed, 9 Apr 2008 15:23:01 -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 <0JZ200M0VU2CTU00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Apr 2008 14:23:00 -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 <0JZ200JSYU2A7W20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Apr 2008 14:22:59 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m39LMvi8039055; Wed, 09 Apr 2008 17:22:57 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m39LMvEL952131; Wed, 09 Apr 2008 17:22:57 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m39LMupr951887; Wed, 09 Apr 2008 17:22:56 -0400 (EDT) Date: Wed, 09 Apr 2008 17:22:56 -0400 From: Peter Memishian Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <47FCD73E.2090401@sun.com> To: "Garrett D'Amore" Cc: peter.memishian@sun.com, Paul Durrant , PSARC-ext@sun.com, Clearview Discuss , Sebastien Roy Reply-to: peter.memishian@sun.com Message-id: <18429.13232.8498.176319@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> <18427.64452.346068.124867@gargle.gargle.HOWL> <47FCD73E.2090401@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 509 > > This code is seperable and we will be happy to remove it when it is no > > longer needed. However, until the GLDv3 API is public (which cannot > > happen at least until Crossbow integrates), we need this to preserve > > performance in Nevada. > > Once it goes in, it will essentially *never* be removable. That's not true -- both because the performance of gigabit will become less important and easier to satisfy, and because conversion will become feasible once APIs are published. -- meem From gdamore@sun.com Wed Apr 9 15:04:57 2008 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 m39M4uLb006671 for ; Wed, 9 Apr 2008 15:04:57 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m39M4s4x022613 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 23:04: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 <0JZ20032TW06FA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 15:04: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 <0JZ200JG6W057T70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 15:04:54 -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 m39M4rUO009031 for ; Wed, 09 Apr 2008 15:04:53 -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 <0JZ200001VKHJU00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 15:04:53 -0700 (PDT) Received: from [192.168.251.106] ([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 <0JZ200FZIVZWGYC0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 15:04:45 -0700 (PDT) Date: Wed, 09 Apr 2008 15:00:46 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <18429.13232.8498.176319@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: Paul Durrant , PSARC-ext@sun.com, Clearview Discuss , Sebastien Roy Message-id: <47FD3C8E.8000404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> <18427.64452.346068.124867@gargle.gargle.HOWL> <47FCD73E.2090401@sun.com> <18429.13232.8498.176319@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1884 Peter Memishian wrote: > > > This code is seperable and we will be happy to remove it when it is no > > > longer needed. However, until the GLDv3 API is public (which cannot > > > happen at least until Crossbow integrates), we need this to preserve > > > performance in Nevada. > > > > Once it goes in, it will essentially *never* be removable. > > That's not true -- both because the performance of gigabit will become > less important and easier to satisfy, and because conversion will become > feasible once APIs are published. > I'm sorry, but you must have your head in the ground. A published API is *not* what is keeping from Cassini from porting to GLDv3. Until performance of Cassini on current hardware ceases to be a concern of interest, we will be stuck. Its likely therefore that this hack will have to live for at least a decade -- until we are able to EOSL Cassini. (And yes, I know that this is true! I offered to supply a GLDv3 version of ce to the current management of ce, with a promise of no perf. regressions or at least negligible perf. regressions, plus numerous added benefits, for integration into Nevada, and NSN flatly turned me down. The political cost of a GLDv3 cassini driver is for reasons not understood to me, far far higher than the actual technical cost of producing one.) Get management to buy into a Cassini GLDv3 port, and the other parties will follow suit. SysKonnect, and Fujitsu could easily get contracts, or get into uts/closed, if that were important to them, so they could become part of ON (and thus not need a contract). I don't think we really care about dropping perf. on those products anyway, once we have a GLDv3 published. All that said, the fast path described here *may* be required for S10. I'm not sure. But I more or less resent the idea of such hackery in Nevada. -- Garrett From Sebastien.Roy@sun.com Wed Apr 9 15:14:54 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m39MEs4Z007974 for ; Wed, 9 Apr 2008 15:14:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m39MEpYt006905 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 15:14:54 -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 <0JZ200421WGU7F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 15:14:54 -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 <0JZ200I2VWGSE4B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 15:14:53 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39MEqnJ007155 for ; Wed, 09 Apr 2008 22:14: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 <0JZ200301WG6NL00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 16:14:52 -0600 (MDT) Received: from [192.168.1.3] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZ200ML4WGMKQ90@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 16:14:48 -0600 (MDT) Date: Wed, 09 Apr 2008 18:14:46 -0400 From: Sebastien Roy Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <47FD3C8E.8000404@sun.com> Sender: Sebastien.Roy@sun.com To: "Garrett D'Amore" Cc: Peter.Memishian@sun.com, Clearview Discuss , PSARC-ext@sun.com Message-id: <47FD3FD6.5030201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> <18427.64452.346068.124867@gargle.gargle.HOWL> <47FCD73E.2090401@sun.com> <18429.13232.8498.176319@gargle.gargle.HOWL> <47FD3C8E.8000404@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 608 Garrett D'Amore wrote: > Peter Memishian wrote: >> That's not true -- both because the performance of gigabit will become >> less important and easier to satisfy, and because conversion will become >> feasible once APIs are published. >> > > I'm sorry, but you must have your head in the ground. Point of order please. I would request that everyone be civil and polite to project teams whose projects are being reviewed. This tone is uncalled for. If you don't think that your point is being understood clearly over email, then perhaps a phone call would do the trick. I can arrange that. -Seb From gdamore@sun.com Wed Apr 9 18:38:05 2008 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 m3A1c51w014001 for ; Wed, 9 Apr 2008 18:38:05 -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 m3A1c4CD056521 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 19:38:04 -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 <0JZ3000035VGPS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 18:38:04 -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 <0JZ300DRF5VGCR50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 18:38:04 -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 m3A1c4SF027486 for ; Wed, 09 Apr 2008 18:38:04 -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 <0JZ300H015TYME00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 18:38:04 -0700 (PDT) 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 <0JZ300A395VF83B0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Apr 2008 18:38:04 -0700 (PDT) Date: Wed, 09 Apr 2008 18:34:03 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <47FD3FD6.5030201@sun.com> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: Peter.Memishian@sun.com, Clearview Discuss , PSARC-ext@sun.com Message-id: <47FD6E8B.3090102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FAF097.1030402@sun.com> <47FB34BF.9020405@gmail.com> <18427.64452.346068.124867@gargle.gargle.HOWL> <47FCD73E.2090401@sun.com> <18429.13232.8498.176319@gargle.gargle.HOWL> <47FD3C8E.8000404@sun.com> <47FD3FD6.5030201@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 828 Sebastien Roy wrote: > Garrett D'Amore wrote: >> Peter Memishian wrote: >>> That's not true -- both because the performance of gigabit will become >>> less important and easier to satisfy, and because conversion will >>> become >>> feasible once APIs are published. >>> >> >> I'm sorry, but you must have your head in the ground. > > Point of order please. I would request that everyone be civil and > polite to project teams whose projects are being reviewed. This tone > is uncalled for. If you don't think that your point is being > understood clearly over email, then perhaps a phone call would do the > trick. I can arrange that. I apologize to Peter, and to anyone else that may be involved. I think I let my own particular emotional frustrations escape and get the better of me. -- Garrett > > -Seb From erik.nordmark@sun.com Fri Apr 11 14:17:23 2008 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 m3BLHNq5024893 for ; Fri, 11 Apr 2008 14:17:23 -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 m3BLHEnH048001; Fri, 11 Apr 2008 15:17:22 -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 <0JZ600H01J4XSA00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 11 Apr 2008 14:17:21 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ6001MMJ4XINF0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 11 Apr 2008 14:17:21 -0700 (PDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3BLHGcC371769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 14:17:17 -0700 (PDT) Date: Fri, 11 Apr 2008 14:17:16 -0700 From: Erik Nordmark Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAA2B3.2080900@sun.com> To: Sebastien Roy Cc: PSARC-ext@sun.com, Clearview Discuss Message-id: <47FFD55C.7020002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1084 Sebastien Roy wrote: > Interfaces > ========== > > - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation Private) Why can't those be project private? Presumably no MAC driver other that softmac should ever use this. > /* > * Info and callbacks of legacy devices. > */ > typedef struct mac_capab_legacy_s { > ... > int (*ml_fastpath_disable)(void *); > void (*ml_fastpath_enable)(void *); > boolean_t (*ml_active_set)(void *); > void (*ml_active_clear)(void *); > } mac_capab_legacy_t; > > The ml_fastpath_enable() and ml_fastpath_disable() callbacks will be > called as the result of first mac_fastpath_disable() and last > mac_fastpath_enable() request on a particular softMAC. Having them appear here means that the implementor of any MAC driver needs to understand whether or not they should implement those functions. Is there a way we can avoid them having to think about it given that only softmac will ever need to use this? Erik From Cathy.Zhou@sun.com Mon Apr 14 09:40:15 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3EGeFRW014585 for ; Mon, 14 Apr 2008 09:40:15 -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 m3EGe6oO021964 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Apr 2008 09:40:15 -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 <0JZB00B2TQB18E00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 10:40:13 -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 <0JZB00KOWQAZHOC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 10:40:12 -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 m3EGehLQ014399 for ; Mon, 14 Apr 2008 16:40:43 +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 <0JZB00101QANSP00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Apr 2008 00:40:03 +0800 (SGT) Received: from [129.146.105.122] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZB007IBQAQUHJ5@mail-apac.sun.com>; Tue, 15 Apr 2008 00:40:03 +0800 (SGT) Date: Mon, 14 Apr 2008 09:39:56 -0700 From: Cathy Zhou Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <47FFD55C.7020002@sun.com> Sender: Cathy.Zhou@sun.com To: Erik Nordmark Cc: Sebastien Roy , PSARC-ext@sun.com, Clearview Discuss Message-id: <480388DC.8030105@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 1670 Erik Nordmark wrote: > Sebastien Roy wrote: > >> Interfaces >> ========== >> >> - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation Private) > > Why can't those be project private? Presumably no MAC driver other that > softmac should ever use this. > These are not used by softmac driver. They are used by mac clients. At this point only the vnic driver will need to call these functions. But it could be used by any MAC clients that don't work with fast-path. >> /* >> * Info and callbacks of legacy devices. >> */ >> typedef struct mac_capab_legacy_s { >> ... >> int (*ml_fastpath_disable)(void *); >> void (*ml_fastpath_enable)(void *); >> boolean_t (*ml_active_set)(void *); >> void (*ml_active_clear)(void *); >> } mac_capab_legacy_t; >> >> The ml_fastpath_enable() and ml_fastpath_disable() callbacks will be >> called as the result of first mac_fastpath_disable() and last >> mac_fastpath_enable() request on a particular softMAC. > > Having them appear here means that the implementor of any MAC driver > needs to understand whether or not they should implement those > functions. Is there a way we can avoid them having to think about it > given that only softmac will ever need to use this? > It is not true. Only a GLDv3 driver which supports MAC_CAPAB_LEGACY capability needs to implement those callbacks, and softmac is the only GLDv3 driver capable of MAC_CAPAB_LEGACY. Thanks - Cathy > Erik > > _________________________________ > clearview-discuss mailing list > clearview-discuss@opensolaris.org From gdamore@sun.com Mon Apr 14 09:53:12 2008 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 m3EGrBPx014868 for ; Mon, 14 Apr 2008 09:53:11 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3EGr4VH025520 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Apr 2008 17:53:10 +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 <0JZB00B0PQWJ2400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 09:53: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 <0JZB00459QWHNVD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 09:53:06 -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 m3EGr5lJ026923 for ; Mon, 14 Apr 2008 09:53:05 -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 <0JZB00201QHVML00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 09:53:05 -0700 (PDT) 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 <0JZB00MMXQWEE600@fe-sfbay-09.sun.com>; Mon, 14 Apr 2008 09:53:02 -0700 (PDT) Date: Mon, 14 Apr 2008 09:48:47 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <480388DC.8030105@sun.com> Sender: Garrett.Damore@sun.com To: Cathy Zhou Cc: Erik Nordmark , Sebastien Roy , PSARC-ext@sun.com, Clearview Discuss Message-id: <48038AEF.4090806@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1624 Cathy Zhou wrote: > Erik Nordmark wrote: >> Sebastien Roy wrote: >> >>> Interfaces >>> ========== >>> >>> - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation >>> Private) >> >> Why can't those be project private? Presumably no MAC driver other >> that softmac should ever use this. >> > These are not used by softmac driver. They are used by mac clients. At > this point only the vnic driver will need to call these functions. But > it could be used by any MAC clients that don't work with fast-path. So the mac clients need to be aware of fast path? That sounds rather unfortunate -- given that the ultimate goal is to expose the mac client API someday. It seems like the details of this should be an implementation detail, that mac clients don't have to worry about. Perhaps more clearly, I don't want MAC clients to fail to function correctly if they don't enable this behavior. I'd rather have an explicit "enable" that is used by fast-path aware clients (probably only the IP stuff), and let all other clients automatically start without fast path enabled. That way if someone writes a mac client that doesn't know about fastpath, it will at least function properly. (Yes, I still believe that this whole fastpath mechanism is essentially a performance hack to work around a few crufty drivers that really should be updated to be pure GLDv3 drivers instead of moving this cruft into the framework. But on the assumption that we're going to move forward with this, lets at least limit the visibility of this API to minimize its architectural impact on the system.) -- Garrett From Robert.Gittins@sun.com Mon Apr 14 09:58:17 2008 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 m3EGwHcJ015407 for ; Mon, 14 Apr 2008 09:58:17 -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 m3EGwBip035024 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Apr 2008 10:58:16 -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 <0JZB00B13R527800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 09:58:14 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZB004C9R51O3D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 09:58:13 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3EGwDMv002267 for ; Mon, 14 Apr 2008 16:58:13 +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 <0JZB00F01P3BZ400@mail-amer.sun.com> (original mail from Robert.Gittins@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 10:58:13 -0600 (MDT) Received: from [129.150.35.196] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZB0027VR4KGBA0@mail-amer.sun.com>; Mon, 14 Apr 2008 10:57:58 -0600 (MDT) Date: Mon, 14 Apr 2008 10:56:52 -0600 From: Rob Gittins Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <48038AEF.4090806@sun.com> Sender: Robert.Gittins@sun.com To: "Garrett D'Amore" Cc: Cathy Zhou , Erik Nordmark , Sebastien Roy , PSARC-ext@sun.com, Clearview Discuss Reply-to: Robert.Gittins@sun.com Message-id: <48038CD4.9060202@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> <48038AEF.4090806@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071031) Status: RO Content-Length: 1773 I just wish we were a step ahead instead of 2 steps behind. Rob Garrett D'Amore wrote: > Cathy Zhou wrote: >> Erik Nordmark wrote: >>> Sebastien Roy wrote: >>> >>>> Interfaces >>>> ========== >>>> >>>> - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation >>>> Private) >>> >>> Why can't those be project private? Presumably no MAC driver other >>> that softmac should ever use this. >>> >> These are not used by softmac driver. They are used by mac clients. >> At this point only the vnic driver will need to call these functions. >> But it could be used by any MAC clients that don't work with fast-path. > > So the mac clients need to be aware of fast path? That sounds rather > unfortunate -- given that the ultimate goal is to expose the mac > client API someday. It seems like the details of this should be an > implementation detail, that mac clients don't have to worry about. > > Perhaps more clearly, I don't want MAC clients to fail to function > correctly if they don't enable this behavior. > > I'd rather have an explicit "enable" that is used by fast-path aware > clients (probably only the IP stuff), and let all other clients > automatically start without fast path enabled. That way if someone > writes a mac client that doesn't know about fastpath, it will at least > function properly. > > (Yes, I still believe that this whole fastpath mechanism is > essentially a performance hack to work around a few crufty drivers > that really should be updated to be pure GLDv3 drivers instead of > moving this cruft into the framework. But on the assumption that > we're going to move forward with this, lets at least limit the > visibility of this API to minimize its architectural impact on the > system.) > > -- Garrett From pdurrant@gmail.com Mon Apr 14 10:00:29 2008 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 m3EH0S65015494 for ; Mon, 14 Apr 2008 10:00:29 -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 m3EH0Kgf011992 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 15 Apr 2008 01:00:27 +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 <0JZB00B1JR8PAK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 10:00:25 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZB004SUR8OO5D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 10:00:25 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3EGc3v6029211 for ; Mon, 14 Apr 2008 17:00:24 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-237047 for PSARC-ext@sun.com; Mon, 14 Apr 2008 17:00:24 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-407358 for PSARC-ext@sun.com; Mon, 14 Apr 2008 17:00:24 +0000 (Z) Received: from fg-out-1718.google.com ([72.14.220.155] [72.14.220.155]) by relay4i.sun.com with ESMTP id BT-MMP-244546 for PSARC-ext@sun.com; Mon, 14 Apr 2008 17:00:24 +0000 (Z) Received: by fg-out-1718.google.com with SMTP id e12so1620392fga.6 for ; Mon, 14 Apr 2008 10:00:08 -0700 (PDT) Received: by 10.86.53.8 with SMTP id b8mr13816062fga.64.1208192030905; Mon, 14 Apr 2008 09:53:50 -0700 (PDT) Received: by 10.86.61.13 with HTTP; Mon, 14 Apr 2008 09:53:50 -0700 (PDT) Date: Mon, 14 Apr 2008 17:53:50 +0100 From: Paul Durrant Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <480388DC.8030105@sun.com> To: Cathy Zhou Cc: Erik Nordmark , PSARC-ext@sun.com, Clearview Discuss , Sebastien Roy Message-id: <112359b70804140953q4d2ded0dt8d878a0e1f77d01a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/Lk++FPl9iAPolW6F8tJ/DRiFOb/y/hJCIgbrsTKThE=; b=mhtUkPmYSqkHews/ND4CAZRWZW+T2mVhbPJNUeVy8cazoqgXRV/3GrURHJXJKiUp3nSro5XxIYkXwaith6Xgurv2e7JvQx5lJBol4k4ZXaWwO7fM2+kf1bicrQgumyS9x0ZxiuBOXQDgGuZkDD1snd5wstVD0/nxKeOvGngm/K4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZyogoRuAQ0RjXA483py4Mc5JGNh8UMblihzaOpgeB+d47KxszGtKeQhKLF2Ov84rmnzv1lJVgaAOXqwbBR5PhSYCAy8wyCkMDMdacbMhX7dOBCHUl/51NG2Jggzz8Krxa44adQpSriXavXtgm3KxZMOrNlqZoD/yONltcw4SDc8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.068sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> Status: RO Content-Length: 848 > On 14/04/2008, Cathy Zhou wrote: > > > > Having them appear here means that the implementor of any MAC driver > > needs to understand whether or not they should implement those > > functions. Is there a way we can avoid them having to think about it > > given that only softmac will ever need to use this? > > > > It is not true. Only a GLDv3 driver which supports MAC_CAPAB_LEGACY capability > needs to implement those callbacks, and softmac is the only GLDv3 driver > capable of MAC_CAPAB_LEGACY. > Would it perhaps be possible to make softmac a plug type of its own (mac_dlpi?) and then allow there to be type specific entry points? I'm sure there are probably other mac module <-> driver interactions that only make sense for a subset of media types. Paul -- Paul Durrant http://www.linkedin.com/in/pdurrant From Sebastien.Roy@sun.com Mon Apr 14 10:11:31 2008 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 m3EHBURt015607 for ; Mon, 14 Apr 2008 10:11:31 -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 m3EHBC8Z015753 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 15 Apr 2008 01:11:30 +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 <0JZB00A15RR1ZA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 10:11:26 -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 <0JZB003S5RR14X50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 10:11:25 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3EHBP9C007567 for ; Mon, 14 Apr 2008 17:11:25 +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 <0JZB00201QCGA700@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 11:11:25 -0600 (MDT) Received: from [192.168.1.3] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZB00BRDRQT3ND0@mail-amer.sun.com>; Mon, 14 Apr 2008 11:11:17 -0600 (MDT) Date: Mon, 14 Apr 2008 13:11:16 -0400 From: Sebastien Roy Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <48038CD4.9060202@sun.com> Sender: Sebastien.Roy@sun.com To: Robert.Gittins@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Cathy Zhou , Erik Nordmark , Clearview Discuss Message-id: <48039034.7040709@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> <48038AEF.4090806@sun.com> <48038CD4.9060202@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 312 Rob Gittins wrote: > I just wish we were a step ahead instead of 2 steps behind. > This is a formal fast-track architectural review. Please limit your comments to those which are architectural in nature, and make them clear enough that they will actually help make progress in the review of the case. -Seb From Cathy.Zhou@Sun.COM Mon Apr 14 12:45:43 2008 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 m3EJjgxF020327 for ; Mon, 14 Apr 2008 12:45:42 -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 m3EJjVBL013686 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 15 Apr 2008 03:45:41 +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 <0JZB00G01YW4Y300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 12:45:40 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZB00CJSYW2LNC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 12:45:39 -0700 (PDT) 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 m3EJkAOo016367 for ; Mon, 14 Apr 2008 19:46:10 +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 <0JZB00201YNJE400@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Apr 2008 03:45:31 +0800 (SGT) Received: from [129.146.105.122] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZB007STYVTUH56@mail-apac.sun.com>; Tue, 15 Apr 2008 03:45:31 +0800 (SGT) Date: Mon, 14 Apr 2008 12:45:24 -0700 From: Cathy Zhou Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <112359b70804140953q4d2ded0dt8d878a0e1f77d01a@mail.gmail.com> Sender: Cathy.Zhou@Sun.COM To: Paul Durrant Cc: PSARC-ext@Sun.COM, Clearview Discuss , Erik Nordmark , Sebastien Roy Message-id: <4803B454.9020301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> <112359b70804140953q4d2ded0dt8d878a0e1f77d01a@mail.gmail.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 1114 Paul Durrant wrote: >> On 14/04/2008, Cathy Zhou wrote: >> > >> > Having them appear here means that the implementor of any MAC driver >> > needs to understand whether or not they should implement those >> > functions. Is there a way we can avoid them having to think about it >> > given that only softmac will ever need to use this? >> > >> >> It is not true. Only a GLDv3 driver which supports MAC_CAPAB_LEGACY capability >> needs to implement those callbacks, and softmac is the only GLDv3 driver >> capable of MAC_CAPAB_LEGACY. >> > > Would it perhaps be possible to make softmac a plug type of its own > (mac_dlpi?) and then allow there to be type specific entry points? I'm > sure there are probably other mac module <-> driver interactions that > only make sense for a subset of media types. > Do you mean make softmac a new mac type? I don't think that is correct approach. MAC type is about the frame format etc. softmac actually can support legacy network devices of all mac types, not limited to Ethernet (as long as that mac type plugin is supported). Thanks - Cathy From Cathy.Zhou@sun.com Mon Apr 14 13:12:10 2008 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 m3EKCAn7021734 for ; Mon, 14 Apr 2008 13:12:10 -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 m3EKC8YW026367 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Apr 2008 14:12:09 -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 <0JZC0051D0497R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 13:12:09 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZC00LEQ045MZB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 13:12:07 -0700 (PDT) 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 m3EKCbeC016578 for ; Mon, 14 Apr 2008 20:12:37 +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 <0JZC00301025NG00@mail-apac.sun.com> (original mail from Cathy.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Apr 2008 04:11:27 +0800 (SGT) Received: from [129.146.105.122] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZC00BV0031RF0Q@mail-apac.sun.com>; Tue, 15 Apr 2008 04:11:27 +0800 (SGT) Date: Mon, 14 Apr 2008 13:11:51 -0700 From: Cathy Zhou Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <48038AEF.4090806@sun.com> Sender: Cathy.Zhou@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, Clearview Discuss , Erik Nordmark , Sebastien Roy Message-id: <4803BA87.3060003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> <48038AEF.4090806@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 2955 Garrett D'Amore wrote: > Cathy Zhou wrote: >> Erik Nordmark wrote: >>> Sebastien Roy wrote: >>> >>>> Interfaces >>>> ========== >>>> >>>> - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation >>>> Private) >>> Why can't those be project private? Presumably no MAC driver other >>> that softmac should ever use this. >>> >> These are not used by softmac driver. They are used by mac clients. At >> this point only the vnic driver will need to call these functions. But >> it could be used by any MAC clients that don't work with fast-path. > > So the mac clients need to be aware of fast path? That sounds rather > unfortunate -- given that the ultimate goal is to expose the mac client > API someday. It seems like the details of this should be an > implementation detail, that mac clients don't have to worry about. > Unfortunately, because softmac is not able to know whether some specific function can work with the fast-path data-model or not, mac clients have to specify that information. But I think you made a valid point that these two functions should be classified as "Project Private" today, as all other mac client interfaces are all "Project Private" today (defined in PSARC 2004/571). I will make these changes to the case material. > Perhaps more clearly, I don't want MAC clients to fail to function > correctly if they don't enable this behavior. > > I'd rather have an explicit "enable" that is used by fast-path aware > clients (probably only the IP stuff), and let all other clients > automatically start without fast path enabled. That way if someone > writes a mac client that doesn't know about fastpath, it will at least > function properly. > Note that VNIC is currently the only mac client that does not work with fastpath. Aggregations (for example) can co-exist with fast-path just fine. Further, even we assume IP is the only mac client which works with fast-path, we have to have some kind of mac client interface to tell the difference: assume that IP is plumbed on a legacy device, and fast-path is enabled explicitly, then some other mac client starts to use this legacy device and it does not work with fast-path, we still need to disable fast-path dynamically. More important, when that mac client goes away, and IP is now the only one user of this legacy device, then we should fall back to the fast-path again. Thanks - Cathy > (Yes, I still believe that this whole fastpath mechanism is essentially > a performance hack to work around a few crufty drivers that really > should be updated to be pure GLDv3 drivers instead of moving this cruft > into the framework. But on the assumption that we're going to move > forward with this, lets at least limit the visibility of this API to > minimize its architectural impact on the system.) > > -- Garrett > > _________________________________ > clearview-discuss mailing list > clearview-discuss@opensolaris.org From gdamore@Sun.COM Mon Apr 14 13:38:51 2008 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 m3EKcoGl022927 for ; Mon, 14 Apr 2008 13:38:51 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3EKcm6N000317 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Apr 2008 21:38:49 +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 <0JZC003031CO4F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 14:38:48 -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 <0JZC00MR31CNWR20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 14:38:47 -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 m3EKclTS026347 for ; Mon, 14 Apr 2008 13:38:47 -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 <0JZC00G0119BZ700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Apr 2008 13:38:47 -0700 (PDT) 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 <0JZC00JHI1CK1OD0@fe-sfbay-09.sun.com>; Mon, 14 Apr 2008 13:38:45 -0700 (PDT) Date: Mon, 14 Apr 2008 13:34:27 -0700 From: "Garrett D'Amore" Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <4803BA87.3060003@sun.com> Sender: Garrett.Damore@Sun.COM To: Cathy Zhou Cc: PSARC-ext@Sun.COM, Clearview Discuss , Erik Nordmark , Sebastien Roy Message-id: <4803BFD3.5020009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> <48038AEF.4090806@sun.com> <4803BA87.3060003@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3730 Cathy Zhou wrote: > Garrett D'Amore wrote: >> Cathy Zhou wrote: >>> Erik Nordmark wrote: >>>> Sebastien Roy wrote: >>>> >>>>> Interfaces >>>>> ========== >>>>> >>>>> - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation >>>>> Private) >>>> Why can't those be project private? Presumably no MAC driver other >>>> that softmac should ever use this. >>>> >>> These are not used by softmac driver. They are used by mac clients. >>> At this point only the vnic driver will need to call these >>> functions. But it could be used by any MAC clients that don't work >>> with fast-path. >> >> So the mac clients need to be aware of fast path? That sounds rather >> unfortunate -- given that the ultimate goal is to expose the mac >> client API someday. It seems like the details of this should be an >> implementation detail, that mac clients don't have to worry about. >> > Unfortunately, because softmac is not able to know whether some > specific function can work with the fast-path data-model or not, mac > clients have to specify that information. Yech. I'd be far far happier if mac clients only needed to specify that *if* they needed the performance of fast path. Notably this seems to be required only for legacy links, which (imo) defeats much of the purpose of the Clearview project, which is to shield clients from knowing or having to deal differently for legacy versus native GLDv3 NICs. Architecturally, this seems unsound (exposing MAC clients to the details of underlying device plumbing). > > But I think you made a valid point that these two functions should be > classified as "Project Private" today, as all other mac client > interfaces are all "Project Private" today (defined in PSARC 2004/571). > > I will make these changes to the case material. Okay, that's a start. > >> Perhaps more clearly, I don't want MAC clients to fail to function >> correctly if they don't enable this behavior. >> >> I'd rather have an explicit "enable" that is used by fast-path aware >> clients (probably only the IP stuff), and let all other clients >> automatically start without fast path enabled. That way if someone >> writes a mac client that doesn't know about fastpath, it will at >> least function properly. >> > Note that VNIC is currently the only mac client that does not work > with fastpath. Aggregations (for example) can co-exist with fast-path > just fine. Further, even we assume IP is the only mac client which > works with fast-path, we have to have some kind of mac client > interface to tell the difference: assume that IP is plumbed on a > legacy device, and fast-path is enabled explicitly, then some other > mac client starts to use this legacy device and it does not work with > fast-path, we still need to disable fast-path dynamically. More > important, when that mac client goes away, and IP is now the only one > user of this legacy device, then we should fall back to the fast-path > again. Yes, but I don't think you gain much simplicity by having disable be explicit. The same problem exists. (Dynamically enabling or disabling fast path.) -- Garrett > > Thanks > - Cathy > >> (Yes, I still believe that this whole fastpath mechanism is >> essentially a performance hack to work around a few crufty drivers >> that really should be updated to be pure GLDv3 drivers instead of >> moving this cruft into the framework. But on the assumption that >> we're going to move forward with this, lets at least limit the >> visibility of this API to minimize its architectural impact on the >> system.) >> >> -- Garrett >> >> _________________________________ >> clearview-discuss mailing list >> clearview-discuss@opensolaris.org > From erik.nordmark@sun.com Tue Apr 15 11:21:43 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3FILgt8028685 for ; Tue, 15 Apr 2008 11:21:43 -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 m3FILeaP019105; Tue, 15 Apr 2008 11:21:40 -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 <0JZD0023ZPO3BK00@brm-avmta-1.central.sun.com>; Tue, 15 Apr 2008 12:21:39 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.104.45]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZD00224PNZAW00@brm-avmta-1.central.sun.com>; Tue, 15 Apr 2008 12:21:35 -0600 (MDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3FILUjv789129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 11:21:31 -0700 (PDT) Date: Tue, 15 Apr 2008 11:21:30 -0700 From: Erik Nordmark Subject: Re: [clearview-discuss] 2008/242 Data Fast-Path for Softmac In-reply-to: <4803BA87.3060003@sun.com> To: Cathy Zhou Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Clearview Discuss , Sebastien Roy Message-id: <4804F22A.4080707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <47FFD55C.7020002@sun.com> <480388DC.8030105@sun.com> <48038AEF.4090806@sun.com> <4803BA87.3060003@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 497 Cathy Zhou wrote: > Unfortunately, because softmac is not able to know whether some specific > function can work with the fast-path data-model or not, mac clients have > to specify that information. > > But I think you made a valid point that these two functions should be > classified as "Project Private" today, as all other mac client > interfaces are all "Project Private" today (defined in PSARC 2004/571). > > I will make these changes to the case material. Works for me. Erik From Sebastien.Roy@sun.com Wed Apr 16 12:43:08 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3GJh89N022322 for ; Wed, 16 Apr 2008 12:43:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3GJh4pa015763 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 16 Apr 2008 12:43:08 -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 <0JZF00L4DO3U2300@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 12:43:06 -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 <0JZF00K2UO3UF960@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 12:43:06 -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 m3GJh65t000156 for ; Wed, 16 Apr 2008 19:43:06 +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 <0JZF00B01NSARZ00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 13:43:05 -0600 (MDT) Received: from [192.168.1.3] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZF00GXZO3CXPB0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 13:42:48 -0600 (MDT) Date: Wed, 16 Apr 2008 15:42:47 -0400 From: Sebastien Roy Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <47FAA2B3.2080900@sun.com> Sender: Sebastien.Roy@sun.com To: psarc-ext@sun.com Cc: Clearview Discuss Message-id: <480656B7.4000902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 730 I took some of the ongoing discussion for this case off-line, and the result is that everyone is satisfied with the two new mac client functions (mac_fastpath_enable()/mac_fastphath_disable()) being Project Private, and that the vnic mac client is the only client that needs to use them. I've placed the new spec in the case directory under materials. The only difference between this spec and the one originally proposed is the classification of the mac client functions as Project Private. The timer for this case expired a few days ago, but since the discussion was still ongoing at that time, I left it open. I'll let the case run through the PSARC meeting this evening to let it go through the usual litany. -Seb From Sebastien.Roy@Sun.COM Wed Apr 16 17:39:22 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3H0dMAj004741 for ; Wed, 16 Apr 2008 17:39:22 -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 m3H0dM4G029269 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 16 Apr 2008 17:39:22 -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 <0JZG00J011TMJG00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 17:39:22 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZG00ECO1TL25B0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 17:39:21 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3H0dL10014528 for ; Thu, 17 Apr 2008 00:39:21 +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 <0JZG00B011QQA200@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 18:39:21 -0600 (MDT) Received: from [192.168.1.3] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZG00CDG1TKE880@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 16 Apr 2008 18:39:21 -0600 (MDT) Date: Wed, 16 Apr 2008 20:39:20 -0400 From: Sebastien Roy Subject: Re: 2008/242 Data Fast-Path for Softmac In-reply-to: <480656B7.4000902@sun.com> Sender: Sebastien.Roy@Sun.COM To: Sebastien Roy Cc: psarc-ext@Sun.COM, Clearview Discuss Message-id: <48069C38.4030202@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47FAA2B3.2080900@sun.com> <480656B7.4000902@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 310 Sebastien Roy wrote: > The timer for this case expired a few days ago, but since the discussion > was still ongoing at that time, I left it open. I'll let the case run > through the PSARC meeting this evening to let it go through the usual > litany. This case was approved during ARC business today. -Seb