From kais@sac.sfbay.sun.com Wed Apr 22 18:06:28 2009 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 n3N16Rs6024556 for ; Wed, 22 Apr 2009 18:06:27 -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 n3N16P15051005; Wed, 22 Apr 2009 19:06:27 -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 <0KIJ00M034EQ5Q00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 22 Apr 2009 18:06:26 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIJ00L984EQKI00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 22 Apr 2009 18:06:26 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3N16P24035386; Wed, 22 Apr 2009 18:06:25 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3N16OUp024551; Wed, 22 Apr 2009 18:06:24 -0700 (PDT) Received: (from kais@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3N16OFF024547; Wed, 22 Apr 2009 18:06:24 -0700 (PDT) Date: Wed, 22 Apr 2009 18:06:24 -0700 (PDT) From: Kais Belgaied Subject: MAC promiscuous dead interfaces removal [PSARC/2009/252 Self Review] To: PSARC-ext@sun.com Cc: Girish.Moodalbail@sun.com Message-id: <200904230106.n3N16OFF024547@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3101 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: MAC promiscuous dead interfaces removal 1.2. Name of Document Author/Supplier: Author: Girish Moodalbail 1.3 Date of This Document: 22 April, 2009 4. Technical Description I am sponsoring this case on behalf of Girish Moodalbail. The case documents the removal of Consolidation Private interfaces that became unused and therefore has no architectural impact. I believe it qualifies for a self-review. The interfaces being changed are all Project Private and patch binding is requested. There are no consumers of these interfaces outside of ON. This case proposes to remove some of the interface changes that were introduced as part of PSARC 2005/289 aka "Promiscuous Nemo". With the integration of Crossbow into Nevada (build 105), those changes are not needed any more and the dead code needs to be removed. Background & Introduction =========================== PSARC case 2005/289 introduced a set of interface changes to separate device-level and MAC-level promiscuous behavior. These changes were required to address an issue with missing 'promiscuous' on/off notification when the underlying data-link became promiscuous. This notification was necessary to adjust the transmit routine to either use a special loopback routine, mac_txloop() or not. This routine would loop back transmitted packets so that they can be observed (almost all Ethernet devices are deaf while transmitting, so transmitted packets which this host must also receive must be looped back by software). See the 2005/289 case directory for more details. With the integration of Crossbow there is no need for interface changes suggested by 2005/289. Crossbow achieves this using mac_promisc_add() MAC client API and MAC_PROMISC_FLAGS_NO_TX_LOOP MAC Client flag. When a MAC client desires to capture packets on an interface, it registers a promiscuous callback with mac_promisc_add(). This callback function is added to the promiscuous callback list maintained by the underlying MAC instance. Further, the MAC_PROMISC_FLAGS_NO_TX_LOOP flag passed to mac_promisc_add() function determines if the sender MAC client wants to receive copies of the packets it sends. Interface Changes ================== Following changes are proposed: * There is no need to separate device-level and MAC-level promiscuous behavior. Only device-level promiscuous notification (MAC_NOTE_DEVPROMISC) is required. So MAC_NOTE_PROMISC is obsolete and needs to be removed. * Removal of mac_promisc_type_t enumeration. It had two values: MAC_PROMISC and MAC_DEVPROMISC * Updating mac_promisc_get() and mac_promisc_set() functions to not to use above enum as function arguments. Note that all of these changes are to the MAC client layer, which is Project Private. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Garrett.Damore@sun.com Wed Apr 22 18:32:15 2009 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 n3N1WDF0024671 for ; Wed, 22 Apr 2009 18:32:14 -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 n3N1Vssx019973 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 23 Apr 2009 02:32:12 +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 <0KIJ00K0T5LMJD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 18:32:10 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIJ007TP5LMHGC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 18:32:10 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3N1WAPe013666 for ; Wed, 22 Apr 2009 18:32:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIJ006005JI1O00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 18:32:10 -0700 (PDT) Received: from [129.153.2.8] ([unknown] [129.153.2.8]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIJ00KYO5LLN830@fe-sfbay-09.sun.com>; Wed, 22 Apr 2009 18:32:10 -0700 (PDT) Date: Wed, 22 Apr 2009 18:32:09 -0700 From: "Garrett D'Amore" Subject: Re: MAC promiscuous dead interfaces removal [PSARC/2009/252 Self Review] In-reply-to: <200904230106.n3N16OFF024547@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Kais Belgaied Cc: PSARC-ext@sun.com, Girish.Moodalbail@sun.com Message-id: <49EFC519.6060608@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: <200904230106.n3N16OFF024547@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 3244 +1 - Garrett On 04/22/09 18:06, Kais Belgaied wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > MAC promiscuous dead interfaces removal > 1.2. Name of Document Author/Supplier: > Author: Girish Moodalbail > 1.3 Date of This Document: > 22 April, 2009 > 4. Technical Description > I am sponsoring this case on behalf of Girish Moodalbail. The case documents the > removal of Consolidation Private interfaces that became unused and therefore has no architectural impact. I believe it qualifies for a self-review. > > The interfaces being changed are all Project Private and patch binding is requested. There are no consumers of these interfaces outside of ON. > > This case proposes to remove some of the interface changes that were introduced as part of PSARC 2005/289 aka "Promiscuous Nemo". With the integration of Crossbow into Nevada (build 105), those changes are not needed any more and the dead code needs to be removed. > > > Background & Introduction > =========================== > > PSARC case 2005/289 introduced a set of interface changes to separate device-level and MAC-level promiscuous behavior. These changes were required to address an issue with missing 'promiscuous' on/off notification when the underlying data-link became promiscuous. This notification was necessary to adjust the transmit routine to either use a special loopback routine, mac_txloop() or not. This routine would loop back transmitted packets so that they can be observed (almost all Ethernet devices are deaf while transmitting, so transmitted packets which this host must also receive must be looped back by software). See the 2005/289 case directory for more details. > > With the integration of Crossbow there is no need for interface changes suggested by 2005/289. Crossbow achieves this using mac_promisc_add() MAC client API and MAC_PROMISC_FLAGS_NO_TX_LOOP MAC Client flag. > > When a MAC client desires to capture packets on an interface, it registers a promiscuous callback with mac_promisc_add(). This callback function is added to the promiscuous callback list maintained by the underlying MAC instance. Further, the MAC_PROMISC_FLAGS_NO_TX_LOOP flag passed to mac_promisc_add() function determines if the sender MAC client wants to receive copies of the packets it sends. > > Interface Changes > ================== > > Following changes are proposed: > > * There is no need to separate device-level and MAC-level promiscuous behavior. Only device-level promiscuous notification (MAC_NOTE_DEVPROMISC) is required. So MAC_NOTE_PROMISC is obsolete and needs to be removed. > > * Removal of mac_promisc_type_t enumeration. It had two values: MAC_PROMISC and MAC_DEVPROMISC > > * Updating mac_promisc_get() and mac_promisc_set() functions to not to use above enum as function arguments. > > Note that all of these changes are to the MAC client layer, which is Project Private. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > >