From gd78059@sac.sfbay.sun.com Thu Aug 21 08:56:44 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 m7LFuiDE013059 for ; Thu, 21 Aug 2008 08:56:44 -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 m7LFuiE9000261; Thu, 21 Aug 2008 08:56:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5Y00G07KAIU800@brm-avmta-1.central.sun.com>; Thu, 21 Aug 2008 09:56:42 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Y00GP8KAHCQ00@brm-avmta-1.central.sun.com>; Thu, 21 Aug 2008 09:56:41 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7LFueje035632; Thu, 21 Aug 2008 08:56:40 -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 m7LFudIj013054; Thu, 21 Aug 2008 08:56:39 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7LFudGF013050; Thu, 21 Aug 2008 08:56:39 -0700 (PDT) Date: Thu, 21 Aug 2008 08:56:39 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] To: PSARC-ext@sun.com Cc: pdurrant@solarflare.com Message-id: <200808211556.m7LFudGF013050@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3005 I'm submitting the following fast-track on behalf of Paul Durrant at SolarFlare, who has done some interesting performance work with 10G ethernet. Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: xesballoc: enhanced esballoc 1.2. Name of Document Author/Supplier: Author: Paul Durrant 1.3 Date of This Document: 21 August, 2008 4. Technical Description PROBLEM A high performance NIC driver needs to avoid copying data wherever possible. Thus, it is common on the receive path to encapsulate DMA buffers in a STREAMS block so that they may be passed directly up the stack. The primitive normally used to do this is desballoc(9F). When such a block is freed a callback into the driver is made. This callback is specified by the frtn_t structure: typedef struct free_rtn { void (*free_func)(); caddr_t free_arg; } frtn_t; that was passed to desballoc(9F), and can be used to recover the block that was encapsulated and recycle it. Unfortunately the encapsulating STREAMS block is always freed; so the first action of the driver is usually to allocate a new one, which leads to extra CPU overhead and kmem cache thrashing. SOLUTION We propose a new primitive xesballoc(), which is a variant of desballoc(9F). The semantics of the function itself are identical however the function specified in the frtn_t structure is subtley different. For blocks allocated using desballoc(9f) frtn_t.free_func() is passed a single argumnent: frtn_t.free_arg, effectively giving it a type of: void (*free_func)(caddr_t) For blocks allocated using xesballoc() frtn_t.free_func will be passed a second argument, a pointer to a boolean_t, effectively giving it a type of: void (*free_func)(caddr_t, boolean_t *) If the driver does not modify the boolean then it remains B_FALSE. In this case the STREAMS block will be freed when free_func() returns, as is the case with blocks allocated using desballoc(9F). However, if the driver sets the boolean to B_TRUE then the STREAMS block will not be freed and it is assumed that the driver will recycle this too. NOTES It should be noted that drivers using xesballoc() or desballoc(9F) must be careful not to assume references to the original mblk_t returned by function will be valid when frtn_t.free_func() is called since there is no guarantee that the STREAMS block has not been dupb()ed and the original mblk_t freed. It is guaranteed that the dblk_t will be the same and so the mblk_t should always be accessed via the db_mblk field of the dblk_t to ensure a valid reference. Clearly this point is not so crucial for consumers of desballoc(9F) since the STREAMS block was always freed immediately after the call to frtn_t.free_func(). 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 sommerfeld@sun.com Thu Aug 21 09:21:38 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 m7LGLc4V014523 for ; Thu, 21 Aug 2008 09:21:38 -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 m7LGLbwR034514; Thu, 21 Aug 2008 10:21:37 -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 <0K5Y00I0HLFZG900@brm-avmta-1.central.sun.com>; Thu, 21 Aug 2008 10:21:35 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Y00GYCLFYCS20@brm-avmta-1.central.sun.com>; Thu, 21 Aug 2008 10:21:34 -0600 (MDT) Received: from localhost.east.sun.com (vroom.East.Sun.COM [129.148.19.3]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7LGLWKI007975; Thu, 21 Aug 2008 12:21:32 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7LGLWtl014842; Thu, 21 Aug 2008 12:21:32 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7LGLV54014841; Thu, 21 Aug 2008 12:21:31 -0400 (EDT) Date: Thu, 21 Aug 2008 12:21:31 -0400 From: Bill Sommerfeld Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <200808211556.m7LFudGF013050@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, pdurrant@solarflare.com Message-id: <1219335691.21960.6.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200808211556.m7LFudGF013050@sac.sfbay.sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 972 On Thu, 2008-08-21 at 08:56 -0700, Garrett D'Amore - sun microsystems wrote: > For blocks allocated using xesballoc() frtn_t.free_func will be passed > a second argument, a pointer to a boolean_t, effectively giving it a > type of: > > void (*free_func)(caddr_t, boolean_t *) > If the driver does not modify the boolean then it remains B_FALSE. In > this case the STREAMS block will be freed when free_func() returns, as > is the case with blocks allocated using desballoc(9F). is there some reason why you didn't define a xfrtn_t (since the function signature of the free callback is different), and why you didn't use a function signature of: boolean_t (*free_func)(caddr_t) (returning B_TRUE or B_FALSE as appropriate) the former seems appropriate from a cleanliness perspective (give the compiler a better chance to catch type mismatches); the latter seems simpler and my vague recollection was that it was slightly more efficient as well. - Bill From pdurrant@solarflare.com Thu Aug 21 09:34:20 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 m7LGYJdS015125 for ; Thu, 21 Aug 2008 09:34:20 -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 m7LGY8WR023473; Thu, 21 Aug 2008 17:34:18 +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 <0K5Y00J1BM158H00@brm-avmta-1.central.sun.com>; Thu, 21 Aug 2008 10:34:17 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Y00G5NM14CI30@brm-avmta-1.central.sun.com>; Thu, 21 Aug 2008 10:34:16 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7LGQMHQ000870; Thu, 21 Aug 2008 16:34:15 +0000 (GMT) Received: from mms25es.mms.us.syntegra.com ([150.143.232.90] [150.143.232.90]) by relay23i.sun.com with ESMTP id BT-MMP-2171014; Thu, 21 Aug 2008 16:34:11 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms25es.mms.us.syntegra.com with ESMTP id BT-MMP-32857592; Thu, 21 Aug 2008 16:34:11 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay23i.sun.com with ESMTP id BT-MMP-26812215; Thu, 21 Aug 2008 16:34:11 +0000 (Z) Received: from [10.17.20.48] ([10.17.20.48]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 09:34:09 -0700 Date: Thu, 21 Aug 2008 17:34:06 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <1219335691.21960.6.camel@localhost> To: Bill Sommerfeld Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <48AD98FE.9040608@solarflare.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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.065sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200808211556.m7LFudGF013050@sac.sfbay.sun.com> <1219335691.21960.6.camel@localhost> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 21 Aug 2008 16:34:09.0415 (UTC) FILETIME=[BC88E970:01C903AB] Status: RO Content-Length: 1839 Bill Sommerfeld wrote: > > is there some reason why you didn't define a xfrtn_t (since the function > signature of the free callback is different), and why you didn't use a > function signature of: > > boolean_t (*free_func)(caddr_t) > > (returning B_TRUE or B_FALSE as appropriate) > > the former seems appropriate from a cleanliness perspective (give the > compiler a better chance to catch type mismatches); the latter seems > simpler and my vague recollection was that it was slightly more > efficient as well. The problem is that the db_frtn field of the dblk_t is defined as a frtn_t *. If I created a new structure type then I'd have to cast it anyway to assign it to that field, or change the typedef of dblk_t to union the two pointer types together and then #define something do that db_frtn still pointed at the frtn_t element. I could do this, but I was uneasy about changing the typedef of dblk_t. The fact that the definition frtn_t.free_func does not specify the arguments to the function seemed like a gift allowing me to keep the code changes to the minimum. The use of an incorrectly defined free_func that does not specify the second argument can also be made safe, as I stated, by the fact that if the boolean remains unmodified then the semantics are identical to desballoc() whereas a function that returns a void ending up being cast to one that returns a boolean would be bad. Paul -- ========================================================= Paul Durrant SolarFlare Communications Senior Staff Engineer Block 2, 2nd Floor TEL: +44 (0)1223 518040 (x5527) Westbrook Centre FAX: +44 (0)1223 464225 Milton Road MOB: +44 (0)7717 868957 Cambridge, CB4 1YG UK ========================================================= From pdurrant@solarflare.com Thu Aug 21 09:47:27 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 m7LGlQNh015366 for ; Thu, 21 Aug 2008 09:47:27 -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 m7LGlL1X028816; Thu, 21 Aug 2008 17:47:25 +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 <0K5Y00F0DMN10700@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Aug 2008 09:47:25 -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 <0K5Y007TCMN00Y80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Aug 2008 09:47:25 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7LGevpC021530; Thu, 21 Aug 2008 16:47:24 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay12i.sun.com with ESMTP id BT-MMP-101911; Thu, 21 Aug 2008 16:47:24 +0000 (Z) Received: from relay17i.sun.com (relay17i.sun.com [129.179.4.127]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-4231994; Thu, 21 Aug 2008 16:47:24 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay1i.sun.com with ESMTP id BT-MMP-26927; Thu, 21 Aug 2008 16:47:24 +0000 (Z) Received: from [10.17.20.48] ([10.17.20.48]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 09:47:23 -0700 Date: Thu, 21 Aug 2008 17:47:20 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <1219335691.21960.6.camel@localhost> To: Bill Sommerfeld Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, pdurrant@solarflare.com Message-id: <48AD9C18.5010809@solarflare.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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.058sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200808211556.m7LFudGF013050@sac.sfbay.sun.com> <1219335691.21960.6.camel@localhost> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 21 Aug 2008 16:47:23.0363 (UTC) FILETIME=[95C3C330:01C903AD] Status: RO Content-Length: 1430 Bill Sommerfeld wrote: > > is there some reason why you didn't define a xfrtn_t (since the function > signature of the free callback is different), and why you didn't use a > function signature of: > > boolean_t (*free_func)(caddr_t) > > (returning B_TRUE or B_FALSE as appropriate) > > the former seems appropriate from a cleanliness perspective (give the > compiler a better chance to catch type mismatches); the latter seems > simpler and my vague recollection was that it was slightly more > efficient as well. The problem is that the db_frtn field of the dblk_t is defined as a frtn_t *. If I created a new structure type then I'd have to cast it anyway to assign it to that field, or change the typedef of dblk_t to union the two pointer types together and then #define something do that db_frtn still pointed at the frtn_t element. I could do this, but I was uneasy about changing the typedef of dblk_t. The fact that the definition frtn_t.free_func does not specify the arguments to the function seemed like a gift allowing me to keep the code changes to the minimum. The use of an incorrectly defined free_func that does not specify the second argument can also be made safe, as I stated, by the fact that if the boolean remains unmodified then the semantics are identical to desballoc() whereas a function that returns a void ending up being cast to one that returns a boolean would be bad. Paul From peter.memishian@sun.com Fri Aug 22 00:24:21 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 m7M7OKAX019538 for ; Fri, 22 Aug 2008 00:24:21 -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 m7M7OCE7008805 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 22 Aug 2008 15:24:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5Z00C05R8HTN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 00:24:17 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Z0069BR8GJ440@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 00:24:17 -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 m7M7OGgb058699 for ; Fri, 22 Aug 2008 03:24:16 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7M7OGhL719562 for ; Fri, 22 Aug 2008 03:24:16 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7M7OGuT719545; Fri, 22 Aug 2008 03:24:16 -0400 (EDT) Date: Fri, 22 Aug 2008 03:24:16 -0400 From: Peter Memishian Subject: re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] To: PSARC-ext@sun.com Reply-to: peter.memishian@sun.com Message-id: <18606.27040.274326.519137@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 X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 919 > It should be noted that drivers using xesballoc() or desballoc(9F) > must be careful not to assume references to the original mblk_t > returned by function will be valid when frtn_t.free_func() is called > since there is no guarantee that the STREAMS block has not been > dupb()ed and the original mblk_t freed. It is guaranteed that the > dblk_t will be the same and so the mblk_t should always be accessed > via the db_mblk field of the dblk_t to ensure a valid reference. That may guarantee that the mblk_t is valid, but it's unclear to me how the information in that mblk_t can be safely used by the driver, given that it reflects the processing state (via b_rptr and b_wptr) of some random mblk_t pointing at the given dblk_t. FWIW, db_mblk is also currently project-private to the STREAMS framework, and not covered in datab(9S), probably because it's unclear how one would use it properly. -- meem From pdurrant@solarflare.com Fri Aug 22 00:33:42 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 m7M7Xf2N019931 for ; Fri, 22 Aug 2008 00:33:41 -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 m7M7XdYI010333; Fri, 22 Aug 2008 08:33:39 +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 <0K5Z00H0TRO0G300@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 01:33:36 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Z00980RNXD260@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 01:33:33 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7M7V341016709; Fri, 22 Aug 2008 07:33:32 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-123332; Fri, 22 Aug 2008 07:33:32 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-5452084; Fri, 22 Aug 2008 07:33:32 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay1ib.sun.com with ESMTP id BT-MMP-377788; Fri, 22 Aug 2008 07:33:32 +0000 (Z) Received: from [192.168.1.2] ([195.137.14.130]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 00:33:28 -0700 Date: Fri, 22 Aug 2008 08:33:25 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <18606.27040.274326.519137@gargle.gargle.HOWL> To: peter.memishian@sun.com Cc: PSARC-ext@sun.com Message-id: <48AE6BC5.3050408@solarflare.com> Organization: SolarFlare Communications Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.259sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18606.27040.274326.519137@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-OriginalArrivalTime: 22 Aug 2008 07:33:28.0747 (UTC) FILETIME=[5ECD8FB0:01C90429] Status: RO Content-Length: 845 Peter Memishian wrote: > > That may guarantee that the mblk_t is valid, but it's unclear to me how > the information in that mblk_t can be safely used by the driver, given > that it reflects the processing state (via b_rptr and b_wptr) of some > random mblk_t pointing at the given dblk_t. That's really an implementation detail. My implementation resets the mblk_t fields to the same state the original mblk_t fields were in after xesballoc() was called before calling frtn_t.free_func(). I've posted a webrev at http://cr.opensolaris.org/~pdurrant/stream. > FWIW, db_mblk is also > currently project-private to the STREAMS framework, and not covered in > datab(9S), probably because it's unclear how one would use it properly. > Ok. I guess that limits xesballoc() to be consolidation private. That is fine for my purposes. Paul From peter.memishian@sun.com Fri Aug 22 00:42:22 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 m7M7gMDB020019 for ; Fri, 22 Aug 2008 00:42:22 -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 m7M7gLRl031834 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 22 Aug 2008 01:42:22 -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 <0K5Z00I07S2M2W00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 01:42:22 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Z009EAS2LCY50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 01:42:21 -0600 (MDT) 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 m7M7gK7c062858; Fri, 22 Aug 2008 03:42:20 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7M7gKgQ881116; Fri, 22 Aug 2008 03:42:20 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7M7gI1Z881098; Fri, 22 Aug 2008 03:42:18 -0400 (EDT) Date: Fri, 22 Aug 2008 03:42:18 -0400 From: Peter Memishian Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48AE6BC5.3050408@solarflare.com> To: Paul Durrant Cc: peter.memishian@sun.com, PSARC-ext@sun.com Reply-to: peter.memishian@sun.com Message-id: <18606.28122.170368.470252@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: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 848 > > That may guarantee that the mblk_t is valid, but it's unclear to me how > > the information in that mblk_t can be safely used by the driver, given > > that it reflects the processing state (via b_rptr and b_wptr) of some > > random mblk_t pointing at the given dblk_t. > > That's really an implementation detail. My implementation resets the > mblk_t fields to the same state the original mblk_t fields were in after > xesballoc() was called before calling frtn_t.free_func(). I've posted a > webrev at http://cr.opensolaris.org/~pdurrant/stream. Is there anything else that could meaningfully be done with mblk_t data? If not, could we just document that the STREAMS framework will reset the attached mblk to a pristine state prior to invoking free_func(), and save the driver from rummaging around in private fields? -- meem From pdurrant@solarflare.com Fri Aug 22 00:48:17 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 m7M7mHhM020079 for ; Fri, 22 Aug 2008 00:48:17 -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 m7M7mFeH010606; Fri, 22 Aug 2008 00:48:16 -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 <0K5Z00I0BSCFJ400@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 01:48:15 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Z009RSSCECY50@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 01:48:14 -0600 (MDT) Received: from relay17i.sun.com (ip127.net129179-4.block1.us.syntegra.com [129.179.4.127]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7M7mDFT012789; Fri, 22 Aug 2008 07:48:13 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay17i.sun.com with ESMTP id BT-MMP-123559; Fri, 22 Aug 2008 07:48:13 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-363612; Fri, 22 Aug 2008 07:48:13 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay1ib.sun.com with ESMTP id BT-MMP-361669; Fri, 22 Aug 2008 07:48:13 +0000 (Z) Received: from [192.168.1.2] ([195.137.14.130]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 00:48:12 -0700 Date: Fri, 22 Aug 2008 08:48:09 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <18606.28122.170368.470252@gargle.gargle.HOWL> To: peter.memishian@sun.com Cc: PSARC-ext@sun.com Message-id: <48AE6F39.102@solarflare.com> Organization: SolarFlare Communications Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.048sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-OriginalArrivalTime: 22 Aug 2008 07:48:12.0774 (UTC) FILETIME=[6DB96060:01C9042B] Status: RO Content-Length: 1026 Peter Memishian wrote: > > Is there anything else that could meaningfully be done with mblk_t data? Not really, no. As you said, the driver has no idea of the heritage of that mblk_t. > If not, could we just document that the STREAMS framework will reset the > attached mblk to a pristine state prior to invoking free_func(), and save > the driver from rummaging around in private fields? > Are you suggesting passing the mblk_t as an argument to free_func? The reason that the driver needs to use db_mblk at the moment is that the context argument to free_func is free_arg. In my driver code free_arg points to my own structure. In that structure I store the dblk_t pointer and then I use db_mblk to find the mblk_t pointer. Passing the mblk_t in as an argument is therefore unnecessary for the driver code as it stands. Would it not be reasonable for this case to simply establish the stability of db_mblk at the same level as xesballoc() (or higher) so that drivers using xesballoc() can use db_mblk? Paul From peter.memishian@sun.com Fri Aug 22 01:01:36 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 m7M81Z0L020563 for ; Fri, 22 Aug 2008 01:01:36 -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 m7M81Z2D037206 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 22 Aug 2008 02:01:35 -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 <0K5Z00E0RSYNKE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 01:01:35 -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 <0K5Z006BCSYHJ360@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 01:01:30 -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 m7M81SNc034030; Fri, 22 Aug 2008 04:01:28 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7M81SQM995445; Fri, 22 Aug 2008 04:01:28 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7M81Rm5995435; Fri, 22 Aug 2008 04:01:27 -0400 (EDT) Date: Fri, 22 Aug 2008 04:01:27 -0400 From: Peter Memishian Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48AE6F39.102@solarflare.com> To: Paul Durrant Cc: peter.memishian@sun.com, PSARC-ext@sun.com Reply-to: peter.memishian@sun.com Message-id: <18606.29271.776330.722456@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: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 967 > Are you suggesting passing the mblk_t as an argument to free_func? The > reason that the driver needs to use db_mblk at the moment is that the > context argument to free_func is free_arg. In my driver code free_arg > points to my own structure. In that structure I store the dblk_t pointer > and then I use db_mblk to find the mblk_t pointer. Passing the mblk_t in > as an argument is therefore unnecessary for the driver code as it stands. > Would it not be reasonable for this case to simply establish the > stability of db_mblk at the same level as xesballoc() (or higher) so > that drivers using xesballoc() can use db_mblk? I'm mildly uncomfortable with promoting it since db_mblk is quite hard to use correctly and moreover is intended as an implementation artifact (indeed, it didn't exist in SVR4's datab). But I don't get a vote on this case, and I guess all abstractions are eventually violated in the name of performance :-/ -- meem From carlsonj@phorcys.east.sun.com Fri Aug 22 05:15: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 m7MCFLBK027168 for ; Fri, 22 Aug 2008 05:15:21 -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 m7MCFFAv008185; Fri, 22 Aug 2008 05:15:20 -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 <0K6000F114PJGB00@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 06:15:19 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K60005CW4PJBJ90@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 06:15:19 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7MC7mmR006661; Fri, 22 Aug 2008 08:07:48 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7MC7mCQ006658; Fri, 22 Aug 2008 08:07:48 -0400 (EDT) Date: Fri, 22 Aug 2008 08:07:48 -0400 From: James Carlson Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <18606.29271.776330.722456@gargle.gargle.HOWL> To: Peter.Memishian@sun.com Cc: Paul Durrant , PSARC-ext@sun.com Message-id: <18606.44052.736337.950571@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.4.1.325704 References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> Status: RO Content-Length: 1516 Peter Memishian writes: > > > Are you suggesting passing the mblk_t as an argument to free_func? The > > reason that the driver needs to use db_mblk at the moment is that the > > context argument to free_func is free_arg. In my driver code free_arg > > points to my own structure. In that structure I store the dblk_t pointer > > and then I use db_mblk to find the mblk_t pointer. Passing the mblk_t in > > as an argument is therefore unnecessary for the driver code as it stands. > > Would it not be reasonable for this case to simply establish the > > stability of db_mblk at the same level as xesballoc() (or higher) so > > that drivers using xesballoc() can use db_mblk? > > I'm mildly uncomfortable with promoting it since db_mblk is quite hard to > use correctly and moreover is intended as an implementation artifact > (indeed, it didn't exist in SVR4's datab). But I don't get a vote on this > case, and I guess all abstractions are eventually violated in the name of > performance :-/ It's a fast-track, so there's no voting (yet), but if we were voting, I'd be opposed to elevating db_mblk. It just can't work well enough to be stable -- you can have multiple mblks that point to the same dblk. It's sometimes useful for examining a dump, but that's about it. -- 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 pdurrant@solarflare.com Fri Aug 22 05:28:11 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 m7MCSAHJ027228 for ; Fri, 22 Aug 2008 05:28:11 -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 m7MCS1eC005064; Fri, 22 Aug 2008 13:28:09 +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 <0K6000G0B5ATBV00@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 06:28:05 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K60005G65ASBMB0@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 06:28:05 -0600 (MDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7MCNRBT018563; Fri, 22 Aug 2008 12:28:04 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay16i.sun.com with ESMTP id BT-MMP-133484; Fri, 22 Aug 2008 12:28:04 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-5742388; Fri, 22 Aug 2008 12:28:04 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay1ib.sun.com with ESMTP id BT-MMP-512958; Fri, 22 Aug 2008 12:28:04 +0000 (Z) Received: from [10.17.20.48] ([10.17.20.48]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Aug 2008 05:28:02 -0700 Date: Fri, 22 Aug 2008 13:27:59 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <18606.44052.736337.950571@gargle.gargle.HOWL> To: James Carlson Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48AEB0CF.8050102@solarflare.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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.052sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <18606.44052.736337.950571@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 22 Aug 2008 12:28:03.0174 (UTC) FILETIME=[85951860:01C90452] Status: RO Content-Length: 1199 James Carlson wrote: > > It's a fast-track, so there's no voting (yet), but if we were voting, > I'd be opposed to elevating db_mblk. It just can't work well enough > to be stable -- you can have multiple mblks that point to the same > dblk. It's sometimes useful for examining a dump, but that's about > it. I agree that one cannot make arbitrary use of db_mblk since in the general case it will point to only one of many mblk_ts that may be linked to the dblk_t. However, in the case of the free_func(), db_ref is guaranteed to be 1 so db_mblk always points at the one and only mblk_t. If the general preference is to have the mblk_t passed as an argument to free_func() then I'm not necessarily against it; I just think it's slightly pointless in this circumstance. Paul -- ========================================================= Paul Durrant SolarFlare Communications Senior Staff Engineer Block 2, 2nd Floor TEL: +44 (0)1223 518040 Westbrook Centre FAX: +44 (0)1223 464225 Milton Road Cambridge, CB4 1YG UK ========================================================= From gdamore@sun.com Fri Aug 22 08:32:32 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 m7MFWVc3001152 for ; Fri, 22 Aug 2008 08:32:31 -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 m7MFWJLb019516 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 22 Aug 2008 16:32:30 +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 <0K6000B07DU3M400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 08:32:27 -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 <0K60004T1DTRUIC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 08:32:15 -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 m7MFWFfn020501 for ; Fri, 22 Aug 2008 08:32:15 -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 <0K6000L01DPR5J00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 08:32:15 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6000L1PDTQ4K10@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Aug 2008 08:32:15 -0700 (PDT) Date: Fri, 22 Aug 2008 08:25:50 -0700 From: "Garrett D'Amore" Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <18606.29271.776330.722456@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: Paul Durrant , PSARC-ext@sun.com Message-id: <48AEDA7E.5060204@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: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1682 Peter Memishian wrote: > > Are you suggesting passing the mblk_t as an argument to free_func? The > > reason that the driver needs to use db_mblk at the moment is that the > > context argument to free_func is free_arg. In my driver code free_arg > > points to my own structure. In that structure I store the dblk_t pointer > > and then I use db_mblk to find the mblk_t pointer. Passing the mblk_t in > > as an argument is therefore unnecessary for the driver code as it stands. > > Would it not be reasonable for this case to simply establish the > > stability of db_mblk at the same level as xesballoc() (or higher) so > > that drivers using xesballoc() can use db_mblk? > > I'm mildly uncomfortable with promoting it since db_mblk is quite hard to > use correctly and moreover is intended as an implementation artifact > (indeed, it didn't exist in SVR4's datab). But I don't get a vote on this > case, and I guess all abstractions are eventually violated in the name of > performance :-/ > > I like the idea of the free_func getting passed a third argument, which is the mblk_t * associated. Then nobody needs to look at db_mblk. I confess that I'd also feel better if the framework code reset the mblk fields to default, so that drivers were not required to know which fields to change and which not. (The problem is what happens if sizeof (mblk_t) changes?) A way to achieve this without requiring a common switch case might be to add a new function, msgreset() or somesuch, which just clears the initial mblk header fields to reasonable defaults. Then the free routine could call msgreset() before reusing the mblk. Thoughts? -- Garrett From carlsonj@phorcys.east.sun.com Fri Aug 22 09:00:24 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 m7MG0NKF001734 for ; Fri, 22 Aug 2008 09:00:24 -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 m7MG0BDE001111; Fri, 22 Aug 2008 17:00:22 +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 <0K6000831F4L0400@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 10:00:21 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6000LTQF4ILH90@brm-avmta-1.central.sun.com>; Fri, 22 Aug 2008 10:00:18 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7MFqmm3007189; Fri, 22 Aug 2008 11:52:48 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7MFqm8G007186; Fri, 22 Aug 2008 11:52:48 -0400 (EDT) Date: Fri, 22 Aug 2008 11:52:48 -0400 From: James Carlson Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48AEB0CF.8050102@solarflare.com> To: Paul Durrant Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <18606.57552.445439.574302@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.4.1.325704 References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <18606.44052.736337.950571@gargle.gargle.HOWL> <48AEB0CF.8050102@solarflare.com> Status: RO Content-Length: 1412 Paul Durrant writes: > James Carlson wrote: > > > > It's a fast-track, so there's no voting (yet), but if we were voting, > > I'd be opposed to elevating db_mblk. It just can't work well enough > > to be stable -- you can have multiple mblks that point to the same > > dblk. It's sometimes useful for examining a dump, but that's about > > it. > > I agree that one cannot make arbitrary use of db_mblk since in the > general case it will point to only one of many mblk_ts that may be > linked to the dblk_t. However, in the case of the free_func(), db_ref is > guaranteed to be 1 so db_mblk always points at the one and only mblk_t. I've never viewed that as a serious limitation. You can always arrange things such that the free_arg is either a structure containing a pointer to the mblk_t or is just the mblk_t itself. > If the general preference is to have the mblk_t passed as an argument to > free_func() then I'm not necessarily against it; I just think it's > slightly pointless in this circumstance. I think the uncomfortable part is that it forever nails down the structure offset and functional behavior for db_mblk, because we can't predict who might be using it. -- 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 pdurrant@solarflare.com Tue Aug 26 01:41:00 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 m7Q8f04B013538 for ; Tue, 26 Aug 2008 01:41:00 -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 m7Q8ewse021859; Tue, 26 Aug 2008 01:40:59 -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 <0K67008039G9W800@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 02:40:57 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K670023Z9G83480@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 02:40:57 -0600 (MDT) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7Q8V2oW018815; Tue, 26 Aug 2008 08:40:56 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay24i.sun.com with ESMTP id BT-MMP-2399191; Tue, 26 Aug 2008 08:40:56 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-79142990; Tue, 26 Aug 2008 08:40:55 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay21i.sun.com with ESMTP id BT-MMP-39239973; Tue, 26 Aug 2008 08:40:55 +0000 (Z) Received: from [10.17.20.48] ([10.17.20.48]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 01:40:54 -0700 Date: Tue, 26 Aug 2008 09:40:51 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <18606.57552.445439.574302@gargle.gargle.HOWL> To: James Carlson Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48B3C193.5060606@solarflare.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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.061sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <18606.44052.736337.950571@gargle.gargle.HOWL> <48AEB0CF.8050102@solarflare.com> <18606.57552.445439.574302@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 26 Aug 2008 08:40:54.0612 (UTC) FILETIME=[73FA9140:01C90757] Status: RO Content-Length: 1854 James Carlson wrote: >> I agree that one cannot make arbitrary use of db_mblk since in the >> general case it will point to only one of many mblk_ts that may be >> linked to the dblk_t. However, in the case of the free_func(), db_ref is >> guaranteed to be 1 so db_mblk always points at the one and only mblk_t. > > I've never viewed that as a serious limitation. You can always > arrange things such that the free_arg is either a structure containing > a pointer to the mblk_t or is just the mblk_t itself. > Actually that's exactly what you *shouldn't* do, which was the point of the note in the first place. When free_func() is called the original mblk_t may have *already* been freed (e.g. dupb; freeb) so you should not follow any references to it. The dblk_t pointer is always safe because it is never freed until after free_func() is called. >> If the general preference is to have the mblk_t passed as an argument to >> free_func() then I'm not necessarily against it; I just think it's >> slightly pointless in this circumstance. > > I think the uncomfortable part is that it forever nails down the > structure offset and functional behavior for db_mblk, because we can't > predict who might be using it. > I think it's overkill here since xesballoc() is only supposed to be consolidation private but I have no problem with the mblk_t being passed as an argument. I'll modify my prototype code accordingly. Paul -- ========================================================= Paul Durrant SolarFlare Communications Senior Staff Engineer Block 2, 2nd Floor TEL: +44 (0)1223 518040 Westbrook Centre FAX: +44 (0)1223 464225 Milton Road Cambridge, CB4 1YG UK ========================================================= From pdurrant@solarflare.com Tue Aug 26 01:46: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 m7Q8kH2e014146 for ; Tue, 26 Aug 2008 01:46: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 m7Q8kDpH028393; Tue, 26 Aug 2008 02:46:15 -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 <0K6700M0F9P1NL00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 01:46:13 -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 <0K6700JKP9P17440@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 01:46:13 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7Q8kCjQ019655; Tue, 26 Aug 2008 08:46:12 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay12i.sun.com with ESMTP id BT-MMP-260852; Tue, 26 Aug 2008 08:46:12 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-12584904; Tue, 26 Aug 2008 08:46:12 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay1i.sun.com with ESMTP id BT-MMP-1965401; Tue, 26 Aug 2008 08:46:11 +0000 (Z) Received: from [10.17.20.48] ([10.17.20.48]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 01:46:11 -0700 Date: Tue, 26 Aug 2008 09:46:08 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48AEDA7E.5060204@sun.com> To: "Garrett D'Amore" Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48B3C2D0.6040101@solarflare.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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.070sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <48AEDA7E.5060204@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 26 Aug 2008 08:46:11.0366 (UTC) FILETIME=[30C76460:01C90758] Status: RO Content-Length: 1597 Garrett D'Amore wrote: > I like the idea of the free_func getting passed a third argument, which > is the mblk_t * associated. Then nobody needs to look at db_mblk. I > confess that I'd also feel better if the framework code reset the mblk > fields to default, so that drivers were not required to know which > fields to change and which not. (The problem is what happens if sizeof > (mblk_t) changes?) > > A way to achieve this without requiring a common switch case might be to > add a new function, msgreset() or somesuch, which just clears the > initial mblk header fields to reasonable defaults. Then the free > routine could call msgreset() before reusing the mblk. Thoughts? I think you're going of at a slight tangent here ;-) There's no need for an extra msgreset() call (although I did consider that option myself) because the dblk_lastfree_xesb() code can reset the mblk_t fields prior to calling free_func(). My code at http://cr.opensolaris.org/~pdurrant/stream shows this; check out http://cr.opensolaris.org/~pdurrant/stream/usr/src/uts/common/io/stream.c.html lines 655-659; they are basically identical to lines 702-706 (in gesballoc()). Paul -- ========================================================= Paul Durrant SolarFlare Communications Senior Staff Engineer Block 2, 2nd Floor TEL: +44 (0)1223 518040 Westbrook Centre FAX: +44 (0)1223 464225 Milton Road Cambridge, CB4 1YG UK ========================================================= From gdamore@sun.com Tue Aug 26 07:42:26 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 m7QEgPDS021833 for ; Tue, 26 Aug 2008 07:42:26 -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 m7QEgOgZ028176 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 22:42:25 +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 <0K6700E0XQ6NWC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 26 Aug 2008 07:42:23 -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 <0K6700AIOQ6L7K80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 26 Aug 2008 07:42:22 -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 m7QEgLOL019361 for ; Tue, 26 Aug 2008 07:42:21 -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 <0K6700A01PZRPQ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 26 Aug 2008 07:42:21 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K670096RQ692U90@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 26 Aug 2008 07:42:09 -0700 (PDT) Date: Tue, 26 Aug 2008 07:35:25 -0700 From: "Garrett D'Amore" Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48B3C2D0.6040101@solarflare.com> Sender: Garrett.Damore@sun.com To: Paul Durrant Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48B414AD.2000000@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: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <48AEDA7E.5060204@sun.com> <48B3C2D0.6040101@solarflare.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1350 Paul Durrant wrote: > Garrett D'Amore wrote: >> I like the idea of the free_func getting passed a third argument, >> which is the mblk_t * associated. Then nobody needs to look at >> db_mblk. I confess that I'd also feel better if the framework code >> reset the mblk fields to default, so that drivers were not required >> to know which fields to change and which not. (The problem is what >> happens if sizeof (mblk_t) changes?) >> >> A way to achieve this without requiring a common switch case might be >> to add a new function, msgreset() or somesuch, which just clears the >> initial mblk header fields to reasonable defaults. Then the free >> routine could call msgreset() before reusing the mblk. Thoughts? > > I think you're going of at a slight tangent here ;-) There's no need > for an extra msgreset() call (although I did consider that option > myself) because the dblk_lastfree_xesb() code can reset the mblk_t > fields prior to calling free_func(). My code at > http://cr.opensolaris.org/~pdurrant/stream shows this; check out > http://cr.opensolaris.org/~pdurrant/stream/usr/src/uts/common/io/stream.c.html > lines 655-659; they are basically identical to lines 702-706 (in > gesballoc()). You've made a good point, and I agree, dblk_lastfree_xesb() is the right place to do that. -- Garrett > > Paul > From peter.memishian@Sun.COM Tue Aug 26 09:29:32 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 m7QGTVpc025725 for ; Tue, 26 Aug 2008 09:29:32 -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 m7QGTSRD016494 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 17:29:30 +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 <0K6700I0DV55PF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 10:29:29 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6700AWMV548OD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 10:29:28 -0600 (MDT) 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 m7QGTRLd006196; Tue, 26 Aug 2008 12:29:27 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7QGTR4r163498; Tue, 26 Aug 2008 12:29:27 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7QGTQaM163495; Tue, 26 Aug 2008 12:29:26 -0400 (EDT) Date: Tue, 26 Aug 2008 12:29:26 -0400 From: Peter Memishian Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48B3C193.5060606@solarflare.com> To: Paul Durrant Cc: James Carlson , peter.memishian@Sun.COM, PSARC-ext@Sun.COM Reply-to: peter.memishian@Sun.COM Message-id: <18612.12134.338199.995237@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: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <18606.44052.736337.950571@gargle.gargle.HOWL> <48AEB0CF.8050102@solarflare.com> <18606.57552.445439.574302@gargle.gargle.HOWL> <48B3C193.5060606@solarflare.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 466 > I think it's overkill here since xesballoc() is only supposed to be > consolidation private but I have no problem with the mblk_t being passed > as an argument. I'll modify my prototype code accordingly. "Supposed to be" being the key bit; STREAMS message allocation routines have a track record of escape, and I suspect this one will be no different if it improves performance. In any case, having the additional argument addresses the concern. -- meem From gdamore@sun.com Fri Aug 29 13:03:35 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 m7TK3ZWi014641 for ; Fri, 29 Aug 2008 13:03:35 -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 m7TK3S5o030637 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 29 Aug 2008 14:03:34 -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 <0K6D00F05P1XZ300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 13:03:33 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6D00DKJP1WX6D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 13:03:32 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7TK3W6K002875 for ; Fri, 29 Aug 2008 13:03:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6D00201ONKKL00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 13:03:32 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6D003UWP1ULA30@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 13:03:31 -0700 (PDT) Date: Fri, 29 Aug 2008 13:03:16 -0700 From: "Garrett D'Amore" Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48B414AD.2000000@sun.com> Sender: Garrett.Damore@sun.com To: Paul Durrant Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48B85604.8090107@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: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <48AEDA7E.5060204@sun.com> <48B3C2D0.6040101@solarflare.com> <48B414AD.2000000@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1546 FYI, this case was approved at PSARC this week, with the understanding that you'll pass the mblk to the free function. -- Garrett Garrett D'Amore wrote: > Paul Durrant wrote: >> Garrett D'Amore wrote: >>> I like the idea of the free_func getting passed a third argument, >>> which is the mblk_t * associated. Then nobody needs to look at >>> db_mblk. I confess that I'd also feel better if the framework code >>> reset the mblk fields to default, so that drivers were not required >>> to know which fields to change and which not. (The problem is what >>> happens if sizeof (mblk_t) changes?) >>> >>> A way to achieve this without requiring a common switch case might >>> be to add a new function, msgreset() or somesuch, which just clears >>> the initial mblk header fields to reasonable defaults. Then the >>> free routine could call msgreset() before reusing the mblk. Thoughts? >> >> I think you're going of at a slight tangent here ;-) There's no need >> for an extra msgreset() call (although I did consider that option >> myself) because the dblk_lastfree_xesb() code can reset the mblk_t >> fields prior to calling free_func(). My code at >> http://cr.opensolaris.org/~pdurrant/stream shows this; check out >> http://cr.opensolaris.org/~pdurrant/stream/usr/src/uts/common/io/stream.c.html >> lines 655-659; they are basically identical to lines 702-706 (in >> gesballoc()). > > > You've made a good point, and I agree, dblk_lastfree_xesb() is the > right place to do that. > > -- Garrett >> >> Paul >> > From pdurrant@solarflare.com Mon Sep 1 01:19: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 m818JHF4025798 for ; Mon, 1 Sep 2008 01:19:18 -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 m818JC0A013948; Mon, 1 Sep 2008 09:19:13 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6I00319CFY9300@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Sep 2008 01:19:10 -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 <0K6I00KAICFXCZC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Sep 2008 01:19:10 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m818B5B0012282; Mon, 01 Sep 2008 08:19:09 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-513208; Mon, 01 Sep 2008 08:19:09 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-21659490; Mon, 01 Sep 2008 08:19:09 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay1i.sun.com with ESMTP id BT-MMP-5199923; Mon, 01 Sep 2008 08:19:09 +0000 (Z) Received: from [10.17.20.48] ([10.17.20.48]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 01 Sep 2008 01:19:07 -0700 Date: Mon, 01 Sep 2008 09:19:04 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48B85604.8090107@sun.com> To: "Garrett D'Amore" Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48BBA578.9070503@solarflare.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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.043sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <48AEDA7E.5060204@sun.com> <48B3C2D0.6040101@solarflare.com> <48B414AD.2000000@sun.com> <48B85604.8090107@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 01 Sep 2008 08:19:08.0103 (UTC) FILETIME=[67B79D70:01C90C0B] Status: RO Content-Length: 687 Garrett D'Amore wrote: > FYI, this case was approved at PSARC this week, with the understanding > that you'll pass the mblk to the free function. > Thank you Garrett. I have made that modification to the interface and checked that it all still works as expected. Paul -- ========================================================= Paul Durrant SolarFlare Communications Senior Staff Engineer Block 2, 2nd Floor TEL: +44 (0)1223 518040 Westbrook Centre FAX: +44 (0)1223 464225 Milton Road Cambridge, CB4 1YG UK ========================================================= From gdamore@sun.com Mon Sep 1 09:15:30 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 m81GFTsX006374 for ; Mon, 1 Sep 2008 09:15:29 -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 m81GFTqe044270 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Sep 2008 10:15:29 -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 <0K6I00803YHT6400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Sep 2008 09:15:29 -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 <0K6I004RKYHOE340@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Sep 2008 09:15:28 -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 m81GFOae022203 for ; Mon, 01 Sep 2008 09:15:24 -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 <0K6I00301YGPQK00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Sep 2008 09:15:24 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6I00JK3YHO5H20@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Sep 2008 09:15:24 -0700 (PDT) Date: Mon, 01 Sep 2008 09:14:56 -0700 From: "Garrett D'Amore" Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48BBA578.9070503@solarflare.com> Sender: Garrett.Damore@sun.com To: Paul Durrant Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48BC1500.8030106@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: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <48AEDA7E.5060204@sun.com> <48B3C2D0.6040101@solarflare.com> <48B414AD.2000000@sun.com> <48B85604.8090107@sun.com> <48BBA578.9070503@solarflare.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 770 Paul Durrant wrote: > Garrett D'Amore wrote: >> FYI, this case was approved at PSARC this week, with the >> understanding that you'll pass the mblk to the free function. >> > > Thank you Garrett. I have made that modification to the interface and > checked that it all still works as expected. > > Paul > Excellent. If you can arrange for a webrev and mercurial changeset then I can sponsor your push. I do confess it would be *ideal* if some other NIC driver that is already integrated could include this. Other approaches are: 1) integrate your driver without this, and then convert it and push this change in a subsequent push 2) integrate this change *and* your driver at the same time. I'm happy to handle it however you would prefer. -- Garrett From pdurrant@solarflare.com Mon Sep 1 09:32: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 m81GWCM1006431 for ; Mon, 1 Sep 2008 09:32:12 -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 m81GW24c021196; Mon, 1 Sep 2008 17:32:08 +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 <0K6I0091PZ9JAJ00@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Sep 2008 09:32:07 -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 <0K6I0048RZ9IEA60@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Sep 2008 09:32:06 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m81GU973007861; Mon, 01 Sep 2008 16:32:05 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-175194; Mon, 01 Sep 2008 16:32:00 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-24128727; Mon, 01 Sep 2008 16:31:59 +0000 (Z) Received: from exchange.solarflare.com ([216.237.3.220] [216.237.3.220]) by relay4i.sun.com with ESMTP id BT-MMP-16676224; Mon, 01 Sep 2008 16:31:59 +0000 (Z) Received: from [10.17.20.48] ([10.17.20.48]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 01 Sep 2008 09:31:58 -0700 Date: Mon, 01 Sep 2008 17:31:55 +0100 From: Paul Durrant Subject: Re: xesballoc: enhanced esballoc [PSARC/2008/539 FastTrack timeout 08/28/2008] In-reply-to: <48BC1500.8030106@sun.com> To: "Garrett D'Amore" Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com Message-id: <48BC18FB.9040001@solarflare.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 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.048sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18606.27040.274326.519137@gargle.gargle.HOWL> <48AE6BC5.3050408@solarflare.com> <18606.28122.170368.470252@gargle.gargle.HOWL> <48AE6F39.102@solarflare.com> <18606.29271.776330.722456@gargle.gargle.HOWL> <48AEDA7E.5060204@sun.com> <48B3C2D0.6040101@solarflare.com> <48B414AD.2000000@sun.com> <48B85604.8090107@sun.com> <48BBA578.9070503@solarflare.com> <48BC1500.8030106@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-OriginalArrivalTime: 01 Sep 2008 16:31:58.0747 (UTC) FILETIME=[4131CEB0:01C90C50] Status: RO Content-Length: 736 Garrett D'Amore wrote: > > Other approaches are: > > 1) integrate your driver without this, and then convert it and push this > change in a subsequent push > 2) integrate this change *and* your driver at the same time. > > I'm happy to handle it however you would prefer. > I will most likely go for option 2. Paul -- ========================================================= Paul Durrant SolarFlare Communications Senior Staff Engineer Block 2, 2nd Floor TEL: +44 (0)1223 518040 Westbrook Centre FAX: +44 (0)1223 464225 Milton Road Cambridge, CB4 1YG UK =========================================================