From dr146992@sac.sfbay.sun.com Mon Nov 26 21:01:49 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAR51nX2028390 for ; Mon, 26 Nov 2007 21:01:49 -0800 (PST) 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 lAR51mJm024758; Mon, 26 Nov 2007 21:01:48 -0800 (PST) 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 <0JS500109FAZOG00@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Nov 2007 21:01:47 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS5000DOFAZH220@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Nov 2007 21:01:47 -0800 (PST) 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 lAR51lfb012470; Mon, 26 Nov 2007 21:01:47 -0800 (PST) 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 lAR51jFX028385; Mon, 26 Nov 2007 21:01:45 -0800 (PST) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lAR51jTx028381; Mon, 26 Nov 2007 21:01:45 -0800 (PST) Date: Mon, 26 Nov 2007 21:01:45 -0800 (PST) From: Darren Reed Subject: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] To: PSARC-ext@Sun.COM Message-id: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 4146 I'm submitting the following case on behalf of the devil (me). Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Broadcast/multicast packet notification through pfhooks 1.2. Name of Document Author/Supplier: Author: Darren Reed 1.3 Date of This Document: 26 November, 2007 4. Technical Description Broadcast/multicast packet notification through pfhooks Introduction ============ This case seeks to introduce a new member of the hooks_pkt_event_t structure (introduced by PSARC/2005/334) to allow communication of whether or not a packet is a multicast or broadcast packet through to receivers of packet events. As the interfaces introduced by PSARC/2005/334 are currently private, so too is the change being introduced by this case. History ======= Prior to PSARC/2005/334, IPFilter was able to examine the mblks before they reached IP, giving it access to the data structures used by the DL_UNITDATA_IND primitive. This structure includes a field known as dl_group_address and indicates whether or not the packet is a broadcast/ multicast packet or a unicast packet. With the advent of PSARC/2005/334, the interception point for filtering was moved to being inside of IP, to a location where the DL_UNITDATA_IND has already been removed from the front of the packet, thus preventing IPFilter from being able to detect whether or not the packet was unicast or not. Details ======= The current hook_pkt_event_t structure can be found in and is as follows: /* * The hook_pkt_event_t structure is supplied with packet events on * associated network interfaces. * * The members of this structure are defined as follows: * hpe_ifp - "in" interface for packets coming into the system or forwarded * hpe_ofp - "out" interface for packets being transmitted or forwarded * hpe_hdr - pointer to protocol header within the packet * hpe_mp - pointer to the mblk pointer starting the chain for this packet * hpe_mb - pointer to the mblk that contains hpe_hdr */ typedef struct hook_pkt_event { phy_if_t hpe_ifp; phy_if_t hpe_ofp; void *hpe_hdr; mblk_t **hpe_mp; mblk_t *hpe_mb; } hook_pkt_event_t; The proposed new structure is: typedef struct hook_pkt_event { phy_if_t hpe_ifp; phy_if_t hpe_ofp; void *hpe_hdr; mblk_t **hpe_mp; mblk_t *hpe_mb; int hpe_flags; } hook_pkt_event_t; The proposed use of hpe_flags is: #define HPE_MULTICAST 0x01 #define HPE_BROADCAST 0x02 These two bit values indicate if the packet is multicast or if it is broadcast, however, using DLPI in Solaris today, it is not possible to know if a packet that reaches IP is multicast or broadcast by looking at the dl_group_address field and nor is there any other mechanism available. In light of this, setting both flags together is supported as an indication that the packet might be one or the other: #define HPE_MBCAST 0x03 Interface table =============== +---------------------------------------------------------------+ | | Interfaces Exported | | |------------------+-----------------------+--------------------| | Interface | Classification | Comments | |------------------+-----------------------+--------------------| | HPE_MULTICAST | Consolidation Private | | | HPE_BROADCAST | Consolidation Private | | | HPE_MBCAST | Consolidation Private | | | hook_pkt_event_t | Consolidation Private | | +------------------+-----------------------+--------------------+ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Reed@Sun.COM Mon Nov 26 21:42:10 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAR5g9Dp000069 for ; Mon, 26 Nov 2007 21:42:10 -0800 (PST) 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 lAR5g8iR007967 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Nov 2007 13:42:08 +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 <0JS500F05H67C500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 26 Nov 2007 21:42:07 -0800 (PST) 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 <0JS5009TMH66EK90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 26 Nov 2007 21:42:07 -0800 (PST) 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 lAR5g6ma008531 for ; Tue, 27 Nov 2007 05:42:06 +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 <0JS500H01H1GSH00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 27 Nov 2007 13:42:05 +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 <0JS5009GVH5VO2QH@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 27 Nov 2007 13:41:56 +0800 (SGT) Date: Mon, 26 Nov 2007 21:41:54 -0800 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> Sender: Darren.Reed@Sun.COM To: PSARC-ext@Sun.COM Message-id: <474BAE22.4070206@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 4333 I forgot to mention that this case seeks patch binding. Darren Reed wrote: >I'm submitting the following case on behalf of the devil (me). > >Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >This information is Copyright 2007 Sun Microsystems >1. Introduction > 1.1. Project/Component Working Name: > Broadcast/multicast packet notification through pfhooks > 1.2. Name of Document Author/Supplier: > Author: Darren Reed > 1.3 Date of This Document: > 26 November, 2007 >4. Technical Description >Broadcast/multicast packet notification through pfhooks > >Introduction >============ >This case seeks to introduce a new member of the hooks_pkt_event_t >structure (introduced by PSARC/2005/334) to allow communication of >whether or not a packet is a multicast or broadcast packet through >to receivers of packet events. As the interfaces introduced by >PSARC/2005/334 are currently private, so too is the change being >introduced by this case. > >History >======= >Prior to PSARC/2005/334, IPFilter was able to examine the mblks before >they reached IP, giving it access to the data structures used by the >DL_UNITDATA_IND primitive. This structure includes a field known as >dl_group_address and indicates whether or not the packet is a broadcast/ >multicast packet or a unicast packet. With the advent of PSARC/2005/334, >the interception point for filtering was moved to being inside of IP, to >a location where the DL_UNITDATA_IND has already been removed from the >front of the packet, thus preventing IPFilter from being able to detect >whether or not the packet was unicast or not. > >Details >======= >The current hook_pkt_event_t structure can be found in >and is as follows: > >/* > * The hook_pkt_event_t structure is supplied with packet events on > * associated network interfaces. > * > * The members of this structure are defined as follows: > * hpe_ifp - "in" interface for packets coming into the system or forwarded > * hpe_ofp - "out" interface for packets being transmitted or forwarded > * hpe_hdr - pointer to protocol header within the packet > * hpe_mp - pointer to the mblk pointer starting the chain for this packet > * hpe_mb - pointer to the mblk that contains hpe_hdr > */ >typedef struct hook_pkt_event { > phy_if_t hpe_ifp; > phy_if_t hpe_ofp; > void *hpe_hdr; > mblk_t **hpe_mp; > mblk_t *hpe_mb; >} hook_pkt_event_t; > >The proposed new structure is: > >typedef struct hook_pkt_event { > phy_if_t hpe_ifp; > phy_if_t hpe_ofp; > void *hpe_hdr; > mblk_t **hpe_mp; > mblk_t *hpe_mb; > int hpe_flags; >} hook_pkt_event_t; > >The proposed use of hpe_flags is: >#define HPE_MULTICAST 0x01 >#define HPE_BROADCAST 0x02 > >These two bit values indicate if the packet is multicast or if it >is broadcast, however, using DLPI in Solaris today, it is not possible to >know if a packet that reaches IP is multicast or broadcast by looking >at the dl_group_address field and nor is there any other mechanism >available. In light of this, setting both flags together is supported >as an indication that the packet might be one or the other: > >#define HPE_MBCAST 0x03 > >Interface table >=============== >+---------------------------------------------------------------+ >| | Interfaces Exported | | >|------------------+-----------------------+--------------------| >| Interface | Classification | Comments | >|------------------+-----------------------+--------------------| >| HPE_MULTICAST | Consolidation Private | | >| HPE_BROADCAST | Consolidation Private | | >| HPE_MBCAST | Consolidation Private | | >| hook_pkt_event_t | Consolidation Private | | >+------------------+-----------------------+--------------------+ > > >6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > > From carlsonj@phorcys.east.sun.com Tue Nov 27 04:35:55 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lARCZtYY011293 for ; Tue, 27 Nov 2007 04:35:55 -0800 (PST) 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 lARCZtQn006526 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Tue, 27 Nov 2007 04:35:55 -0800 (PST) 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 <0JS600J1X0BUV300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 27 Nov 2007 04:35:54 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS6006UH0BSCP30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 27 Nov 2007 04:35:53 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lARCYxGL017138; Tue, 27 Nov 2007 07:34:59 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lARCYxeY017135; Tue, 27 Nov 2007 07:34:59 -0500 (EST) Date: Tue, 27 Nov 2007 07:34:59 -0500 From: James Carlson Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <18252.3827.179434.87486@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> Status: RO Content-Length: 1014 Darren Reed writes: > These two bit values indicate if the packet is multicast or if it > is broadcast, however, using DLPI in Solaris today, it is not possible to > know if a packet that reaches IP is multicast or broadcast by looking > at the dl_group_address field and nor is there any other mechanism > available. In light of this, setting both flags together is supported > as an indication that the packet might be one or the other: > > #define HPE_MBCAST 0x03 Do the clients using this interface need to know the difference between multicast and broadcast in order to function correctly? If so, then why not have this interface resolve the amibiguity? That can be done by checking the destination address (dl_dest_addr_*) when you see that dl_group_address is set. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Tue Nov 27 10:13:16 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lARIDFgp017401 for ; Tue, 27 Nov 2007 10:13:15 -0800 (PST) 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 lARID8oY000777 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 02:13:14 +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 <0JS600K1TFXZKN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 10:13:11 -0800 (PST) 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 <0JS600H0DFXX0F90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 10:13:09 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lARID9P3023762 for ; Tue, 27 Nov 2007 10:13:09 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS600801FMHCR00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 10:13:09 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS600EF5FXV4J80@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 10:13:07 -0800 (PST) Date: Tue, 27 Nov 2007 10:08:11 -0800 From: "Garrett D'Amore" Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474BAE22.4070206@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <474C5D0B.3020501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <474BAE22.4070206@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 5020 Hmm.... I seem to recall when I was looking at path optimizations in Sitara, that a bit more clean up could be done in some hot paths if the mblk carried the group indication in a bit rather than always carrying the link layer header around. Have you given any thought to maybe *gasp* adding a bit or two to the mblk with the IP header. If that were done, there are other optimizations that would help the hot code path as well. -- Garrett Darren Reed wrote: > I forgot to mention that this case seeks patch binding. > > Darren Reed wrote: > >> I'm submitting the following case on behalf of the devil (me). >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Broadcast/multicast packet notification through pfhooks >> 1.2. Name of Document Author/Supplier: >> Author: Darren Reed >> 1.3 Date of This Document: >> 26 November, 2007 >> 4. Technical Description >> Broadcast/multicast packet notification through pfhooks >> >> Introduction >> ============ >> This case seeks to introduce a new member of the hooks_pkt_event_t >> structure (introduced by PSARC/2005/334) to allow communication of >> whether or not a packet is a multicast or broadcast packet through >> to receivers of packet events. As the interfaces introduced by >> PSARC/2005/334 are currently private, so too is the change being >> introduced by this case. >> >> History >> ======= >> Prior to PSARC/2005/334, IPFilter was able to examine the mblks before >> they reached IP, giving it access to the data structures used by the >> DL_UNITDATA_IND primitive. This structure includes a field known as >> dl_group_address and indicates whether or not the packet is a broadcast/ >> multicast packet or a unicast packet. With the advent of >> PSARC/2005/334, >> the interception point for filtering was moved to being inside of IP, to >> a location where the DL_UNITDATA_IND has already been removed from the >> front of the packet, thus preventing IPFilter from being able to detect >> whether or not the packet was unicast or not. >> >> Details >> ======= >> The current hook_pkt_event_t structure can be found in >> >> and is as follows: >> >> /* >> * The hook_pkt_event_t structure is supplied with packet events on >> * associated network interfaces. >> * >> * The members of this structure are defined as follows: >> * hpe_ifp - "in" interface for packets coming into the system or >> forwarded >> * hpe_ofp - "out" interface for packets being transmitted or forwarded >> * hpe_hdr - pointer to protocol header within the packet >> * hpe_mp - pointer to the mblk pointer starting the chain for this >> packet >> * hpe_mb - pointer to the mblk that contains hpe_hdr >> */ >> typedef struct hook_pkt_event { >> phy_if_t hpe_ifp; >> phy_if_t hpe_ofp; >> void *hpe_hdr; >> mblk_t **hpe_mp; >> mblk_t *hpe_mb; >> } hook_pkt_event_t; >> >> The proposed new structure is: >> >> typedef struct hook_pkt_event { >> phy_if_t hpe_ifp; >> phy_if_t hpe_ofp; >> void *hpe_hdr; >> mblk_t **hpe_mp; >> mblk_t *hpe_mb; >> int hpe_flags; >> } hook_pkt_event_t; >> >> The proposed use of hpe_flags is: >> #define HPE_MULTICAST 0x01 >> #define HPE_BROADCAST 0x02 >> >> These two bit values indicate if the packet is multicast or if it >> is broadcast, however, using DLPI in Solaris today, it is not >> possible to >> know if a packet that reaches IP is multicast or broadcast by looking >> at the dl_group_address field and nor is there any other mechanism >> available. In light of this, setting both flags together is supported >> as an indication that the packet might be one or the other: >> >> #define HPE_MBCAST 0x03 >> >> Interface table >> =============== >> +---------------------------------------------------------------+ >> | | Interfaces Exported | | >> |------------------+-----------------------+--------------------| >> | Interface | Classification | Comments | >> |------------------+-----------------------+--------------------| >> | HPE_MULTICAST | Consolidation Private | | >> | HPE_BROADCAST | Consolidation Private | | >> | HPE_MBCAST | Consolidation Private | | >> | hook_pkt_event_t | Consolidation Private | | >> +------------------+-----------------------+--------------------+ >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> >> > From Darren.Reed@sun.com Tue Nov 27 17:42:19 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAS1gI43005070 for ; Tue, 27 Nov 2007 17:42:18 -0800 (PST) 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 lAS1gEBv024293 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 09:42:17 +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 <0JS700J010QG1900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 17:42:16 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS700A4P0QF5LB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 17:42:16 -0800 (PST) Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAS1gEHv025518 for ; Wed, 28 Nov 2007 01:42:14 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JS700F0105XDR00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:42:14 +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 <0JS7005XV0QD2YZ4@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:42:14 +0800 (SGT) Date: Tue, 27 Nov 2007 17:42:12 -0800 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <18252.3827.179434.87486@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <474CC774.3030208@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <18252.3827.179434.87486@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1006 James Carlson wrote: >Darren Reed writes: > > >>These two bit values indicate if the packet is multicast or if it >>is broadcast, however, using DLPI in Solaris today, it is not possible to >>know if a packet that reaches IP is multicast or broadcast by looking >>at the dl_group_address field and nor is there any other mechanism >>available. In light of this, setting both flags together is supported >>as an indication that the packet might be one or the other: >> >>#define HPE_MBCAST 0x03 >> >> > >Do the clients using this interface need to know the difference >between multicast and broadcast in order to function correctly? > > No. >If so, then why not have this interface resolve the amibiguity? That >can be done by checking the destination address (dl_dest_addr_*) when >you see that dl_group_address is set. > > Even if they did, once the packet reaches IP, it's beyond the scope of IP to determine what the MAC destination address meant at the MAC layer. Darren From Darren.Reed@sun.com Tue Nov 27 18:14:24 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAS2ENxe005636 for ; Tue, 27 Nov 2007 18:14:23 -0800 (PST) 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 lAS2EGmn011364 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 10:14:22 +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 <0JS700K0127WSV00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 18:14:20 -0800 (PST) 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 <0JS700AMC27U5PE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 18:14:19 -0800 (PST) Received: from fe-apac-01.sun.com (fe-apac-01.sun.com [192.18.19.172] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAS2EIHU028086 for ; Wed, 28 Nov 2007 02:14:18 +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 <0JS700B011ANHS00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 10:14:18 +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 <0JS700LRF27SL6B2@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 10:14:18 +0800 (SGT) Date: Tue, 27 Nov 2007 18:14:16 -0800 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474C5D0B.3020501@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <474CCEF8.5010709@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.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <474BAE22.4070206@Sun.COM> <474C5D0B.3020501@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 693 Garrett D'Amore wrote: > Hmm.... I seem to recall when I was looking at path optimizations in > Sitara, that a bit more clean up could be done in some hot paths if > the mblk carried the group indication in a bit rather than always > carrying the link layer header around. > > Have you given any thought to maybe *gasp* adding a bit or two to the > mblk with the IP header. If that were done, there are other > optimizations that would help the hot code path as well. Can you be more specific about where it is you're thinking that these flags could be stored and what their definition would mean for messages going up from IP (as IP would set them) as well as down from IP? Darren From gdamore@sun.com Tue Nov 27 20:54:51 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAS4spSd007986 for ; Tue, 27 Nov 2007 20:54:51 -0800 (PST) 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 lAS4soH4009539 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Nov 2007 20:54:50 -0800 (PST) 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 <0JS7005039NEHY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 21:54:50 -0700 (MST) 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 <0JS700MEW9NE1M40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 21:54:50 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAS4snrM022312 for ; Tue, 27 Nov 2007 20:54:49 -0800 (PST) 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 <0JS7000019IXUX00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:54:49 -0800 (PST) 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 <0JS700JZS9N74SB0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 20:54:44 -0800 (PST) Date: Tue, 27 Nov 2007 20:49:46 -0800 From: "Garrett D'Amore" Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474CCEF8.5010709@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <474CF36A.3050501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <474BAE22.4070206@Sun.COM> <474C5D0B.3020501@sun.com> <474CCEF8.5010709@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1111 Darren Reed wrote: > Garrett D'Amore wrote: > >> Hmm.... I seem to recall when I was looking at path optimizations in >> Sitara, that a bit more clean up could be done in some hot paths if >> the mblk carried the group indication in a bit rather than always >> carrying the link layer header around. >> >> Have you given any thought to maybe *gasp* adding a bit or two to the >> mblk with the IP header. If that were done, there are other >> optimizations that would help the hot code path as well. > > > Can you be more specific about where it is you're > thinking that these flags could be stored and what > their definition would mean for messages going > up from IP (as IP would set them) as well as down > from IP? Actually, I'd like to see them going up _to_ up. I.e. set the bit in the Nemo layer or device drivers. They could live on the in the msgb->b_flag member. It *looks* like only about 7 bits of this 16-bit field are used, but I'm not looking very hard at it right now. (I suspect I may be missing something that isn't in the sys/stream.h header.) -- Garrett > > Darren > From Darren.Reed@sun.com Tue Nov 27 21:37:38 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAS5bbq7009099 for ; Tue, 27 Nov 2007 21:37:38 -0800 (PST) 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 lAS5bZ2a028416 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 05:37:36 GMT 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 <0JS700707BMIAO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 21:37:31 -0800 (PST) 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 <0JS70023IBMHFU70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 21:37:30 -0800 (PST) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAS5bTcF012018 for ; Wed, 28 Nov 2007 05:37:29 +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 <0JS700M01AWJ8E00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 13:37:29 +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 <0JS700A1RBMFZQF4@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 13:37:29 +0800 (SGT) Date: Tue, 27 Nov 2007 21:37:27 -0800 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474CF36A.3050501@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <474CFE97.8040402@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.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <474BAE22.4070206@Sun.COM> <474C5D0B.3020501@sun.com> <474CCEF8.5010709@Sun.COM> <474CF36A.3050501@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1242 Garrett D'Amore wrote: > Darren Reed wrote: > >> Garrett D'Amore wrote: >> >>> Hmm.... I seem to recall when I was looking at path optimizations in >>> Sitara, that a bit more clean up could be done in some hot paths if >>> the mblk carried the group indication in a bit rather than always >>> carrying the link layer header around. >>> >>> Have you given any thought to maybe *gasp* adding a bit or two to >>> the mblk with the IP header. If that were done, there are other >>> optimizations that would help the hot code path as well. >> >> >> >> Can you be more specific about where it is you're >> thinking that these flags could be stored and what >> their definition would mean for messages going >> up from IP (as IP would set them) as well as down >> from IP? > > > Actually, I'd like to see them going up _to_ up. I.e. set the bit in > the Nemo layer or device drivers. That isn't this case and this case does nothing to prevent your suggestion from being taken up at a later point in time. This case is only looking at communication of the broadcast/multicast property from IP out to other code connected via pfhooks and can be adapted to use whatever signalling mechanism is used between IP and device drivers. Darren From gdamore@sun.com Tue Nov 27 22:14:30 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAS6EUGU009918 for ; Tue, 27 Nov 2007 22:14:30 -0800 (PST) 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 lAS6ETNU005517 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Nov 2007 22:14:29 -0800 (PST) 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 <0JS700B0PDC50100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 22:14:29 -0800 (PST) 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 <0JS700MEMDC4UT60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 22:14:28 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAS6ESuw024218 for ; Tue, 27 Nov 2007 22:14:28 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS700I01D8NA000@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 22:14:28 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS700C40DC4GMC0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Nov 2007 22:14:28 -0800 (PST) Date: Tue, 27 Nov 2007 22:09:30 -0800 From: "Garrett D'Amore" Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474CFE97.8040402@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <474D061A.9010508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <474BAE22.4070206@Sun.COM> <474C5D0B.3020501@sun.com> <474CCEF8.5010709@Sun.COM> <474CF36A.3050501@sun.com> <474CFE97.8040402@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1401 Darren Reed wrote: > Garrett D'Amore wrote: > >> Darren Reed wrote: >> >>> Garrett D'Amore wrote: >>> >>>> Hmm.... I seem to recall when I was looking at path optimizations >>>> in Sitara, that a bit more clean up could be done in some hot paths >>>> if the mblk carried the group indication in a bit rather than >>>> always carrying the link layer header around. >>>> >>>> Have you given any thought to maybe *gasp* adding a bit or two to >>>> the mblk with the IP header. If that were done, there are other >>>> optimizations that would help the hot code path as well. >>> >>> >>> >>> Can you be more specific about where it is you're >>> thinking that these flags could be stored and what >>> their definition would mean for messages going >>> up from IP (as IP would set them) as well as down >>> from IP? >> >> >> Actually, I'd like to see them going up _to_ up. I.e. set the bit in >> the Nemo layer or device drivers. > > > That isn't this case and this case does nothing to prevent your > suggestion > from being taken up at a later point in time. > > This case is only looking at communication of the broadcast/multicast > property from IP out to other code connected via pfhooks and can be > adapted to use whatever signalling mechanism is used between IP and > device drivers. Fair 'nuff. I was just asking if you had thought about it, was all. :-) -- Garrett > > Darren > From carlsonj@phorcys.east.sun.com Wed Nov 28 05:19:48 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASDJmn5018144 for ; Wed, 28 Nov 2007 05:19:48 -0800 (PST) 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 lASDJjDB019140; Wed, 28 Nov 2007 06:19:46 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS700F12X0UTQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Nov 2007 05:19:42 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS700GSBX0S7VE0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Nov 2007 05:19:41 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lASDIkKF021782; Wed, 28 Nov 2007 08:18:46 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lASDIkj5021779; Wed, 28 Nov 2007 08:18:46 -0500 (EST) Date: Wed, 28 Nov 2007 08:18:46 -0500 From: James Carlson Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474CC774.3030208@Sun.COM> To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <18253.27318.476147.372933@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <18252.3827.179434.87486@gargle.gargle.HOWL> <474CC774.3030208@Sun.COM> Status: RO Content-Length: 1860 Darren Reed writes: > James Carlson wrote: > >Do the clients using this interface need to know the difference > >between multicast and broadcast in order to function correctly? > > > > > > No. So, then, why distinguish? It looks like you're trying to emulate the BSD {MSG,M}_[BM]CAST flags, but I'm unsure why that's a useful thing when the emulation (as defined) doesn't work, it seems like there's no plan to make it work, and the consumers don't need to know that information anyway. I'm suggesting that perhaps it'd be worthwhile to make it work or to consider getting rid of it. For what it's worth, I care about this because it seems like there's a plan to make this interface open to projects other than IP Filter. As just a private interface, the change probably falls below the radar. > >If so, then why not have this interface resolve the amibiguity? That > >can be done by checking the destination address (dl_dest_addr_*) when > >you see that dl_group_address is set. > > > > > > Even if they did, once the packet reaches IP, it's beyond the > scope of IP to determine what the MAC destination address > meant at the MAC layer. I don't think that's the point. The point is what sort of functionality makes sense for users of this interface. What gyrations IP may need to go through to provide the needed information are a separate design and implementation matter (and I don't think I share the concern about "scope" -- our IP _implementation_ is already hip deep in MAC layer trivia, and doing a compare between dl_dest_addr_* and dl_brdcst_addr_*, to both of which IP has ready access, shouldn't be hard). -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Wed Nov 28 13:38:44 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASLchwm007751 for ; Wed, 28 Nov 2007 13:38:43 -0800 (PST) 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 lASLccrX024420 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Nov 2007 05:38:42 +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 <0JS80007YK4FKE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 13:38:39 -0800 (PST) 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 <0JS800K3AK4DRZ20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 13:38:38 -0800 (PST) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lASLcbO1017166 for ; Wed, 28 Nov 2007 21:38: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 <0JS800I01JUY4300@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Nov 2007 05:38:37 +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 <0JS800AE1K4BZQN4@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Nov 2007 05:38:36 +0800 (SGT) Date: Wed, 28 Nov 2007 13:38:35 -0800 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <18253.27318.476147.372933@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <474DDFDB.6070400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <18252.3827.179434.87486@gargle.gargle.HOWL> <474CC774.3030208@Sun.COM> <18253.27318.476147.372933@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2428 James Carlson wrote: >Darren Reed writes: > > >>James Carlson wrote: >> >> >>>Do the clients using this interface need to know the difference >>>between multicast and broadcast in order to function correctly? >>> >>> >>> >>> >>No. >> >> > >So, then, why distinguish? > >It looks like you're trying to emulate the BSD {MSG,M}_[BM]CAST flags, >but I'm unsure why that's a useful thing when the emulation (as >defined) doesn't work, it seems like there's no plan to make it work, >and the consumers don't need to know that information anyway. > > IPFilter needs to know whether or not the packet is unicast or not so that you can do policy based routing without copying over broadcast/multicast packets, e.g. pass in on bge0 to bge1:192.168.1.1 from any to any with not mbcast This works pre-S10U4 and is broken in nevada/s10u4+. On BSD, the same rule works (applying to both broadcast and multicast) but because of the flags that are specific to broadcast/multicast are present in their equivalent of the mblk_t, it is also possible to write rules that are specific to one, e.g: block in quick all with broadcast >... > >For what it's worth, I care about this because it seems like there's a >plan to make this interface open to projects other than IP Filter. As >just a private interface, the change probably falls below the radar. > > Yes, I'm with you there. >>>If so, then why not have this interface resolve the amibiguity? That >>>can be done by checking the destination address (dl_dest_addr_*) when >>>you see that dl_group_address is set. >>> >>> >>> >>> >>Even if they did, once the packet reaches IP, it's beyond the >>scope of IP to determine what the MAC destination address >>meant at the MAC layer. >> >> > >I don't think that's the point. The point is what sort of >functionality makes sense for users of this interface. What gyrations >IP may need to go through to provide the needed information are a >separate design and implementation matter (and I don't think I share >the concern about "scope" -- our IP _implementation_ is already hip >deep in MAC layer trivia, and doing a compare between dl_dest_addr_* >and dl_brdcst_addr_*, to both of which IP has ready access, shouldn't >be hard). > > I'll look into this but it makes no difference to the architecture, only the implementation that would enable setting just one of the flags rather than both. Darren From carlsonj@phorcys.east.sun.com Wed Nov 28 13:48:22 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASLmLA0008338 for ; Wed, 28 Nov 2007 13:48:21 -0800 (PST) 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 lASLltMD001272; Wed, 28 Nov 2007 21:48:18 GMT 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 <0JS800203KKF4U00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Nov 2007 13:48:15 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800KHEKKDRZ30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Nov 2007 13:48:14 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lASLlJ8v024631; Wed, 28 Nov 2007 16:47:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lASLlIQ5024628; Wed, 28 Nov 2007 16:47:19 -0500 (EST) Date: Wed, 28 Nov 2007 16:47:18 -0500 From: James Carlson Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474DDFDB.6070400@Sun.COM> To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <18253.57830.594930.889834@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <18252.3827.179434.87486@gargle.gargle.HOWL> <474CC774.3030208@Sun.COM> <18253.27318.476147.372933@gargle.gargle.HOWL> <474DDFDB.6070400@Sun.COM> Status: RO Content-Length: 1948 Darren Reed writes: > On BSD, the same rule works (applying to both broadcast and multicast) > but because of the flags that are specific to broadcast/multicast are > present in their equivalent of the mblk_t, it is also possible to write > rules that are specific to one, e.g: > > block in quick all with broadcast So ... should that same thing work on Solaris one day or not? You previously said that IP Filter doesn't need to know the difference between broadcast and multicast. But this makes it look as though knowing that difference would in fact benefit IP Filter. > >I don't think that's the point. The point is what sort of > >functionality makes sense for users of this interface. What gyrations > >IP may need to go through to provide the needed information are a > >separate design and implementation matter (and I don't think I share > >the concern about "scope" -- our IP _implementation_ is already hip > >deep in MAC layer trivia, and doing a compare between dl_dest_addr_* > >and dl_brdcst_addr_*, to both of which IP has ready access, shouldn't > >be hard). > > > > > > I'll look into this but it makes no difference to the architecture, > only the implementation that would enable setting just one of > the flags rather than both. I disagree. Setting both flags as an attempted emulation of the BSD interface _is_ architectural, because it means that consumers of the interface can't actually rely on it to implement user interface artifacts such as the "with broadcast" filter. I could go along with this _if_ there's a commitment to repair the interface before changing the stability. "Repair" would mean that either the flags operate as intended, or that the interface itself is removed. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Wed Nov 28 14:30:54 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASMUrjL008969 for ; Wed, 28 Nov 2007 14:30:54 -0800 (PST) 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 lASMUiVP021997 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Nov 2007 06:30:52 +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 <0JS800907MJECW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 14:30:50 -0800 (PST) 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 <0JS800K9KMJDRWA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 14:30:50 -0800 (PST) Received: from fe-apac-03.sun.com (fe-apac-03.sun.com [192.18.19.174] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lASMUnie017053 for ; Wed, 28 Nov 2007 22:30:49 +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 <0JS800401LROCH00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Nov 2007 06:30:49 +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 <0JS8008WEMJBXDJ5@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Nov 2007 06:30:48 +0800 (SGT) Date: Wed, 28 Nov 2007 14:30:46 -0800 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <18253.57830.594930.889834@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <474DEC16.8010402@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <18252.3827.179434.87486@gargle.gargle.HOWL> <474CC774.3030208@Sun.COM> <18253.27318.476147.372933@gargle.gargle.HOWL> <474DDFDB.6070400@Sun.COM> <18253.57830.594930.889834@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2055 James Carlson wrote: >Darren Reed writes: > > >>On BSD, the same rule works (applying to both broadcast and multicast) >>but because of the flags that are specific to broadcast/multicast are >>present in their equivalent of the mblk_t, it is also possible to write >>rules that are specific to one, e.g: >> >>block in quick all with broadcast >> >> > >So ... should that same thing work on Solaris one day or not? > > I'd like it to, yes. >You previously said that IP Filter doesn't need to know the difference >between broadcast and multicast. But this makes it look as though >knowing that difference would in fact benefit IP Filter. > > It enables better rules to be written, yes. >>>I don't think that's the point. The point is what sort of >>>functionality makes sense for users of this interface. What gyrations >>>IP may need to go through to provide the needed information are a >>>separate design and implementation matter (and I don't think I share >>>the concern about "scope" -- our IP _implementation_ is already hip >>>deep in MAC layer trivia, and doing a compare between dl_dest_addr_* >>>and dl_brdcst_addr_*, to both of which IP has ready access, shouldn't >>>be hard). >>> >>> >>> >>> >>I'll look into this but it makes no difference to the architecture, >>only the implementation that would enable setting just one of >>the flags rather than both. >> >> > >I disagree. Setting both flags as an attempted emulation of the BSD >interface _is_ architectural, because it means that consumers of the >interface can't actually rely on it to implement user interface >artifacts such as the "with broadcast" filter. > >I could go along with this _if_ there's a commitment to repair the >interface before changing the stability. "Repair" would mean that >either the flags operate as intended, or that the interface itself is >removed. > > Are you taking to task the setting of both bits as a way of saying "I know it's not unicast, but I can't decide if it is multicast/broadcast" or something else? Darren From carlsonj@phorcys.east.sun.com Wed Nov 28 14:42:21 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASMgLUf009030 for ; Wed, 28 Nov 2007 14:42:21 -0800 (PST) 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 lASMgIPc004709; Wed, 28 Nov 2007 15:42:19 -0700 (MST) 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 <0JS800C01N2I8700@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 14:42:18 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS8007E9N2II280@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 14:42:18 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lASMfNOO024970; Wed, 28 Nov 2007 17:41:23 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lASMfNDn024967; Wed, 28 Nov 2007 17:41:23 -0500 (EST) Date: Wed, 28 Nov 2007 17:41:21 -0500 From: James Carlson Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <474DEC16.8010402@Sun.COM> To: Darren Reed Cc: PSARC-ext@Sun.COM Message-id: <18253.61073.905373.711605@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <18252.3827.179434.87486@gargle.gargle.HOWL> <474CC774.3030208@Sun.COM> <18253.27318.476147.372933@gargle.gargle.HOWL> <474DDFDB.6070400@Sun.COM> <18253.57830.594930.889834@gargle.gargle.HOWL> <474DEC16.8010402@Sun.COM> Status: RO Content-Length: 1409 Darren Reed writes: > James Carlson wrote: > >I could go along with this _if_ there's a commitment to repair the > >interface before changing the stability. "Repair" would mean that > >either the flags operate as intended, or that the interface itself is > >removed. > > > > > > Are you taking to task the setting of both bits as a way of saying > "I know it's not unicast, but I can't decide if it is multicast/broadcast" > or something else? Yes. It puts the burden on the client to figure out what that means and opens up a new possibility that wouldn't happen with the original BSD interface, and one that doesn't seem to make semantic sense. Filters written to match just "broadcast" would also match all L2 multicast messages, even though that's clearly not what was wanted. That result seems to me to be architectural. It's a limitation in the defined interface that ends up limiting the possible things the client of that interface can do. As a project (or consolidation) private issue, I still think it's a touch broken, but I don't think I care much. If it's aiming to end up as non-private one day, then it's a loose end that needs to be resolved before that day. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Thu Nov 29 11:45:07 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATJj6kv011043 for ; Thu, 29 Nov 2007 11:45:06 -0800 (PST) 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 lATJj2rQ024387 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Nov 2007 03:45:05 +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 <0JSA00B1P9J5WB00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 29 Nov 2007 12:45:05 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA005JT9J2H290@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 29 Nov 2007 12:45:03 -0700 (MST) Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATJj1XN020623 for ; Thu, 29 Nov 2007 19:45: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 <0JSA007019DEFS00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 30 Nov 2007 03:45:01 +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 <0JSA0016I9J0AE50@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 30 Nov 2007 03:45:01 +0800 (SGT) Date: Thu, 29 Nov 2007 11:44:59 -0800 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <18253.61073.905373.711605@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <474F16BB.3070808@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Eb7Y/kAf6jOczt31y+Z5iw)" X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> <18252.3827.179434.87486@gargle.gargle.HOWL> <474CC774.3030208@Sun.COM> <18253.27318.476147.372933@gargle.gargle.HOWL> <474DDFDB.6070400@Sun.COM> <18253.57830.594930.889834@gargle.gargle.HOWL> <474DEC16.8010402@Sun.COM> <18253.61073.905373.711605@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 3436 This is a multi-part message in MIME format. --Boundary_(ID_Eb7Y/kAf6jOczt31y+Z5iw) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT I'm updating the spec with the attached file. The only change is removing the HPE_MBCAST which allows for both the multicast and broadcast bits to be set simultaneously. Darren --Boundary_(ID_Eb7Y/kAf6jOczt31y+Z5iw) Content-type: text/plain; name=mbcast Content-transfer-encoding: 7BIT Content-disposition: inline; filename=mbcast Broadcast/multicast packet notification through pfhooks Introduction ============ This case seeks to introduce a new member of the hooks_pkt_event_t structure (introduced by PSARC/2005/334) to allow communication of whether or not a packet is a multicast or broadcast packet through to receivers of packet events. The interfaces discussed below are currently private. History ======= Prior to PSARC/2005/334, IPFilter was able to examine the mblks before they reached IP, giving it access to the data structures used by the DL_UNITDATA_IND primitive. This structure includes a field known as dl_group_address and indicates whether or not the packet is a broadcast/ multicast packet or a unicast packet. With the advent of PSARC/2005/334, the interception point for filtering was moved to being inside of IP, to a location where the DL_UNITDATA_IND has been removed from the front of the packet, thus preventing IPFilter from being able to detect whether or not the packet was unicast or not. Details ======= The current hook_pkt_event_t structure can be found in and is as follows: /* * The hook_pkt_event_t structure is supplied with packet events on * associated network interfaces. * * The members of this structure are defined as follows: * hpe_ifp - "in" interface for packets coming into the system or forwarded * hpe_ofp - "out" interface for packets being transmitted or forwarded * hpe_hdr - pointer to protocol header within the packet * hpe_mp - pointer to the mblk pointer starting the chain for this packet * hpe_mb - pointer to the mblk that contains hpe_hdr */ typedef struct hook_pkt_event { phy_if_t hpe_ifp; phy_if_t hpe_ofp; void *hpe_hdr; mblk_t **hpe_mp; mblk_t *hpe_mb; } hook_pkt_event_t; The proposed structure is: typedef struct hook_pkt_event { phy_if_t hpe_ifp; phy_if_t hpe_ofp; void *hpe_hdr; mblk_t **hpe_mp; mblk_t *hpe_mb; int hpe_flags; } hook_pkt_event_t; The proposed use of hpe_flags is: #define HPE_MULTICAST 0x01 #define HPE_BROADCAST 0x02 These values indicate if the packet is multicast or if it is broadcast. Interface table =============== +---------------------------------------------------------------+ | | Interfaces Exported | | |------------------+-----------------------+--------------------| | Interface | Classification | Comments | |------------------+-----------------------+--------------------| | hook_pkt_event_t | Consolidation Private | | +------------------+-----------------------+--------------------+ --Boundary_(ID_Eb7Y/kAf6jOczt31y+Z5iw)-- From Darren.Reed@sun.com Mon Dec 17 21:09:21 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI59Kqw009375 for ; Mon, 17 Dec 2007 21:09:21 -0800 (PST) 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 lBI59G4g004921 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 Dec 2007 05:09:19 GMT 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 <0JT80010RBNHNZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 17 Dec 2007 22:09:17 -0700 (MST) 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 <0JT80014EBNFF500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 17 Dec 2007 22:09:16 -0700 (MST) 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 lBI59FJW025004 for ; Tue, 18 Dec 2007 05:09:15 +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 <0JT800K01BFSES00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 18 Dec 2007 13:09:15 +0800 (SGT) Received: from [129.158.87.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JT800COPBNEUF13@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 18 Dec 2007 13:09:15 +0800 (SGT) Date: Tue, 18 Dec 2007 16:08:47 +1100 From: Darren Reed Subject: Re: Broadcast/multicast packet notification through pfhooks [PSARC/2007/666 FastTrack timeout 12/03/2007] In-reply-to: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: PSARC-ext@sun.com Message-id: <476755DF.8000605@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200711270501.lAR51jTx028381@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 54 This fast track was approved at PSARC on 12-12-2007.