From sacadmin Thu Sep 19 19:46:31 2002 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Sep 2002 22:42:30 -0400 From: James Carlson To: psarc@sac.eng.sun.com cc: Adi.Masputra@Sun.COM, chris.schmechel@Sun.COM Subject: 2002/276 TCP Multi-Data Transmit Content-Length: 13710 I am sponsoring this fast-track request for Adi Masputra and Chris Schmechel. The timer is set for 09/25/2002. The project team has asked that this case be converted to a fast-track request. I think it's a little on the large side for a fast-track, but the materials are very well done, and scope of the change is actually quite small since only the 'ce' (GigaSwift) interface will have a contract to use this interface, and the team will need to revisit the ARC later to expand it. The contract with NSPG is being drafted and will be deposited in the materials directory when it is ready. BACKGROUND ---------- Relevant background MDT information (in the materials directory): Multidata Interface Design Specification (mmd.pdf) "An Efficient Networking Transmit Mechanism for Solaris: Multidata Transmit (MDT)" (mdt.pdf) This case is dependent on these ARC cases: PSARC 2002/322 - DL_CAPABILITY knob PSARC 2002/105 - Three Ammendments to PSARC/2001/070 DL_C*_REQ PSARC 2001/070 - DL_{CAPABILITY,CONTROL}_REQ PROBLEM ------- The current model for packet transmission and reception throughout the Solaris TCP/IP stack and network device driver is geared towards sending and receiving one packet at a time. Because of the high per-packet costs in the Solaris stack, this model consumes a lot of the system processing time and has an impact on the networking performance. For example, it makes it hard for Solaris to saturate the 1 gigabit per second (Gbps) line rate on a single TCP connection. SOLUTION -------- This fast-track proposal introduces a Multi-Data mechanism which allows for more than one packet to be sent from one module to another in a given call, thereby reducing the per-packet processing costs. This translates to improving the host CPU utilization and/or network throughput. The requested release binding is micro for the "off by default" configuration, and minor for the "on by default" configuration. This proposal creates the following interfaces: Exported Interfaces: +-----------------------+----------------------------------+-----------------+ |Interface | Classification | Comments | |-----------------------+----------------------------------+-----------------| |sys/multidata.h | Contracted Consolidation Private | Shipping | |sys/pattr.h | Contracted Consolidation Private | Shipping | |sys/multidata_impl.h | Consolidation Private | Not Shipped | | | | | |ip_multidata_outbound | Unstable | ndd variable | | | | S10 - On | | | | S9U* - Off | | | | | |M_MULTIDATA | Contracted Consolidation Private | sys/stream.h | | | | | |DL_CAPAB_MDT | Contracted Consolidation Private | sys/dlpi.h | |struct dl_capab_mdt_t | Contracted Consolidation Private | sys/dlpi.h | | | | | |struct pattrinfo_t | Contracted Consolidation Private | sys/multidata.h | |struct mbufinfo_t | Contracted Consolidation Private | sys/multidata.h | |struct pdescinfo_t | Contracted Consolidation Private | sys/multidata.h | | | | | |PDESC_HDR_REF | Contracted Consolidation Private | sys/multidata.h | |PDESC_PBUF_REF | Contracted Consolidation Private | sys/multidata.h | |PDESC_HDRSIZE | Contracted Consolidation Private | sys/multidata.h | |PDESC_HDRL | Contracted Consolidation Private | sys/multidata.h | |PDESC_HDRHEAD | Contracted Consolidation Private | sys/multidata.h | |PDESC_HDRTAIL | Contracted Consolidation Private | sys/multidata.h | |PDESC_PLDSIZE | Contracted Consolidation Private | sys/multidata.h | |PDESC_PLDL | Contracted Consolidation Private | sys/multidata.h | | | | | |mmd_alloc() | Contracted Consolidation Private | sys/multidata.h | |mmd_getmultidata() | Contracted Consolidation Private | sys/multidata.h | |mmd_getregions() | Contracted Consolidation Private | sys/multidata.h | |mmd_getcnt() | Contracted Consolidation Private | sys/multidata.h | |mmd_addpdesc() | Contracted Consolidation Private | sys/multidata.h | |mmd_rempdesc() | Contracted Consolidation Private | sys/multidata.h | |mmd_getfirstpdesc() | Contracted Consolidation Private | sys/multidata.h | |mmd_getlastpdesc() | Contracted Consolidation Private | sys/multidata.h | |mmd_getnextpdesc() | Contracted Consolidation Private | sys/multidata.h | |mmd_getprevpdesc() | Contracted Consolidation Private | sys/multidata.h | |mmd_adjpdesc() | Contracted Consolidation Private | sys/multidata.h | |mmd_transform() | Contracted Consolidation Private | sys/multidata.h | |mmd_dupbufs() | Contracted Consolidation Private | sys/multidata.h | |mmd_getpdescinfo() | Contracted Consolidation Private | sys/multidata.h | |mmd_addpattr() | Contracted Consolidation Private | sys/multidata.h | |mmd_rempattr() | Contracted Consolidation Private | sys/multidata.h | |mmd_getpattr() | Contracted Consolidation Private | sys/multidata.h | | | | | |PATTR_DSTADDRSAP | Contracted Consolidation Private | sys/pattr.h | |PATTR_SRCADDRSAP | Contracted Consolidation Private | sys/pattr.h | |struct pattr_addr_t | Contracted Consolidation Private | sys/pattr.h | +-----------------------+----------------------------------+-----------------+ Imported Interfaces: +-----------------------+---------------------------------------------------+ |Interface | Classification | Comments | |-----------------------+---------------------------------------------------| |DL_CAPABILITY_REQ | Contracted Consolidation Private | PSARC/2001/070 | |DL_CAPABILITY_ACK | Contracted Consolidation Private | PSARC/2001/070 | +-----------------------+----------------------------------+----------------+ A new STREAMS data block type (M_MULTIDATA) is proposed, and is used to identify data blocks containing the Multidata metadata: In , #define M_MULTIDATA 0x02 /* reserved for Multidata use only */ A set of kernel functions are provided to allocate and manipulate (add or remove elements to/from) the Multidata metadata: In , /* Multidata packet attribute information */ typedef struct pattrinfo_s { uint_t type; /* attribute type value */ uint_t len; /* attribute length */ void *buf; /* pointer to user data area */ } pattrinfo_t; /* Multidata buffer information */ typedef struct mbufinfo_s { uchar_t *hbuf_rptr; /* start address of header buffer */ uchar_t *hbuf_wptr; /* end address of header buffer */ uchar_t *pbuf_rptr; /* start address of payload buffer */ uchar_t *pbuf_wptr; /* end address of header buffer */ } mbufinfo_t; /* Multidata packet descriptor information */ typedef struct pdescinfo_s { uint_t flags; /* misc. flags */ uchar_t *hdr_base; /* start address of header area */ uchar_t *hdr_rptr; /* start address of header data */ uchar_t *hdr_wptr; /* end address of header data */ uchar_t *hdr_lim; /* end address of header area */ uchar_t *pld_rptr; /* start address of payload data */ uchar_t *pld_wptr; /* pointer to end of payload data */ } pdescinfo_t; /* Possible values for flags */ #define PDESC_HBUF_REF 0x1 /* descriptor uses header buffer */ #define PDESC_PBUF_REF 0x2 /* descriptor uses payload buffer */ #define PDESC_HDRSIZE(p) ((p)->hdr_lim - (p)->hdr_base) #define PDESC_HDRL(p) ((p)->hdr_wptr - (p)->hdr_rptr) #define PDESC_HDRHEAD(p) ((p)->hdr_rptr - (p)->hdr_base) #define PDESC_HDRTAIL(p) ((p)->hdr_lim - (p)->hdr_wptr) #define PDESC_PLDSIZE(p) ((p)->pld_wptr - (p)->pld_rptr) #define PDESC_PLDL(p) PDESC_PLDSIZE(p) /* These structures are opaque to multidata clients */ struct pdesc_s; typedef struct pdesc_s pdesc_t; struct pattr_s; typedef struct pattr_s pattr_t; struct multidata_s; typedef struct multidata_s multidata_t; extern int mmd_alloc(mblk_t *, mblk_t *, mblk_t **, multidata_t **, int); extern multidata_t *mmd_getmultidata(mblk_t *); extern int mmd_getregions(multidata_t *, mbufinfo_t *); extern int mmd_getcnt(multidata_t *, uint_t *, uint_t *); extern int mmd_addpdesc(multidata_t *, pdescinfo_t *, pdesc_t **, int); extern void mmd_rempdesc(pdesc_t *); extern pdesc_t *mmd_getfirstpdesc(multidata_t *, pdescinfo_t *); extern pdesc_t *mmd_getlastpdesc(multidata_t *, pdescinfo_t *); extern pdesc_t *mmd_getnextpdesc(pdesc_t *, pdescinfo_t *); extern pdesc_t *mmd_getprevpdesc(pdesc_t *, pdescinfo_t *); extern int mmd_adjpdesc(pdesc_t *, pdescinfo_t *); extern int mmd_transform(pdesc_t *, mblk_t **); extern int mmd_dupbufs(multidata_t *, mblk_t **, mblk_t **); extern int mmd_getpdescinfo(pdesc_t *, pdescinfo_t *); extern int mmd_addpattr(multidata_t *, pdesc_t *, pattrinfo_t *, pattr_t **, int); extern void mmd_rempattr(pattr_t *); extern pattr_t *mmd_getpattr(multidata_t *, pdesc_t *, pattrinfo_t *); The regular freeb(9F) or freemsg(9F) may be used to deallocate a Multidata message block and its associated data block containing the metadata. A Multidata message block may also be duplicated by dupb(9F) or dupmsg(9F), as well as copied by copyb(9F) or copymsg(9F). Because the data block contains metadata, the following STREAMS routines will return failures: msgpullup(9F), pullupmsg(9F), adjmsg(9F). Modules should not be calling those functions on Multidata message blocks. A producing module is expected to negotiate its intention of using Multidata to the consuming module(s). The negotiation between IP and the DLS provider is done via a DL_CAPAB (PSARC/2001/070) sub-capability. The sub-capability definitions are as follows: In , #define DL_CAPAB_MDT 0x04 /* Multidata Transmit capability */ /* * Multidata Transmit sub-capability (follows dl_capability_sub_t) */ typedef struct { t_uscalar_t mdt_version; /* interface version */ t_uscalar_t mdt_flags; /* flags */ t_uscalar_t mdt_hdr_head; /* minimum leading header space */ t_uscalar_t mdt_hdr_tail; /* minimum trailing header space */ } dl_capab_mdt_t; /* * Multidata Transmit revision definition history */ #define MDT_CURRENT_VERSION 0x01 #define MDT_VERSION_1 0x01 /* * mdt_flags values */ #define DL_CAPAB_MDT_ENABLE 0x01 /* enable Multidata Transmit */ A set of Multidata packet attributes are defined, and used by IP and the DLS provider: In , /* Attribute types and structures */ #define PATTR_DSTADDRSAP 0x1 /* destination physical address+SAP */ #define PATTR_SRCADDRSAP 0x2 /* source physical address+SAP */ /* Structure shared by {source,destination} physical address+SAP attributes */ typedef struct pattr_addr_s { uint8_t addr_is_group; /* address is broadcast or multicast */ uint8_t addr_len; /* length of address */ uint8_t addr[1]; /* address */ } pattr_addr_t; DETAILS ------- This proposal changes the appearance of IP packets between IP and the underlying DLPI driver when the MDT functionality is enabled and negotiated and the packets are eligible for MDT. Packets will be labeled with the M_MULTIDATA message type, and any intermediate STREAMS modules may not recognize packets of this type. To mitigate this problem, we won't break IPSEC, IPQOS, CGTP, and IPMP because we can detect when they are enabled and disable MDT accordingly. The IPSEC and IPQOS checks are special, in that they're not only done during ip_md_out_fastpath() -- called when the connection is first established -- but also during every transmit. This is to handle the case where the policies get introduced after the connection is established. For CGTP, we check the IRE. For IPMP, we check the ILL every time we transmit, and if the failover ILL doesn't support MDT, we break the packets out. We don't do MDT for IPQOS, we use the same check as IPSEC. We will enable the MDT functionality by default in Solaris 10. In order to reduce the default impact of the new functionality on innocent and unsuspecting third-party modules, rendering it suitable for inclusion in a patch release, we propose to leave it disabled by default in patches. Customers who want to use the new functionality can then choose to enable it after understanding the issues involved. No mechanism is proposed to detect the insertion/removal of STREAMS modules. Doing this would require per-packet checkts of the STREAMS plumbing to guard against module insertion/removal. This would affect performance for all IP users. Solaris should have a general mechanism to allow plumbing-specific optimizations. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Sep 24 12:10:32 2002 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="APx/EWu26z" Content-Transfer-Encoding: 7bit Date: Tue, 24 Sep 2002 15:06:28 -0400 From: James Carlson To: psarc@sac.eng.sun.com Subject: Fwd: ARC contract for MDT (PSARC/2002/276) Content-Length: 9085 --APx/EWu26z Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I've placed a copy of this signed contract in the case directory as 'contract-001'. --APx/EWu26z Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Length: 7338 Content-Type: MULTIPART/mixed; BOUNDARY=Fall_of_Woodcocks_161_000 Received: from eastmail1bur.East.Sun.COM (eastmail1bur [129.148.9.49]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g8OIuPg17042 for ; Tue, 24 Sep 2002 14:56:25 -0400 (EDT) Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OIuJvN024771 for ; Tue, 24 Sep 2002 14:56:25 -0400 (EDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.17.55]) by sunmail3.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g8OIuIm08185; Tue, 24 Sep 2002 11:56:18 -0700 (PDT) Received: from orcas (orcas.Eng.Sun.COM [129.146.86.80]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g8OIuHda295289; Tue, 24 Sep 2002 11:56:17 -0700 (PDT) Message-Id: <200209241856.g8OIuHda295289@jurassic.eng.sun.com> Reply-To: Chris Schmechel X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_15 SunOS 5.10 sun4u sparc X-DCC-carlson-at-sun-Metrics: purol 1019; Body=1 Fuz1=1 Fuz2=1 From: Chris Schmechel To: james.d.carlson@sun.com Cc: adi.masputra@sun.com Subject: ARC contract for MDT (PSARC/2002/276) Date: Tue, 24 Sep 2002 11:55:48 -0700 (PDT) --Fall_of_Woodcocks_161_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hSLI2fTv/e2foN4m95EZ6A== Jim, I've attached the approved ARC contract by both parties. Thanks, Chris ------------- Begin Forwarded Message ------------- Date: Tue, 24 Sep 2002 11:47:22 -0700 (PDT) From: Jay Jayachandran Subject: ARC contract for MDT (PSARC/2002/276) To: mimi.wong@sun.com Cc: Jay.Jayachandran@sun.com, Frank.Dimambro@sun.com, Chris.Schmechel@eng.sun.com, adi.masputra@sun.com, deepak.bhagat@sun.com MIME-Version: 1.0 Chris, Mimi, I approve the attached ARC contract-001 for MDT (PSARC/2002/276) from CONSUMER end. Jay Jayachandran Manager, NSPG Software group ------------- Begin Forwarded Message ------------- Date: Tue, 24 Sep 2002 11:11:30 -0700 (PDT) From: Chris Schmechel Subject: ARC contract for MDT (PSARC/2002/276) To: jay.jayachandran@sun.com Cc: adi.masputra@sun.com, frank.dimambro@sun.com, mimi.wong@sun.com Jay, I've attached the ARC contract for MDT (PSARC/2002/276) between SNT and N&S/Cassini. Please review and approve. I'll add your approval information afterwards. We have already approved the contract on our end. Let me know if you have any questions. Thanks again, Chris Schmechel ------------- End Forwarded Message ------------- ------------- End Forwarded Message ------------- --Fall_of_Woodcocks_161_000 Content-Type: TEXT/plain; name=contract-001; charset=us-ascii Content-Description: contract-001 Content-MD5: /ysPTv296N6FuHsIDPbNSA== @(#)/shared/sac/doc/templates/contract [1.5 00/04/06] CONTRACT FOR CONTRACT PRIVATE INTERFACES 0. Number: PSARC/2002/276-001 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: OS/Networking Department or Group: Internet Engineering Bugtraq Category/SubCategory: kernel/multidata Responsible Manager: Mimi Wong 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: OS/Networking Department or Group: N&S/Cassini Bugtraq Category/SubCategory: ethernet_cassini/cassini_sw Responsible Manager: Jay Jayachandran 4. The INTERFACES are: DL_CAPABILITY_REQ interface for detecting and enabling DLS provider capability. DL_CAPAB_MDT MDT Sub-capability Primitive Multidata Interface API interfaces for multiple packet transmission and reception through TCP/IP stack and network device driver. As described in the "Multidata Interface Design Specification" document which supplemented PSARC/2002/276. 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing these INTERFACES is: PSARC/2001/070 PSARC/2002/276 7. Changes to INTERFACES requires ARC approval. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same bundle, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same bundle, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES, and requires execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The SUPPLIER will provide the CONSUMER with specifications for the DL_CAPABILITY_REQ, DL_CAPAB_MDT, and the Multidata Interface API. The SUPPLIER will gain agreement from the CONSUMER that the interfaces being proposed are sufficient to support the CONSUMERS needs prior to submitting the interfaces for ARC approval. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: The SUPPLIER agrees to develop, test and support the PSARC/2001/070 API within the IP network stack "ip" according to the specification provided with "DL_CAPAB_MDT" implementation of "DL_CAPABILITY_REQ" which accompanied PSARC/2002/276. The SUPPLIER agrees to develop, test and support the Multidata Interface API within the IP network stack "ip" according to the specification provided with MDT implementation of the Multidata Interface API which accompanied PSARC/2002/276. The CONSUMER agrees to develop, test and support the PSARC/2001/070 API within the Cassini device driver "ce" according to the specification provided with "DL_CAPAB_MDT implementation of DL_CAPABILITY_REQ" which accompanied PSARC/2002/276. The CONSUMER agrees to develop, test and support the Multidata Interface API within the Cassini device driver "ce" according to the specification provided with MDT implementation of the Multidata Interface API which accompanied PSARC/2002/276. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The PSARC/2002/276 API(s) between MDT and Cassini are documented as a supplement document as part of the case materials. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: Changes to the interface will be tested by the SUPPLIER using the existing test suites in addition to the exposure provided by ON. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: This contract will terminate after mutual signed agreement between SUPPLIER and CONSUMER. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Mimi Wong Date: 23-Sep-2002 For CONSUMER: Jay Jayachandran Date: 24-Sep-2002 For ARC: Date: A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. An e-mail alias "contract-yyyy-nnn-ss@sun.com" shall be created via netadmin for notification of any desired changes. The SUPPLIER shall be the alias owner. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: --Fall_of_Woodcocks_161_000-- --APx/EWu26z-- From sacadmin Tue Sep 24 15:04:15 2002 Date: Tue, 24 Sep 2002 15:01:48 -0700 (PDT) From: Ralph Campbell Subject: Re: 2002/276 TCP Multi-Data Transmit To: psarc@sac.eng.sun.com Cc: Adi.Masputra@Sun.Com, chris.schmechel@Sun.Com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q2bOkfKcS/93l/ZjQkynHg== Content-Length: 184 Just out of curiosity, do you know how this interface will change when the FireEngine project (2002/433) delivers? It sounds like you are trying to address some of the same problems. From sacadmin Tue Sep 24 15:32:49 2002 Date: Tue, 24 Sep 2002 15:29:00 -0700 (PDT) From: Adi Masputra To: Ralph Campbell cc: psarc@sac.eng.sun.com, , Subject: Re: 2002/276 TCP Multi-Data Transmit MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 646 Ralph Campbell writes: > Just out of curiosity, do you know how this interface will change > when the FireEngine project (2002/433) delivers? It'll probably stay as it is; FireEngine may use the Multidata APIs in the same way that the current stack uses them. There may be enhancements here and there throughout the Multidata implementation (or interface), but we won't know until after the FireEngine development is completed. > It sounds like you are trying to address some of the same problems. Multidata addresses portions of the bulk data transfer problems; FireEngine takes on the rest (and more). The two should work together. Adi From sacadmin Tue Sep 24 19:07:35 2002 Date: Tue, 24 Sep 2002 19:03:15 -0700 (PDT) From: Chris Schmechel Subject: Re: 2002/276 TCP Multi-Data Transmit To: psarc@sac.eng.sun.com Cc: adi.masputra@sun.com, chris.schmechel@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SL7V4MuTUYZceATvuXZanA== Content-Length: 1555 Hi, Here are my proposed changes ip(7P) man pages changes to accompany this case. We would like to document the ip_multidata_outbound interface so that users have the ability to enable/disable MDT. Thanks, Chris *** ip-orig Tue Sep 24 11:45:47 2002 --- ip Tue Sep 24 12:27:24 2002 *************** *** 268,287 **** --- 268,294 ---- Protocols ip(7P) the reassembly queues if the complete datagram is not recon- structed within a short time period. Errors in sending discovered at the network interface driver layer are passed by IP back up to the user process. + Multi-Data Transmit allows more than one packet to be sent from + the IP module to another in a given call, thereby reducing the + per-packet processing costs. The behavior of Multi-Data Transmit + can be overrideen by using ndd(1M) to set the /dev/ip variable, + ip_multidata_outbound to 0. Note, the IP module will only initiate + Multi-Data Transmit if the network interface driver supports it. + SEE ALSO ndd(1M), read(2), write(2), bind(3SOCKET), connect(3SOCKET), getsockopt(3SOCKET), recv(3SOCKET), send(3SOCKET), defaul- trouter(4), icmp(7P), if_tcp(7P), inet(7P), ip6(7P), ipsec(7P),routing(7P), tcp(7P), udp(7P) Braden, R., RFC 1122, Requirements for Internet Hosts - Com- munication Layers, Information Sciences Institute, Univer- sity of Southern California, October 1989. From sacadmin Wed Sep 25 06:16:28 2002 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 25 Sep 2002 09:12:20 -0400 From: James Carlson To: Ralph Campbell , Adi Masputra Cc: psarc@sac.eng.sun.com, Subject: Re: 2002/276 TCP Multi-Data Transmit Content-Length: 1764 Adi Masputra writes: > Ralph Campbell writes: > > Just out of curiosity, do you know how this interface will change > > when the FireEngine project (2002/433) delivers? > > It'll probably stay as it is; FireEngine may use the Multidata > APIs in the same way that the current stack uses them. There > may be enhancements here and there throughout the Multidata > implementation (or interface), but we won't know until after the > FireEngine development is completed. Fireengine mostly addresses perimeter issues, while MDT is a data representation issue. The one bit of conceptual overlap is that Fireengine defines a way to link multiple packets together to be returned from the processing modules rather than the traditional putnext() on each packet, and MDT seems to deal in multiple packets as well. The differences are that MDT allows the packet creator to make a list of packet headers that all refer to a common block of data, and that MDT crosses the boundary of DLPI and into the driver. It's a very specific optimization for STREAMS itself. In Fireengine, each MDT message would be seen as an individual independent 'packet' on the list (and wouldn't see the embedded multiple headers), and the list Fireengine uses is related to breaking apart the direct linkage to STREAMS entry points. So, I see these two as being separate issues. (Though the code involved is in close proximity and, as the submitters say, it's not unlikely that the two projects need to coordinate. Fortunately, they share a manager in common ...) -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Sep 25 10:12:24 2002 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 25 Sep 2002 13:08:19 -0400 From: James Carlson To: psarc@sac.eng.sun.com cc: Adi.Masputra@Sun.COM, chris.schmechel@Sun.COM Subject: 2002/276 TCP Multi-Data Transmit Content-Length: 287 This fast-track request was approved at today's PSARC meeting. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Oct 30 10:44:01 2002 Date: Wed, 30 Oct 2002 10:38:41 -0800 (PST) From: Adi Masputra To: psarc@sac.eng.sun.com cc: masputra@eng.sun.com, Subject: 2002/276 TCP Multi-Data Transmit MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 467 This is a minor update to the case. The case proposed for the IP NDD variable 'ip_multidata_outbound' to be set to 1 (turned on) for S10. Due to a generic STREAMS problem related to dynamic module insertion below IP (see 4771245), we plan on turning this feature off (setting it to 0) by default in S10 until the problem is fixed. The problem stated in 4771245 will be fixed by S10 FCS, and once it's putbacked, the MDT feature will be turned on by default. Adi