From rsb@sac.sfbay.sun.com Wed Sep 9 14:02:21 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n89L2LVU013562 for ; Wed, 9 Sep 2009 14:02:21 -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 n89L2IGR052012; Wed, 9 Sep 2009 15:02:21 -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 <0KPQ00C0J2FWC100@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Sep 2009 14:02:20 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPQ007372FWCLA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Sep 2009 14:02:20 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n89L2JIp036265; Wed, 09 Sep 2009 14:02:19 -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 n89L2FYT013556; Wed, 09 Sep 2009 14:02:15 -0700 (PDT) Received: (from rsb@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n89L2FFU013552; Wed, 09 Sep 2009 16:02:15 -0500 (CDT) Date: Wed, 09 Sep 2009 16:02:15 -0500 (CDT) From: Rich.Brown@sun.com Subject: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] To: PSARC-ext@sun.com Cc: Rich.Brown@sun.com, chunli.zhang@sun.com, siddheshwar.mahesh@sun.com Message-id: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 13455 I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang. This case proposes new interfaces to support copy reduction in the I/O path especially for file sharing services. Minor binding is requested. This times out on Wednesday, 16 September, 2009. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Copy Reduction Interfaces 1.2. Name of Document Author/Supplier: Author: Mahesh Siddheshwar, Chunli Zhang 1.3 Date of This Document: 09 September, 2009 4. Technical Description == Introduction/Background == Zero-copy (copy avoidance) is essentially buffer sharing among multiple modules that pass data between the modules. This proposal avoids the data copy in the READ/WRITE path of filesystems, by providing a mechanism to share data buffers between the modules. It is intended to be used by network file sharing services like NFS, CIFS or others. Although the buffer sharing can be achieved through a few different solutions, any such solution must work with File Event Monitors (FEM monitors)[1] installed on the files. The solution must allow the underlying filesystem to maintain any existing file range locking in the filesystem. The proposed solution provides extensions to the existing VOP interface to request and return buffers from a filesystem. The buffers are then used with existing VOP_READ/VOP_WRITE calls with minimal changes. == Proposed Changes == VOP Extensions for Zero-Copy Support ======================================== a. Extended struct uio, xuio_t The following proposes an extensible uio structure that can be extended for multiple purposes. For example, an immediate extension, xu_zc, is to be used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned zero-copy buffers, as well as to be passed to the existing VOP_READ/VOP_WRITE calls for normal read/write operations. Another example of extension, xu_aio, is intended to replace uioa_t for async I/O. This new structure, xuio_t, contains the following: - the existing uio structure (embedded) as the first member - additional fields to support extensibility - a union of all the defined extensions The following uio_extflag is added to indicate that an uio structure is indeed an xuio_t: #define UIO_XUIO 0x004 /* Structure is xuio_t */ The following uio_extflag will be removed after uioa_t has been converted to xuio_t: #define UIO_ASYNC 0x002 /* Structure is xuio_t */ The project team has commitment from the networking team to remove the current use of uioa_t and use the proposed extensions (CR 6880095). The definition of xuio_t is: typedef struct xuio { uio_t xu_uio; /* Embedded UIO structure */ /* Extended uio fields */ enum xuio_type xu_type; /* What kind of uio structure? */ union { /* Async I/O Support */ struct { uint32_t xu_a_state; /* state of async i/o */ uint32_t xu_a_state; /* state of async i/o */ ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ void *xu_a_hwst[4]; /* opaque hardware state */ uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ } xu_aio; /* Zero Copy Support */ struct { enum uio_rw xu_zc_rw; /* the use of the buffer */ void *xu_zc_priv; /* fs specific */ } xu_zc; } xu_ext; } xuio_t; where xu_type is currently defined as: typedef enum xuio_type { UIOTYPE_ASYNCIO, UIOTYPE_ZEROCOPY } xuio_type_t; New uio extensions can be added by defining a new xuio_type_t, and adding a new member to the xu_ext union. b. Requesting zero-copy buffers #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, caller_context_t *); This function requests buffers associated with file vp in preparation for a subsequent zero copy read or write. The extended uio_t -- xuio_t is used to pass the parameters and results. Only the following fields of xuio_t are relevant to this call. uiozcp->xu_uio.uio_resid: used by the caller to specify the total length of the buffer. uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the file offset it would like the buffers to be associated with. A value of -1 indicates that the provider returns buffers that are not associated with a particular offset. These are defined to be anonymous buffers. Anonymous buffers may be used for requesting a write buffer to receive data over the wire, where file offset might not be handily available. uiozcp->xu_uio.uio_iov: used by the provider to return an array of buffers (in case multiple filesystem buffers have to be reserved for the requested length). uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the number of returned buffers (length of array uiop->uio_iov). Other arguments to the call include: vp: vnode pointer of the associated file. rwflag: Indicates what the buffers are to be subsequently used for. Expected values are UIO_READ for VOP_READ() and UIO_WRITE for VOP_WRITE(). Upon successful completion, the function returns 0. One or more buffers may be returned as referenced by uio_iov[] and uio_iovcnt members. uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio is set to UIOTYPE_ZEROCOPY. The caller can use this returned xuio_t in a subsequent call to VOP_READ or VOP_WRITE. In the case of UIO_READ buffers, the caller should reference the uio_iov[] buffers only after a successful VOP_READ(). In the case of UIO_WRITE buffers, the caller should not reference the uio_iov[] buffers after a successful VOP_WRITE. In the case of anonymous buffers, the caller should set the value of uio_loffset before such a read/write call. This should be done only in the case of anonymous buffers. The member xu_zc_priv of the extended uio structure for zero-copy is a private handle that may be used by the provider to track its buffer headers or any other private information that is useful to map the loaned iovec entries to its internal buffers. The xu_zc_priv member is private to the provider and should not be changed or interpreted in anyway by the callers. Upon failure, the function returns EINVAL error and the content of uiozcp should be ignored by the callers. The provider must fail the request if it is unable to satisfy the complete request (ie. it must not return buffers that cover only a part of the length that was asked for). Probable causes for failure include: - the filesystem is short on buffers to loan out at the time - the filesystem determines that it's not efficient to take the zero-copy path based on the input parameters c. Returning zero-copy buffers #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ fop_retzcbuf(vp, uiozcp, cr, ct) int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); This function returns the buffers previously obtained via a call to VOP_REQZCBUF(). In case multiple buffers are associated with the uio_iov[], all the buffers associated with the uiozcp are returned. In other words, VOP_RETZCBUF() should only be called once per xuio_t. The caller should not reference any of the uio_iov[] members after a return. d. New VFS feature attributes A new VFS feature attribute is introduced for the support of zero-copy interface. #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 Zero-copy is an optional feature. A filesystem supporting the zero-copy interface (ie. the Interface Provider) must set this VFS feature attribute through the VFS Feature Registration interface[2]. Callers of the interface (ie. Interface Consumer) must check the presence of support through vfs_has_feature() interface. The intermediate fop routines (called via the VOP_* macros) will detect if the interfaces are being called for a filesystem that does not support zero-copy and will return ENOTSUP. INTERFACE TABLE +==========================================================================================+ |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments +==========================================================================================+ VOP_REQZCBUF() |Consolidation |This | New VOP calls fop_reqzcbuf() |Private |Document | VOP_RETZCBUF() | | | fop_retzcbuf() | | | | | | VFSFT_ZEROCOPY_SUPPORTED | | | New VFS feature definition | | | xuio_t | | | Extended uio_t definition | | | | | | uioa_t | | | Deprecated UIO_ASYNC | | | Deprecated +==========================================================================================+ * The project's deliverables will all go into the OS/NET Consolidation, so no contracts are required. == Using the New VOP Interfaces for Zero-copy == VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with VOP_READ() or VOP_WRITE() to implement zero-copy read or write. a. Read In a normal read, the consumer allocates the data buffer and passes it to VOP_READ(). The provider initiates the I/O, and copies the data from its own cache buffer to the consumer supplied buffer. To avoid the copy (initiating a zero-copy read), the consumer first calls VOP_REQZCBUF() to inform the provider to prepare to loan out its cache buffer. It then calls VOP_READ(). After the call returns, the consumer has direct access to the cache buffer loaned out by the provider. After processing the data, the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to the provider. Here is an illustration using NFSv4 read over TCP: rfs4_op_read(nfs_argop4 *argop, ...) { int zerocopy; xuio_t *xuio; ... xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); setup length, offset, etc; if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { zerocopy = 0; allocate the data buffer the normal way; initialize (uio_t *)xuio; } else { /* xuio has been setup by the provider */ zerocopy = 1; } do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); ... if (zerocopy) { setup callback mechanism that makes the network layer call VOP_RETZCBUF() and free xuio after the data is sent out; } else { kmem_free(xuio, sizeof(xuio_t)); } } b. Write In a normal write, the consumer allocates the data buffer, loads the data, and passes the buffer to VOP_WRITE(). The provider copies the data from the consumer supplied buffer to its own cache buffer, and starts the I/O. To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to grab a cache buffer from the provider. It loads the data directly to the loaned cache buffer, and calls VOP_WRITE(). After the call returns, the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to the provider. Here is an illustration using NFSv4 write via RDMA: rfs4_op_write(nfs_argop4 *argop, ...) { int zerocopy; xuio_t *xuio; ... xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); setup length, offset, etc; if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { zerocopy = 0; allocate the data buffer the normal way; initialize (uio_t *)xuio; xdrrdma_read_from_client(...); } else { /* xuio has been setup by the provider */ zerocopy = 1; xdrrdma_zcopy_read_from_client(..., xuio); } do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); ... if (zerocopy) { VOP_RETZCBUF(vp, xuio, cr, &ct); } kmem_free(xuio, sizeof(xuio_t)); } References: [1] PSARC/2003/172 File Event Monitoring [2] PSARC/2007/227 VFS Features 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 gdamore@sun.com Wed Sep 9 15:08:19 2009 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 n89M8IpD010236 for ; Wed, 9 Sep 2009 15:08:19 -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 n89M8CLb006445 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 10 Sep 2009 06:08:18 +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 <0KPQ00H0N5HS9R00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 09 Sep 2009 15:08:16 -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 <0KPQ004PO5HSAHA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 09 Sep 2009 15:08:16 -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 n89M8Gc7027545 for ; Wed, 09 Sep 2009 15:08:16 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPQ00400589N700@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 09 Sep 2009 15:08:16 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPQ00HWU5HRXO40@fe-sfbay-09.sun.com>; Wed, 09 Sep 2009 15:08:16 -0700 (PDT) Date: Wed, 09 Sep 2009 15:08:15 -0700 From: "Garrett D'Amore" Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Chunli.Zhang@sun.com, Siddheshwar.Mahesh@sun.com Message-id: <4AA8274F.9070803@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 14615 I've not had time to go over all this yet, but do we really believe this kind of change is fast track appropriate? I have a feeling that this is a significant enough core change with implications for a variety of project teams, that maybe this one ought to be a full case. I'd be a bit uncomfortable allowing this one to just time out with a single +1, which is the normal rule for fast tracks. Am I alone in this particular concern? Are there any implications for unbundled 3rd party filesystems? - Garrett Rich.Brown@Sun.COM wrote: > I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang. > This case proposes new interfaces to support copy reduction in the I/O path > especially for file sharing services. > > Minor binding is requested. > > This times out on Wednesday, 16 September, 2009. > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Copy Reduction Interfaces > 1.2. Name of Document Author/Supplier: > Author: Mahesh Siddheshwar, Chunli Zhang > 1.3 Date of This Document: > 09 September, 2009 > 4. Technical Description > > == Introduction/Background == > > Zero-copy (copy avoidance) is essentially buffer sharing > among multiple modules that pass data between the modules. > This proposal avoids the data copy in the READ/WRITE path > of filesystems, by providing a mechanism to share data buffers > between the modules. It is intended to be used by network file > sharing services like NFS, CIFS or others. > > Although the buffer sharing can be achieved through a few different > solutions, any such solution must work with File Event Monitors > (FEM monitors)[1] installed on the files. The solution must > allow the underlying filesystem to maintain any existing file > range locking in the filesystem. > > The proposed solution provides extensions to the existing VOP > interface to request and return buffers from a filesystem. The > buffers are then used with existing VOP_READ/VOP_WRITE calls with > minimal changes. > > > == Proposed Changes == > > VOP Extensions for Zero-Copy Support > ======================================== > > a. Extended struct uio, xuio_t > > The following proposes an extensible uio structure that can be extended for > multiple purposes. For example, an immediate extension, xu_zc, is to be > used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned > zero-copy buffers, as well as to be passed to the existing VOP_READ/VOP_WRITE > calls for normal read/write operations. Another example of extension, > xu_aio, is intended to replace uioa_t for async I/O. > > This new structure, xuio_t, contains the following: > > - the existing uio structure (embedded) as the first member > - additional fields to support extensibility > - a union of all the defined extensions > > The following uio_extflag is added to indicate that an uio structure is > indeed an xuio_t: > > #define UIO_XUIO 0x004 /* Structure is xuio_t */ > > The following uio_extflag will be removed after uioa_t has been converted > to xuio_t: > > #define UIO_ASYNC 0x002 /* Structure is xuio_t */ > > The project team has commitment from the networking team to remove > the current use of uioa_t and use the proposed extensions (CR 6880095). > > The definition of xuio_t is: > > typedef struct xuio { > uio_t xu_uio; /* Embedded UIO structure */ > > /* Extended uio fields */ > enum xuio_type xu_type; /* What kind of uio structure? */ > > union { > > /* Async I/O Support */ > struct { > uint32_t xu_a_state; /* state of async i/o */ > uint32_t xu_a_state; /* state of async i/o */ > ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ > uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ > void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ > void *xu_a_hwst[4]; /* opaque hardware state */ > uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ > } xu_aio; > > /* Zero Copy Support */ > struct { > enum uio_rw xu_zc_rw; /* the use of the buffer */ > void *xu_zc_priv; /* fs specific */ > } xu_zc; > > } xu_ext; > } xuio_t; > > where xu_type is currently defined as: > > typedef enum xuio_type { > UIOTYPE_ASYNCIO, > UIOTYPE_ZEROCOPY > } xuio_type_t; > > New uio extensions can be added by defining a new xuio_type_t, and adding a > new member to the xu_ext union. > > b. Requesting zero-copy buffers > > #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ > fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) > > int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, > caller_context_t *); > > This function requests buffers associated with file vp in preparation for a > subsequent zero copy read or write. The extended uio_t -- xuio_t is used > to pass the parameters and results. Only the following fields of xuio_t are > relevant to this call. > > uiozcp->xu_uio.uio_resid: used by the caller to specify the total length > of the buffer. > > uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the file offset > it would like the buffers to be associated with. A value of -1 > indicates that the provider returns buffers that are not associated > with a particular offset. These are defined to be anonymous buffers. > Anonymous buffers may be used for requesting a write buffer to receive > data over the wire, where file offset might not be handily available. > > uiozcp->xu_uio.uio_iov: used by the provider to return an array of buffers > (in case multiple filesystem buffers have to be reserved for the > requested length). > > uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the number of > returned buffers (length of array uiop->uio_iov). > > Other arguments to the call include: > > vp: vnode pointer of the associated file. > > rwflag: Indicates what the buffers are to be subsequently used for. > Expected values are UIO_READ for VOP_READ() and UIO_WRITE for > VOP_WRITE(). > > Upon successful completion, the function returns 0. One or more > buffers may be returned as referenced by uio_iov[] and uio_iovcnt members. > uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio is set > to UIOTYPE_ZEROCOPY. > > The caller can use this returned xuio_t in a subsequent call to VOP_READ > or VOP_WRITE. In the case of UIO_READ buffers, the caller should > reference the uio_iov[] buffers only after a successful VOP_READ(). > In the case of UIO_WRITE buffers, the caller should not reference > the uio_iov[] buffers after a successful VOP_WRITE. > > In the case of anonymous buffers, the caller should set the value of > uio_loffset before such a read/write call. This should be done only in > the case of anonymous buffers. > > The member xu_zc_priv of the extended uio structure for zero-copy is > a private handle that may be used by the provider to track its buffer > headers or any other private information that is useful to map the > loaned iovec entries to its internal buffers. The xu_zc_priv member > is private to the provider and should not be changed or interpreted > in anyway by the callers. > > Upon failure, the function returns EINVAL error and the content > of uiozcp should be ignored by the callers. The provider must fail the > request if it is unable to satisfy the complete request (ie. it must > not return buffers that cover only a part of the length that was > asked for). > > Probable causes for failure include: > > - the filesystem is short on buffers to loan out at the time > - the filesystem determines that it's not efficient to take the > zero-copy path based on the input parameters > > c. Returning zero-copy buffers > > #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ > fop_retzcbuf(vp, uiozcp, cr, ct) > > int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); > > This function returns the buffers previously obtained via a call > to VOP_REQZCBUF(). In case multiple buffers are associated with the > uio_iov[], all the buffers associated with the uiozcp are returned. > In other words, VOP_RETZCBUF() should only be called once per xuio_t. > The caller should not reference any of the uio_iov[] members after > a return. > > d. New VFS feature attributes > > A new VFS feature attribute is introduced for the support of > zero-copy interface. > > #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 > > Zero-copy is an optional feature. A filesystem supporting the > zero-copy interface (ie. the Interface Provider) must set this > VFS feature attribute through the VFS Feature Registration > interface[2]. Callers of the interface (ie. Interface Consumer) > must check the presence of support through vfs_has_feature() interface. > The intermediate fop routines (called via the VOP_* macros) will detect > if the interfaces are being called for a filesystem that does not support > zero-copy and will return ENOTSUP. > > INTERFACE TABLE > +==========================================================================================+ > |Proposed |Specified | > |Stability |in what | > Interface Name |Classification |Document? | Comments > +==========================================================================================+ > VOP_REQZCBUF() |Consolidation |This | New VOP calls > fop_reqzcbuf() |Private |Document | > VOP_RETZCBUF() | | | > fop_retzcbuf() | | | > | | | > VFSFT_ZEROCOPY_SUPPORTED | | | New VFS feature definition > | | | > xuio_t | | | Extended uio_t definition > | | | > | | | > uioa_t | | | Deprecated > UIO_ASYNC | | | Deprecated > +==========================================================================================+ > > * The project's deliverables will all go into the OS/NET > Consolidation, so no contracts are required. > > > == Using the New VOP Interfaces for Zero-copy == > > VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with > VOP_READ() or VOP_WRITE() to implement zero-copy read or write. > > a. Read > > In a normal read, the consumer allocates the data buffer and passes it to > VOP_READ(). The provider initiates the I/O, and copies the data from its > own cache buffer to the consumer supplied buffer. > > To avoid the copy (initiating a zero-copy read), the consumer first calls > VOP_REQZCBUF() to inform the provider to prepare to loan out its cache > buffer. It then calls VOP_READ(). After the call returns, the consumer > has direct access to the cache buffer loaned out by the provider. After > processing the data, the consumer calls VOP_RETZCBUF() to return the loaned > cache buffer to the provider. > > Here is an illustration using NFSv4 read over TCP: > > rfs4_op_read(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > } > do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > setup callback mechanism that makes the network layer call > VOP_RETZCBUF() and free xuio after the data is sent out; > } else { > kmem_free(xuio, sizeof(xuio_t)); > } > } > > b. Write > > In a normal write, the consumer allocates the data buffer, loads the data, > and passes the buffer to VOP_WRITE(). The provider copies the data from > the consumer supplied buffer to its own cache buffer, and starts the I/O. > > To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to > grab a cache buffer from the provider. It loads the data directly to > the loaned cache buffer, and calls VOP_WRITE(). After the call returns, > the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to > the provider. > > Here is an illustration using NFSv4 write via RDMA: > > rfs4_op_write(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > xdrrdma_read_from_client(...); > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > xdrrdma_zcopy_read_from_client(..., xuio); > } > do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > VOP_RETZCBUF(vp, xuio, cr, &ct); > } > kmem_free(xuio, sizeof(xuio_t)); > } > > > References: > [1] PSARC/2003/172 File Event Monitoring > [2] PSARC/2007/227 VFS Features > > > 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 siddheshwar.mahesh@sun.com Wed Sep 9 15:30:40 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n89MUdOC028632 for ; Wed, 9 Sep 2009 15:30:39 -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 n89MUXn5005341; Wed, 9 Sep 2009 23:30:36 +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 <0KPQ005056IZJS00@brm-avmta-1.central.sun.com>; Wed, 09 Sep 2009 16:30:35 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPQ00IRE6IY6340@brm-avmta-1.central.sun.com>; Wed, 09 Sep 2009 16:30:34 -0600 (MDT) Received: from dhcp-umpk17-229-151.sfbay.sun.com (dhcp-umpk17-229-151.SFBay.Sun.COM [129.146.229.151]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n89MUYFb111405; Wed, 09 Sep 2009 15:30:34 -0700 (PDT) Date: Wed, 09 Sep 2009 15:30:01 -0700 From: Mahesh Siddheshwar Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <4AA8274F.9070803@sun.com> To: "Garrett D'Amore" Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, Chunli.Zhang@sun.com Message-id: <4AA82C69.1000904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <4AA8274F.9070803@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 15487 Garrett D'Amore wrote: > I've not had time to go over all this yet, but do we really believe > this kind of change is fast track appropriate? I have a feeling that > this is a significant enough core change with implications for a > variety of project teams, that maybe this one ought to be a full > case. I'd be a bit uncomfortable allowing this one to just time out > with a single +1, which is the normal rule for fast tracks. > > Am I alone in this particular concern? > > Are there any implications for unbundled 3rd party filesystems? Not unless the 3rd party filesystem wants to support this optional feature. This is covered in section (d) of the spec. The intermediate fop routines handle it correctly. Regards, Mahesh > - Garrett > > > Rich.Brown@Sun.COM wrote: >> I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli >> Zhang. >> This case proposes new interfaces to support copy reduction in the >> I/O path >> especially for file sharing services. >> >> Minor binding is requested. >> >> This times out on Wednesday, 16 September, 2009. >> >> >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Copy Reduction Interfaces >> 1.2. Name of Document Author/Supplier: >> Author: Mahesh Siddheshwar, Chunli Zhang >> 1.3 Date of This Document: >> 09 September, 2009 >> 4. Technical Description >> >> == Introduction/Background == >> >> Zero-copy (copy avoidance) is essentially buffer sharing >> among multiple modules that pass data between the modules. This >> proposal avoids the data copy in the READ/WRITE path of filesystems, >> by providing a mechanism to share data buffers >> between the modules. It is intended to be used by network file >> sharing services like NFS, CIFS or others. >> >> Although the buffer sharing can be achieved through a few different >> solutions, any such solution must work with File Event Monitors >> (FEM monitors)[1] installed on the files. The solution must >> allow the underlying filesystem to maintain any existing file range >> locking in the filesystem. >> >> The proposed solution provides extensions to the existing VOP >> interface to request and return buffers from a filesystem. The >> buffers are then used with existing VOP_READ/VOP_WRITE calls with >> minimal changes. >> >> >> == Proposed Changes == >> >> VOP Extensions for Zero-Copy Support >> ======================================== >> >> a. Extended struct uio, xuio_t >> >> The following proposes an extensible uio structure that can be >> extended for >> multiple purposes. For example, an immediate extension, xu_zc, is >> to be used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to >> pass loaned >> zero-copy buffers, as well as to be passed to the existing >> VOP_READ/VOP_WRITE >> calls for normal read/write operations. Another example of extension, >> xu_aio, is intended to replace uioa_t for async I/O. >> >> This new structure, xuio_t, contains the following: >> >> - the existing uio structure (embedded) as the first member >> - additional fields to support extensibility >> - a union of all the defined extensions >> >> The following uio_extflag is added to indicate that an uio >> structure is >> indeed an xuio_t: >> >> #define UIO_XUIO 0x004 /* Structure is xuio_t */ >> >> The following uio_extflag will be removed after uioa_t has been >> converted to xuio_t: >> >> #define UIO_ASYNC 0x002 /* Structure is xuio_t */ >> >> The project team has commitment from the networking team to remove >> the current use of uioa_t and use the proposed extensions (CR >> 6880095). >> >> The definition of xuio_t is: >> >> typedef struct xuio { >> uio_t xu_uio; /* Embedded UIO structure */ >> >> /* Extended uio fields */ >> enum xuio_type xu_type; /* What kind of uio structure? */ >> >> union { >> >> /* Async I/O Support */ >> struct { >> uint32_t xu_a_state; /* state of async i/o */ >> uint32_t xu_a_state; /* state of async i/o */ >> ssize_t xu_a_mbytes; /* bytes that have been >> uioamove()ed */ >> uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ >> void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ >> void *xu_a_hwst[4]; /* opaque hardware state */ >> uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov >> locked pages */ >> } xu_aio; >> >> /* Zero Copy Support */ >> struct { >> enum uio_rw xu_zc_rw; /* the use of the buffer */ >> void *xu_zc_priv; /* fs specific */ >> } xu_zc; >> >> } xu_ext; >> } xuio_t; >> >> where xu_type is currently defined as: >> >> typedef enum xuio_type { >> UIOTYPE_ASYNCIO, >> UIOTYPE_ZEROCOPY >> } xuio_type_t; >> >> New uio extensions can be added by defining a new xuio_type_t, and >> adding a >> new member to the xu_ext union. >> >> b. Requesting zero-copy buffers >> >> #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ >> fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) >> >> int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, >> caller_context_t *); >> >> This function requests buffers associated with file vp in >> preparation for a >> subsequent zero copy read or write. The extended uio_t -- xuio_t >> is used >> to pass the parameters and results. Only the following fields of >> xuio_t are >> relevant to this call. >> >> uiozcp->xu_uio.uio_resid: used by the caller to specify the total >> length >> of the buffer. >> >> uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the >> file offset >> it would like the buffers to be associated with. A value of >> -1 indicates that the provider returns buffers that are not >> associated >> with a particular offset. These are defined to be anonymous >> buffers. >> Anonymous buffers may be used for requesting a write buffer >> to receive >> data over the wire, where file offset might not be handily >> available. >> >> uiozcp->xu_uio.uio_iov: used by the provider to return an array >> of buffers >> (in case multiple filesystem buffers have to be reserved for >> the >> requested length). >> >> uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the >> number of >> returned buffers (length of array uiop->uio_iov). >> >> Other arguments to the call include: >> >> vp: vnode pointer of the associated file. >> >> rwflag: Indicates what the buffers are to be subsequently used for. >> Expected values are UIO_READ for VOP_READ() and UIO_WRITE >> for >> VOP_WRITE(). >> >> Upon successful completion, the function returns 0. One or more >> buffers may be returned as referenced by uio_iov[] and uio_iovcnt >> members. >> uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio >> is set >> to UIOTYPE_ZEROCOPY. >> >> The caller can use this returned xuio_t in a subsequent call to >> VOP_READ >> or VOP_WRITE. In the case of UIO_READ buffers, the caller should >> reference the uio_iov[] buffers only after a successful VOP_READ(). >> In the case of UIO_WRITE buffers, the caller should not reference >> the uio_iov[] buffers after a successful VOP_WRITE. >> >> In the case of anonymous buffers, the caller should set the value >> of uio_loffset before such a read/write call. This should be done >> only in the case of anonymous buffers. >> The member xu_zc_priv of the extended uio structure for zero-copy >> is a private handle that may be used by the provider to track its >> buffer >> headers or any other private information that is useful to map >> the loaned iovec entries to its internal buffers. The xu_zc_priv >> member >> is private to the provider and should not be changed or >> interpreted in anyway by the callers. >> >> Upon failure, the function returns EINVAL error and the content >> of uiozcp should be ignored by the callers. The provider must >> fail the >> request if it is unable to satisfy the complete request (ie. it must >> not return buffers that cover only a part of the length that was >> asked for). >> >> Probable causes for failure include: >> >> - the filesystem is short on buffers to loan out at the time >> - the filesystem determines that it's not efficient to take the >> zero-copy path based on the input parameters >> c. Returning zero-copy buffers >> >> #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ >> fop_retzcbuf(vp, uiozcp, cr, ct) >> >> int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); >> >> This function returns the buffers previously obtained via a call >> to VOP_REQZCBUF(). In case multiple buffers are associated with the >> uio_iov[], all the buffers associated with the uiozcp are returned. >> In other words, VOP_RETZCBUF() should only be called once per >> xuio_t. >> The caller should not reference any of the uio_iov[] members after >> a return. >> >> d. New VFS feature attributes >> >> A new VFS feature attribute is introduced for the support of >> zero-copy interface. >> >> #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 >> >> Zero-copy is an optional feature. A filesystem supporting the >> zero-copy interface (ie. the Interface Provider) must set this >> VFS feature attribute through the VFS Feature Registration >> interface[2]. Callers of the interface (ie. Interface Consumer) >> must check the presence of support through vfs_has_feature() >> interface. >> The intermediate fop routines (called via the VOP_* macros) will >> detect >> if the interfaces are being called for a filesystem that does not >> support >> zero-copy and will return ENOTSUP. >> >> INTERFACE TABLE >> +==========================================================================================+ >> >> |Proposed |Specified | >> |Stability |in what | >> Interface Name |Classification |Document? | Comments >> +==========================================================================================+ >> >> VOP_REQZCBUF() |Consolidation |This | New VOP calls >> fop_reqzcbuf() |Private |Document | >> VOP_RETZCBUF() | | | >> fop_retzcbuf() | | | >> | | | >> VFSFT_ZEROCOPY_SUPPORTED | | | New VFS >> feature definition >> | | | >> xuio_t | | | Extended >> uio_t definition >> | | | >> | | | >> uioa_t | | | Deprecated >> UIO_ASYNC | | | Deprecated >> +==========================================================================================+ >> >> >> * The project's deliverables will all go into the OS/NET >> Consolidation, so no contracts are required. >> >> >> == Using the New VOP Interfaces for Zero-copy == >> >> VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction >> with >> VOP_READ() or VOP_WRITE() to implement zero-copy read or write. >> a. Read >> >> In a normal read, the consumer allocates the data buffer and >> passes it to >> VOP_READ(). The provider initiates the I/O, and copies the data >> from its >> own cache buffer to the consumer supplied buffer. >> >> To avoid the copy (initiating a zero-copy read), the consumer >> first calls >> VOP_REQZCBUF() to inform the provider to prepare to loan out its >> cache >> buffer. It then calls VOP_READ(). After the call returns, the >> consumer >> has direct access to the cache buffer loaned out by the >> provider. After >> processing the data, the consumer calls VOP_RETZCBUF() to return >> the loaned >> cache buffer to the provider. >> >> Here is an illustration using NFSv4 read over TCP: >> >> rfs4_op_read(nfs_argop4 *argop, ...) >> { >> int zerocopy; >> xuio_t *xuio; >> ... >> xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); >> setup length, offset, etc; >> if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { >> zerocopy = 0; >> allocate the data buffer the normal way; >> initialize (uio_t *)xuio; >> } else { >> /* xuio has been setup by the provider */ >> zerocopy = 1; >> } >> do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); >> ... >> if (zerocopy) { >> setup callback mechanism that makes the network layer >> call >> VOP_RETZCBUF() and free xuio after the data is sent out; >> } else { >> kmem_free(xuio, sizeof(xuio_t)); >> } >> } >> >> b. Write >> >> In a normal write, the consumer allocates the data buffer, loads >> the data, >> and passes the buffer to VOP_WRITE(). The provider copies the >> data from >> the consumer supplied buffer to its own cache buffer, and starts >> the I/O. >> >> To initiate a zero-copy write, the consumer first calls >> VOP_REQZCBUF() to >> grab a cache buffer from the provider. It loads the data >> directly to >> the loaned cache buffer, and calls VOP_WRITE(). After the call >> returns, >> the consumer calls VOP_RETZCBUF() to return the loaned cache >> buffer to >> the provider. >> >> Here is an illustration using NFSv4 write via RDMA: >> >> rfs4_op_write(nfs_argop4 *argop, ...) >> { >> int zerocopy; >> xuio_t *xuio; >> ... >> xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); >> setup length, offset, etc; >> if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { >> zerocopy = 0; >> allocate the data buffer the normal way; >> initialize (uio_t *)xuio; >> xdrrdma_read_from_client(...); >> } else { >> /* xuio has been setup by the provider */ >> zerocopy = 1; >> xdrrdma_zcopy_read_from_client(..., xuio); >> } >> do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); >> ... >> if (zerocopy) { >> VOP_RETZCBUF(vp, xuio, cr, &ct); >> } >> kmem_free(xuio, sizeof(xuio_t)); >> } >> >> >> References: >> [1] PSARC/2003/172 File Event Monitoring [2] PSARC/2007/227 VFS >> Features >> >> 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 roland.mainz@nrubsig.org Thu Sep 10 05:43:21 2009 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 n8AChKlR021391 for ; Thu, 10 Sep 2009 05:43:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8AChBX5029969; Thu, 10 Sep 2009 20:43:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPR00M1JA01VI00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 10 Sep 2009 05:43:13 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPR00I7TA00YT70@nwk-avmta-1.sfbay.Sun.COM>; Thu, 10 Sep 2009 05:43:13 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8ACaCTv004635; Thu, 10 Sep 2009 12:43:12 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-1376378; Thu, 10 Sep 2009 12:43:12 +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-1450047; Thu, 10 Sep 2009 12:43:12 +0000 (Z) Received: from mail-in-06.arcor-online.net ([151.189.21.46] [151.189.21.46]) by relay1i.sun.com with ESMTP id BT-MMP-2155539; Thu, 10 Sep 2009 12:43:11 +0000 (Z) Received: from mail-in-17-z2.arcor-online.net (mail-in-17-z2.arcor-online.net [151.189.8.34]) by mx.arcor.de (Postfix) with ESMTP id DB61339AA97; Thu, 10 Sep 2009 14:43:10 +0200 (CEST) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-17-z2.arcor-online.net (Postfix) with ESMTP id C3C9645C2D9; Thu, 10 Sep 2009 14:43:10 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-188-097-008-141.pools.arcor-ip.net [188.97.8.141]) by mail-in-03.arcor-online.net (Postfix) with ESMTPS id 9370E2C2E67; Thu, 10 Sep 2009 14:43:09 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n8ACh63p001884; Thu, 10 Sep 2009 14:43:07 +0200 (CEST) Date: Thu, 10 Sep 2009 14:43:06 +0200 From: Roland Mainz Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout09/16/2009] Sender: gisburn@jupiterb48.nrubsig.org To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, chunli.zhang@sun.com, siddheshwar.mahesh@sun.com Message-id: <4AA8F45A.E04B1613@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-03.arcor-online.net 9370E2C2E67 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Status: RO Content-Length: 3312 Rich.Brown@sun.com wrote: [snip] > == Introduction/Background == > > Zero-copy (copy avoidance) is essentially buffer sharing > among multiple modules that pass data between the modules. > This proposal avoids the data copy in the READ/WRITE path > of filesystems, by providing a mechanism to share data buffers > between the modules. It is intended to be used by network file > sharing services like NFS, CIFS or others. > > Although the buffer sharing can be achieved through a few different > solutions, any such solution must work with File Event Monitors > (FEM monitors)[1] installed on the files. The solution must > allow the underlying filesystem to maintain any existing file > range locking in the filesystem. > > The proposed solution provides extensions to the existing VOP > interface to request and return buffers from a filesystem. The > buffers are then used with existing VOP_READ/VOP_WRITE calls with > minimal changes. How do you handle "sparse files", e.g. files with one or more "holes" ? > == Proposed Changes == > > VOP Extensions for Zero-Copy Support > ======================================== > > a. Extended struct uio, xuio_t [snip] > The project team has commitment from the networking team to remove > the current use of uioa_t and use the proposed extensions (CR 6880095). > > The definition of xuio_t is: > > typedef struct xuio { > uio_t xu_uio; /* Embedded UIO structure */ > > /* Extended uio fields */ > enum xuio_type xu_type; /* What kind of uio structure? */ > > union { > > /* Async I/O Support */ > struct { > uint32_t xu_a_state; /* state of async i/o */ > uint32_t xu_a_state; /* state of async i/o */ > ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ > uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ > void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ > void *xu_a_hwst[4]; /* opaque hardware state */ > uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ > } xu_aio; > > /* Zero Copy Support */ > struct { > enum uio_rw xu_zc_rw; /* the use of the buffer */ > void *xu_zc_priv; /* fs specific */ Does it make sense to have a |xu_flags| field here for future enhancments ? > } xu_zc; > > } xu_ext; > } xuio_t; > > where xu_type is currently defined as: > > typedef enum xuio_type { > UIOTYPE_ASYNCIO, > UIOTYPE_ZEROCOPY > } xuio_type_t; > > New uio extensions can be added by defining a new xuio_type_t, and adding a > new member to the xu_ext union. > > b. Requesting zero-copy buffers > > #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ > fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) > > int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, > caller_context_t *); AFAIK the prototype should have a flags field to allow future changes/extenstions without adding another VOP_*-hook ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From Rich.Brown@sun.com Thu Sep 10 06:37:22 2009 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 n8ADbMQD022705 for ; Thu, 10 Sep 2009 06:37:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8ADbIxn024477 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 10 Sep 2009 06:37:22 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPR005LSCI9OH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 10 Sep 2009 06:37:21 -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 <0KPR003KSCHOM360@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 10 Sep 2009 06:37:00 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8ADb0lY015058 for ; Thu, 10 Sep 2009 13:37:00 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPR00E00BY1P000@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 10 Sep 2009 07:37:00 -0600 (MDT) Received: from [129.147.9.28] ([unknown] [129.147.9.28]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPR00MS2CHDIM10@mail-amer.sun.com>; Thu, 10 Sep 2009 07:36:49 -0600 (MDT) Date: Thu, 10 Sep 2009 08:36:49 -0500 From: Rich Brown Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <4AA8274F.9070803@sun.com> Sender: Rich.Brown@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, Chunli.Zhang@sun.com, Siddheshwar.Mahesh@sun.com Message-id: <4AA900F1.7070208@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <4AA8274F.9070803@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 2468 On 09/09/09 17:08, Garrett D'Amore wrote: > I've not had time to go over all this yet, but do we really believe this > kind of change is fast track appropriate? I have a feeling that this is > a significant enough core change with implications for a variety of > project teams, that maybe this one ought to be a full case. I'd be a > bit uncomfortable allowing this one to just time out with a single +1, > which is the normal rule for fast tracks. > > Am I alone in this particular concern? > > Are there any implications for unbundled 3rd party filesystems? > > - Garrett > Garrett, Perhaps this will help. As the sponsor, I asked myself the same question. This seemed similar in scope to another fast-track: PSARC/2007/315 (Extensible Attribute Interfaces). One could argue that this proposal is smaller in scope and impact since there are no user level interfaces involved. Here's what I considered during my review of the project (which might help make the proposal a bit more digestible): - The proposal extends the uio_t structure in a way that includes (and cleans up) the existing uioa_t (asynchronous uio) structure and adds a "zero copy" feature. With all due respect to the original implementors of uioa_t, this proposal seemed like a cleaner, more flexible solution to extending the functionality of the uio_t structure. This is roughly equivalent to the way that the vattr_t structure was extended with the xvattr_t structure in PSARC/2007/315. - This does not change the way that the existing VOP_READ/VOP_WRITE implementations work the same way that the addition of xvattr_t didn't change the way existing VOP_GETATTR/VOP_SETATTR implementations. Only those file systems that explicitly choose to participate in the extensions need to change their VOP_READ and VOP_WRITE implementations to handle the xuio_t structure. The current use of the uio_t structure will still work. - Also, only those file systems that explicitly choose to participate in the zero-copy feature need to implement VOP_REQZCBUF and VOP_RETZCBUF. For those file systems that do not implement these interfaces, they will automatically default to fs_nosys() without any effort by the file system implementor thanks to the vnode/vfs operation registration mechanism (introduced in PSARC/2001/679). Just to be clear, unbundled (Sun and 3rd party) file systems won't notice any difference. Rich From siddheshwar.mahesh@sun.com Thu Sep 10 09:50:54 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8AGormQ011360 for ; Thu, 10 Sep 2009 09:50:54 -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 n8AGojfo006914; Thu, 10 Sep 2009 17:50:50 +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 <0KPR00M1NLGQME00@nwk-avmta-2.sfbay.sun.com>; Thu, 10 Sep 2009 09:50:50 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPR00F8YLGPA790@nwk-avmta-2.sfbay.sun.com>; Thu, 10 Sep 2009 09:50:49 -0700 (PDT) Received: from siddheshwar-maheshs-computer-2.local (punchin-client-10-7-250-182.SFBay.Sun.COM [10.7.250.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8AGonv3257228; Thu, 10 Sep 2009 09:50:49 -0700 (PDT) Date: Thu, 10 Sep 2009 09:50:15 -0700 From: Mahesh Siddheshwar Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout09/16/2009] In-reply-to: <4AA8F45A.E04B1613@nrubsig.org> To: Roland Mainz Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, chunli.zhang@sun.com Message-id: <4AA92E47.7050204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <4AA8F45A.E04B1613@nrubsig.org> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 3285 Hi Roland, Roland Mainz wrote: [snip] > How do you handle "sparse files", e.g. files with one or more "holes" ? > > Sparse files are not handled any differently in VOP_READ/VOP_WRITE calls when using the zero-copy interface. Modules that want to seek/skip holes can use the _FIO_SEEK_DATA/_FIO_SEEK_HOLE commands of VOP_IOCTL, to do so. >> == Proposed Changes == >> >> VOP Extensions for Zero-Copy Support >> ======================================== >> >> a. Extended struct uio, xuio_t >> > [snip] > >> The project team has commitment from the networking team to remove >> the current use of uioa_t and use the proposed extensions (CR 6880095). >> >> The definition of xuio_t is: >> >> typedef struct xuio { >> uio_t xu_uio; /* Embedded UIO structure */ >> >> /* Extended uio fields */ >> enum xuio_type xu_type; /* What kind of uio structure? */ >> >> union { >> >> /* Async I/O Support */ >> struct { >> uint32_t xu_a_state; /* state of async i/o */ >> uint32_t xu_a_state; /* state of async i/o */ >> ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ >> uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ >> void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ >> void *xu_a_hwst[4]; /* opaque hardware state */ >> uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ >> } xu_aio; >> >> /* Zero Copy Support */ >> struct { >> enum uio_rw xu_zc_rw; /* the use of the buffer */ >> void *xu_zc_priv; /* fs specific */ >> > > Does it make sense to have a |xu_flags| field here for future > enhancments ? > If future enhancements are needed to extend xuio_t, a new xuio_type can be defined and extended that way. For extensions not specific to xuio, there also exists uio_extflg in the uio_t. Without a particular purpose an additional flag seems unnecessary for zero-copy right now. Please note that there is a typo in the spec, in the definition for struct xu_aio. The below line is printed twice: uint32_t xu_a_state; /* state of async i/o */ A corrected final spec will be posted in the case directory. >> } xu_zc; >> >> } xu_ext; >> } xuio_t; >> >> where xu_type is currently defined as: >> >> typedef enum xuio_type { >> UIOTYPE_ASYNCIO, >> UIOTYPE_ZEROCOPY >> } xuio_type_t; >> >> New uio extensions can be added by defining a new xuio_type_t, and adding a >> new member to the xu_ext union. >> >> b. Requesting zero-copy buffers >> >> #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ >> fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) >> >> int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, >> caller_context_t *); >> > > AFAIK the prototype should have a flags field to allow future > changes/extenstions without adding another VOP_*-hook ... > > Roland, if the extensions/changes are for the purpose of copy reduction/buffer sharing, we don't need to add additional VOP_* routines. The current xuio_t extension is defined just for that. Thanks, Mahesh > ---- > > Bye, > Roland > > From roland.mainz@nrubsig.org Thu Sep 10 10:25:47 2009 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 n8AHPkQ1012175 for ; Thu, 10 Sep 2009 10:25:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8AHPYSV008734; Fri, 11 Sep 2009 01:25:40 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPR00A05N2QRK00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 10 Sep 2009 10:25:38 -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 <0KPR002SBN2QLF60@nwk-avmta-1.sfbay.Sun.COM>; Thu, 10 Sep 2009 10:25:38 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8AHKK8c013802; Thu, 10 Sep 2009 17:25:37 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay41i.sun.com with ESMTP id BT-MMP-828280; Thu, 10 Sep 2009 17:25:37 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-3405919; Thu, 10 Sep 2009 17:25:37 +0000 (Z) Received: from mail-in-04.arcor-online.net ([151.189.21.44] [151.189.21.44]) by relay4i.sun.com with ESMTP id BT-MMP-19520067; Thu, 10 Sep 2009 17:25:37 +0000 (Z) Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mx.arcor.de (Postfix) with ESMTP id C25F633A7EE; Thu, 10 Sep 2009 19:25:35 +0200 (CEST) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id E4D5428EE29; Thu, 10 Sep 2009 19:25:35 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-188-097-008-141.pools.arcor-ip.net [188.97.8.141]) by mail-in-08.arcor-online.net (Postfix) with ESMTPS id B59D62AEE54; Thu, 10 Sep 2009 19:25:34 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n8AHPWJC001941; Thu, 10 Sep 2009 19:25:32 +0200 (CEST) Date: Thu, 10 Sep 2009 19:25:32 +0200 From: Roland Mainz Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout09/16/2009] Sender: gisburn@jupiterb48.nrubsig.org To: Mahesh Siddheshwar Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, chunli.zhang@sun.com Message-id: <4AA9368C.451D9667@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-08.arcor-online.net B59D62AEE54 X-Antispam: No, score=0.0/5.0, scanned in 0.128sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <4AA8F45A.E04B1613@nrubsig.org> <4AA92E47.7050204@sun.com> Status: RO Content-Length: 3935 Mahesh Siddheshwar wrote: > Roland Mainz wrote: > [snip] > > How do you handle "sparse files", e.g. files with one or more "holes" ? > > Sparse files are not handled any differently in VOP_READ/VOP_WRITE calls > when using the zero-copy interface. Modules that want to seek/skip holes > can use the _FIO_SEEK_DATA/_FIO_SEEK_HOLE commands > of VOP_IOCTL, to do so. Ok... [snip] > >> The definition of xuio_t is: > >> > >> typedef struct xuio { > >> uio_t xu_uio; /* Embedded UIO structure */ > >> > >> /* Extended uio fields */ > >> enum xuio_type xu_type; /* What kind of uio structure? */ > >> > >> union { > >> > >> /* Async I/O Support */ > >> struct { > >> uint32_t xu_a_state; /* state of async i/o */ > >> uint32_t xu_a_state; /* state of async i/o */ > >> ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ > >> uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ > >> void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ > >> void *xu_a_hwst[4]; /* opaque hardware state */ > >> uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ > >> } xu_aio; > >> > >> /* Zero Copy Support */ > >> struct { > >> enum uio_rw xu_zc_rw; /* the use of the buffer */ > >> void *xu_zc_priv; /* fs specific */ > >> > > > > Does it make sense to have a |xu_flags| field here for future > > enhancments ? > > > If future enhancements are needed to extend xuio_t, a new xuio_type > can be defined and extended that way. For extensions not specific > to xuio, there also exists uio_extflg in the uio_t. Without a particular > purpose an additional flag seems unnecessary for zero-copy right now. Right now... yes. But Unix has a little (IMO) ugly tradition of not adding such flag fields and instead swamping the headers with many many variations of one interface over time which could be avoided by use having a flags field as argument (that's a generic issue). > Please note that there is a typo in the spec, in the definition > for struct xu_aio. The below line is printed twice: > > uint32_t xu_a_state; /* state of async i/o */ > > A corrected final spec will be posted in the case directory. Ok... > >> } xu_zc; > >> > >> } xu_ext; > >> } xuio_t; > >> > >> where xu_type is currently defined as: > >> > >> typedef enum xuio_type { > >> UIOTYPE_ASYNCIO, > >> UIOTYPE_ZEROCOPY > >> } xuio_type_t; > >> > >> New uio extensions can be added by defining a new xuio_type_t, and adding a > >> new member to the xu_ext union. > >> > >> b. Requesting zero-copy buffers > >> > >> #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ > >> fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) > >> > >> int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, > >> caller_context_t *); > >> > > > > AFAIK the prototype should have a flags field to allow future > > changes/extenstions without adding another VOP_*-hook ... > > Roland, if the extensions/changes are for the purpose of > copy reduction/buffer sharing, we don't need to add > additional VOP_* routines. The current xuio_t extension is > defined just for that. Erm... the idea of having a flags field in |fop_reqzcbuf()| was to allow slight modifications in behaviour - for example in the future there could be flags which describe where (in a NUMA system) the buffer memory resides (e.g. near the calling thread, near a point which is optimal for all consumers, or near the hardware which fills the buffer etc.), whether it should be in the L2 cache or not etc. etc. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From Nicolas.Williams@sun.com Thu Sep 10 10:51:27 2009 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 n8AHpRXg012435 for ; Thu, 10 Sep 2009 10:51:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8AHpP6D017888; Thu, 10 Sep 2009 10:51:26 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPR0030BO9Q3600@nwk-avmta-2.sfbay.sun.com>; Thu, 10 Sep 2009 10:51:26 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPR00F3VO9PABF0@nwk-avmta-2.sfbay.sun.com>; Thu, 10 Sep 2009 10:51:25 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8AHeL8I014032; Thu, 10 Sep 2009 12:40:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8AHeLdw014031; Thu, 10 Sep 2009 12:40:21 -0500 (CDT) Date: Thu, 10 Sep 2009 12:40:21 -0500 From: Nicolas Williams Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout09/16/2009] In-reply-to: <4AA9368C.451D9667@nrubsig.org> To: Roland Mainz Cc: Mahesh Siddheshwar , Rich.Brown@sun.com, PSARC-ext@sun.com, Chunli.Zhang@sun.com Message-id: <20090910174021.GQ1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <4AA8F45A.E04B1613@nrubsig.org> <4AA92E47.7050204@sun.com> <4AA9368C.451D9667@nrubsig.org> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1243 On Thu, Sep 10, 2009 at 07:25:32PM +0200, Roland Mainz wrote: > Mahesh Siddheshwar wrote: > > If future enhancements are needed to extend xuio_t, a new xuio_type > > can be defined and extended that way. For extensions not specific > > to xuio, there also exists uio_extflg in the uio_t. Without a particular > > purpose an additional flag seems unnecessary for zero-copy right now. > > Right now... yes. But Unix has a little (IMO) ugly tradition of not > adding such flag fields and instead swamping the headers with many many > variations of one interface over time which could be avoided by use > having a flags field as argument (that's a generic issue). Not just Unix. Any sufficiently old, and large piece of software tends to have such bloat (how many Windows APIs ending in "Ex" or "Ex2" are there?). It's a price we pay for backwards compatibility. A flags field is not enough -- you'd have to define the criticality of unknown flags, and what error code to return when unknown, critical flags are seen. Get it wrong and you end up paying for an unused flag field forever. Get it right and you still end up with the bloat of multiple interface definitions down the road. So what does a flags field buy you here? Nico -- From siddheshwar.mahesh@sun.com Fri Sep 11 11:31:56 2009 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 n8BIVuSH017026 for ; Fri, 11 Sep 2009 11:31:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8BIVtp6008559; Fri, 11 Sep 2009 11:31:55 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPT0021ZKT76H00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 11 Sep 2009 11:31:55 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPT008D7KT7AWC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 11 Sep 2009 11:31:55 -0700 (PDT) Received: from dhcp-umpk17-229-151.sfbay.sun.com (dhcp-umpk17-229-151.SFBay.Sun.COM [129.146.229.151]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8BIVt2n488066; Fri, 11 Sep 2009 11:31:55 -0700 (PDT) Date: Fri, 11 Sep 2009 11:31:20 -0700 From: Mahesh Siddheshwar Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout09/16/2009] In-reply-to: <4AA9368C.451D9667@nrubsig.org> To: Roland Mainz Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, chunli.zhang@sun.com Message-id: <4AAA9778.3020004@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <4AA8F45A.E04B1613@nrubsig.org> <4AA92E47.7050204@sun.com> <4AA9368C.451D9667@nrubsig.org> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 2778 Roland Mainz wrote: > Mahesh Siddheshwar wrote: > >> Roland Mainz wrote: >> >>> Does it make sense to have a |xu_flags| field here for future >>> enhancments ? >>> >> If future enhancements are needed to extend xuio_t, a new xuio_type >> can be defined and extended that way. For extensions not specific >> to xuio, there also exists uio_extflg in the uio_t. Without a particular >> purpose an additional flag seems unnecessary for zero-copy right now. >> > > Right now... yes. But Unix has a little (IMO) ugly tradition of not > adding such flag fields and instead swamping the headers with many many > variations of one interface over time which could be avoided by use > having a flags field as argument (that's a generic issue). > [snip] >>>> b. Requesting zero-copy buffers >>>> >>>> #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ >>>> fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) >>>> >>>> int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, >>>> caller_context_t *) >>> AFAIK the prototype should have a flags field to allow future >>> changes/extenstions without adding another VOP_*-hook ... >>> >> Roland, if the extensions/changes are for the purpose of >> copy reduction/buffer sharing, we don't need to add >> additional VOP_* routines. The current xuio_t extension is >> defined just for that. >> > > Erm... the idea of having a flags field in |fop_reqzcbuf()| was to allow > slight modifications in behaviour - for example in the future there > could be flags which describe where (in a NUMA system) the buffer memory > resides (e.g. near the calling thread, near a point which is optimal for > all consumers, or near the hardware which fills the buffer etc.), > whether it should be in the L2 cache or not etc. etc. > Roland, I agree with Nico on the drawbacks of adding undefined flags for future use. You make two suggestions: 1) addition of a flag to xuio_t for future use 2) addition of a flag to VOP_REQZCBUF() for future use. It's the project team's opinion that these flags are not needed for this spec, for the following reasons: For 1) the existence of uio_extflg in uio_t and the possibility of extending xuio_t through additional xuio_type's, make an additional 'xu_flags' flag an overhead that can be avoided. For 2) we don't have a specific purpose for the flag right now. If there is a need for additional flags or arguments in future, the VOP routine can be easily extended. As has been done in the recent past with several extensions for existing VOP routines (PSARC 2007/244, 2007/218, 2007/227, 2009/387). The existence of strong type checking for vnode/vfs operations through PSARC 2007/124 make it easier to catch an interface mismatch. Thanks, Mahesh From johansen@sun.com Fri Sep 11 13:43:47 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8BKhkId024857 for ; Fri, 11 Sep 2009 13:43:47 -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 n8BKhdqA016854; Fri, 11 Sep 2009 21:43:42 +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 <0KPT00K1RQWT9H00@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Sep 2009 13:43:41 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPT00866QWSWHE0@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Sep 2009 13:43:40 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8BKheGv523440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Sep 2009 13:43:40 -0700 (PDT) Received: (from johansen@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n8BKheGF523430; Fri, 11 Sep 2009 13:43:40 -0700 (PDT) Date: Fri, 11 Sep 2009 13:43:40 -0700 From: johansen@sun.com Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, chunli.zhang@sun.com, siddheshwar.mahesh@sun.com Message-id: <20090911204340.GA491594@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: johansen set sender to johansen@sun.com using -f User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 2757 On Wed, Sep 09, 2009 at 04:02:15PM -0500, Rich.Brown@sun.com wrote: > == Introduction/Background == > > Zero-copy (copy avoidance) is essentially buffer sharing > among multiple modules that pass data between the modules. > This proposal avoids the data copy in the READ/WRITE path > of filesystems, by providing a mechanism to share data buffers > between the modules. It is intended to be used by network file > sharing services like NFS, CIFS or others. > > Although the buffer sharing can be achieved through a few different > solutions, any such solution must work with File Event Monitors > (FEM monitors)[1] installed on the files. The solution must > allow the underlying filesystem to maintain any existing file > range locking in the filesystem. > > The proposed solution provides extensions to the existing VOP > interface to request and return buffers from a filesystem. The > buffers are then used with existing VOP_READ/VOP_WRITE calls with > minimal changes. > > > == Proposed Changes == <...> > == Using the New VOP Interfaces for Zero-copy == > > VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with > VOP_READ() or VOP_WRITE() to implement zero-copy read or write. > > a. Read > > In a normal read, the consumer allocates the data buffer and passes it to > VOP_READ(). The provider initiates the I/O, and copies the data from its > own cache buffer to the consumer supplied buffer. > > To avoid the copy (initiating a zero-copy read), the consumer > first calls VOP_REQZCBUF() to inform the provider to prepare to > loan out its cache buffer. It then calls VOP_READ(). After the > call returns, the consumer has direct access to the cache buffer > loaned out by the provider. After processing the data, the > consumer calls VOP_RETZCBUF() to return the loaned cache buffer to > the provider. <...> > b. Write > > In a normal write, the consumer allocates the data buffer, loads the data, > and passes the buffer to VOP_WRITE(). The provider copies the data from > the consumer supplied buffer to its own cache buffer, and starts the I/O. > > To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to > grab a cache buffer from the provider. It loads the data directly to > the loaned cache buffer, and calls VOP_WRITE(). After the call returns, > the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to > the provider. Just for clarification: this interface only affects pages mapped in the kernel, correct? I'm trying to understand if this is just for reducing the number of in-kernel copies, or if this is a userland <-> kernel zero-copy interface. Thanks, -j From siddheshwar.mahesh@sun.com Fri Sep 11 14:35:53 2009 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 n8BLZqXN005208 for ; Fri, 11 Sep 2009 14:35:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8BLZkAK024529; Sat, 12 Sep 2009 05:35:47 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPT00305TBJED00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 11 Sep 2009 14:35:43 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPT006TRTBJOS80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 11 Sep 2009 14:35:43 -0700 (PDT) Received: from dhcp-umpk17-229-151.sfbay.sun.com (dhcp-umpk17-229-151.SFBay.Sun.COM [129.146.229.151]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8BLZgM1532484; Fri, 11 Sep 2009 14:35:42 -0700 (PDT) Date: Fri, 11 Sep 2009 14:35:08 -0700 From: Mahesh Siddheshwar Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <20090911204340.GA491594@eng.sun.com> To: johansen@sun.com Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, chunli.zhang@sun.com Message-id: <4AAAC28C.6090000@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <20090911204340.GA491594@eng.sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 3150 johansen@sun.com wrote: > On Wed, Sep 09, 2009 at 04:02:15PM -0500, Rich.Brown@sun.com wrote: > >> == Introduction/Background == >> >> Zero-copy (copy avoidance) is essentially buffer sharing >> among multiple modules that pass data between the modules. >> This proposal avoids the data copy in the READ/WRITE path >> of filesystems, by providing a mechanism to share data buffers >> between the modules. It is intended to be used by network file >> sharing services like NFS, CIFS or others. >> >> Although the buffer sharing can be achieved through a few different >> solutions, any such solution must work with File Event Monitors >> (FEM monitors)[1] installed on the files. The solution must >> allow the underlying filesystem to maintain any existing file >> range locking in the filesystem. >> >> The proposed solution provides extensions to the existing VOP >> interface to request and return buffers from a filesystem. The >> buffers are then used with existing VOP_READ/VOP_WRITE calls with >> minimal changes. >> >> >> == Proposed Changes == >> > <...> > > >> == Using the New VOP Interfaces for Zero-copy == >> >> VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with >> VOP_READ() or VOP_WRITE() to implement zero-copy read or write. >> >> a. Read >> >> In a normal read, the consumer allocates the data buffer and passes it to >> VOP_READ(). The provider initiates the I/O, and copies the data from its >> own cache buffer to the consumer supplied buffer. >> >> To avoid the copy (initiating a zero-copy read), the consumer >> first calls VOP_REQZCBUF() to inform the provider to prepare to >> loan out its cache buffer. It then calls VOP_READ(). After the >> call returns, the consumer has direct access to the cache buffer >> loaned out by the provider. After processing the data, the >> consumer calls VOP_RETZCBUF() to return the loaned cache buffer to >> the provider. >> > <...> > > >> b. Write >> >> In a normal write, the consumer allocates the data buffer, loads the data, >> and passes the buffer to VOP_WRITE(). The provider copies the data from >> the consumer supplied buffer to its own cache buffer, and starts the I/O. >> >> To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to >> grab a cache buffer from the provider. It loads the data directly to >> the loaned cache buffer, and calls VOP_WRITE(). After the call returns, >> the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to >> the provider. >> > > Just for clarification: this interface only affects pages mapped in the > kernel, correct? I'm trying to understand if this is just for reducing > the number of in-kernel copies, or if this is a userland <-> kernel > zero-copy interface. > > That is correct. This interface is to prevent in-kernel copies and allow buffer sharing between kernel modules (that can be used by in-kernel services like NFS or CIFS). The spec does not define any userland <-> kernel zero-copy interface. Thanks, Mahesh > Thanks, > > -j > From Roch.Bourbonnais@sun.com Wed Sep 16 06:50:25 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8GDoOVQ012999 for ; Wed, 16 Sep 2009 06:50:24 -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 n8GDoLQ6006587 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Sep 2009 14:50:23 +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 <0KQ200903H3YMY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 06:50:22 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ200JUPH3XRPB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 06:50:22 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8GDoKbE015795 for ; Wed, 16 Sep 2009 13:50:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ200A00GBKLE00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 14:50:04 +0100 (BST) Received: from bode ([unknown] [129.157.192.177]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ2009I3H3DE520@fe-emea-09.sun.com>; Wed, 16 Sep 2009 14:50:01 +0100 (BST) Date: Wed, 16 Sep 2009 06:50:04 -0700 From: Roch Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Sender: Roch.Bourbonnais@sun.com To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Chunli.Zhang@sun.com, Siddheshwar.Mahesh@sun.com, Blaise.Sanouillet@sun.com Message-id: <19120.60684.154168.483311@gargle.gargle.HOWL> Organization: SUN Microsystems MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Phone: (+33).4.76.18.83.20 (x[70]38320) Status: RO Content-Length: 14923 Filesystems might have some blocksize and alignment constraints conditioning their ability to loan up buffers (for writes). If that is so, we could use an API to query the FS about those values. For a copy on write & variable block size filesystem, that natural blocksize might also depend on the vnode being targetted. Do we know if ZFS will ever be able to loan up buffers for writes that are not aligned full records ? -r Rich.Brown@Sun.COM writes: > I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang. > This case proposes new interfaces to support copy reduction in the I/O path > especially for file sharing services. > > Minor binding is requested. > > This times out on Wednesday, 16 September, 2009. > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Copy Reduction Interfaces > 1.2. Name of Document Author/Supplier: > Author: Mahesh Siddheshwar, Chunli Zhang > 1.3 Date of This Document: > 09 September, 2009 > 4. Technical Description > > == Introduction/Background == > > Zero-copy (copy avoidance) is essentially buffer sharing > among multiple modules that pass data between the modules. > This proposal avoids the data copy in the READ/WRITE path > of filesystems, by providing a mechanism to share data buffers > between the modules. It is intended to be used by network file > sharing services like NFS, CIFS or others. > > Although the buffer sharing can be achieved through a few different > solutions, any such solution must work with File Event Monitors > (FEM monitors)[1] installed on the files. The solution must > allow the underlying filesystem to maintain any existing file > range locking in the filesystem. > > The proposed solution provides extensions to the existing VOP > interface to request and return buffers from a filesystem. The > buffers are then used with existing VOP_READ/VOP_WRITE calls with > minimal changes. > > > == Proposed Changes == > > VOP Extensions for Zero-Copy Support > ======================================== > > a. Extended struct uio, xuio_t > > The following proposes an extensible uio structure that can be extended for > multiple purposes. For example, an immediate extension, xu_zc, is to be > used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned > zero-copy buffers, as well as to be passed to the existing VOP_READ/VOP_WRITE > calls for normal read/write operations. Another example of extension, > xu_aio, is intended to replace uioa_t for async I/O. > > This new structure, xuio_t, contains the following: > > - the existing uio structure (embedded) as the first member > - additional fields to support extensibility > - a union of all the defined extensions > > The following uio_extflag is added to indicate that an uio structure is > indeed an xuio_t: > > #define UIO_XUIO 0x004 /* Structure is xuio_t */ > > The following uio_extflag will be removed after uioa_t has been converted > to xuio_t: > > #define UIO_ASYNC 0x002 /* Structure is xuio_t */ > > The project team has commitment from the networking team to remove > the current use of uioa_t and use the proposed extensions (CR 6880095). > > The definition of xuio_t is: > > typedef struct xuio { > uio_t xu_uio; /* Embedded UIO structure */ > > /* Extended uio fields */ > enum xuio_type xu_type; /* What kind of uio structure? */ > > union { > > /* Async I/O Support */ > struct { > uint32_t xu_a_state; /* state of async i/o */ > uint32_t xu_a_state; /* state of async i/o */ > ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ > uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ > void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ > void *xu_a_hwst[4]; /* opaque hardware state */ > uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ > } xu_aio; > > /* Zero Copy Support */ > struct { > enum uio_rw xu_zc_rw; /* the use of the buffer */ > void *xu_zc_priv; /* fs specific */ > } xu_zc; > > } xu_ext; > } xuio_t; > > where xu_type is currently defined as: > > typedef enum xuio_type { > UIOTYPE_ASYNCIO, > UIOTYPE_ZEROCOPY > } xuio_type_t; > > New uio extensions can be added by defining a new xuio_type_t, and adding a > new member to the xu_ext union. > > b. Requesting zero-copy buffers > > #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ > fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) > > int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, > caller_context_t *); > > This function requests buffers associated with file vp in preparation for a > subsequent zero copy read or write. The extended uio_t -- xuio_t is used > to pass the parameters and results. Only the following fields of xuio_t are > relevant to this call. > > uiozcp->xu_uio.uio_resid: used by the caller to specify the total length > of the buffer. > > uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the file offset > it would like the buffers to be associated with. A value of -1 > indicates that the provider returns buffers that are not associated > with a particular offset. These are defined to be anonymous buffers. > Anonymous buffers may be used for requesting a write buffer to receive > data over the wire, where file offset might not be handily available. > > uiozcp->xu_uio.uio_iov: used by the provider to return an array of buffers > (in case multiple filesystem buffers have to be reserved for the > requested length). > > uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the number of > returned buffers (length of array uiop->uio_iov). > > Other arguments to the call include: > > vp: vnode pointer of the associated file. > > rwflag: Indicates what the buffers are to be subsequently used for. > Expected values are UIO_READ for VOP_READ() and UIO_WRITE for > VOP_WRITE(). > > Upon successful completion, the function returns 0. One or more > buffers may be returned as referenced by uio_iov[] and uio_iovcnt members. > uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio is set > to UIOTYPE_ZEROCOPY. > > The caller can use this returned xuio_t in a subsequent call to VOP_READ > or VOP_WRITE. In the case of UIO_READ buffers, the caller should > reference the uio_iov[] buffers only after a successful VOP_READ(). > In the case of UIO_WRITE buffers, the caller should not reference > the uio_iov[] buffers after a successful VOP_WRITE. > > In the case of anonymous buffers, the caller should set the value of > uio_loffset before such a read/write call. This should be done only in > the case of anonymous buffers. > > The member xu_zc_priv of the extended uio structure for zero-copy is > a private handle that may be used by the provider to track its buffer > headers or any other private information that is useful to map the > loaned iovec entries to its internal buffers. The xu_zc_priv member > is private to the provider and should not be changed or interpreted > in anyway by the callers. > > Upon failure, the function returns EINVAL error and the content > of uiozcp should be ignored by the callers. The provider must fail the > request if it is unable to satisfy the complete request (ie. it must > not return buffers that cover only a part of the length that was > asked for). > > Probable causes for failure include: > > - the filesystem is short on buffers to loan out at the time > - the filesystem determines that it's not efficient to take the > zero-copy path based on the input parameters > > c. Returning zero-copy buffers > > #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ > fop_retzcbuf(vp, uiozcp, cr, ct) > > int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); > > This function returns the buffers previously obtained via a call > to VOP_REQZCBUF(). In case multiple buffers are associated with the > uio_iov[], all the buffers associated with the uiozcp are returned. > In other words, VOP_RETZCBUF() should only be called once per xuio_t. > The caller should not reference any of the uio_iov[] members after > a return. > > d. New VFS feature attributes > > A new VFS feature attribute is introduced for the support of > zero-copy interface. > > #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 > > Zero-copy is an optional feature. A filesystem supporting the > zero-copy interface (ie. the Interface Provider) must set this > VFS feature attribute through the VFS Feature Registration > interface[2]. Callers of the interface (ie. Interface Consumer) > must check the presence of support through vfs_has_feature() interface. > The intermediate fop routines (called via the VOP_* macros) will detect > if the interfaces are being called for a filesystem that does not support > zero-copy and will return ENOTSUP. > > INTERFACE TABLE > +==========================================================================================+ > |Proposed |Specified | > |Stability |in what | > Interface Name |Classification |Document? | Comments > +==========================================================================================+ > VOP_REQZCBUF() |Consolidation |This | New VOP calls > fop_reqzcbuf() |Private |Document | > VOP_RETZCBUF() | | | > fop_retzcbuf() | | | > | | | > VFSFT_ZEROCOPY_SUPPORTED | | | New VFS feature definition > | | | > xuio_t | | | Extended uio_t definition > | | | > | | | > uioa_t | | | Deprecated > UIO_ASYNC | | | Deprecated > +==========================================================================================+ > > * The project's deliverables will all go into the OS/NET > Consolidation, so no contracts are required. > > > == Using the New VOP Interfaces for Zero-copy == > > VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with > VOP_READ() or VOP_WRITE() to implement zero-copy read or write. > > a. Read > > In a normal read, the consumer allocates the data buffer and passes it to > VOP_READ(). The provider initiates the I/O, and copies the data from its > own cache buffer to the consumer supplied buffer. > > To avoid the copy (initiating a zero-copy read), the consumer first calls > VOP_REQZCBUF() to inform the provider to prepare to loan out its cache > buffer. It then calls VOP_READ(). After the call returns, the consumer > has direct access to the cache buffer loaned out by the provider. After > processing the data, the consumer calls VOP_RETZCBUF() to return the loaned > cache buffer to the provider. > > Here is an illustration using NFSv4 read over TCP: > > rfs4_op_read(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > } > do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > setup callback mechanism that makes the network layer call > VOP_RETZCBUF() and free xuio after the data is sent out; > } else { > kmem_free(xuio, sizeof(xuio_t)); > } > } > > b. Write > > In a normal write, the consumer allocates the data buffer, loads the data, > and passes the buffer to VOP_WRITE(). The provider copies the data from > the consumer supplied buffer to its own cache buffer, and starts the I/O. > > To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to > grab a cache buffer from the provider. It loads the data directly to > the loaned cache buffer, and calls VOP_WRITE(). After the call returns, > the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to > the provider. > > Here is an illustration using NFSv4 write via RDMA: > > rfs4_op_write(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > xdrrdma_read_from_client(...); > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > xdrrdma_zcopy_read_from_client(..., xuio); > } > do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > VOP_RETZCBUF(vp, xuio, cr, &ct); > } > kmem_free(xuio, sizeof(xuio_t)); > } > > > References: > [1] PSARC/2003/172 File Event Monitoring > [2] PSARC/2007/227 VFS Features > > > 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 siddheshwar.mahesh@sun.com Wed Sep 16 08:58:18 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8GFwIXk027272 for ; Wed, 16 Sep 2009 08:58:18 -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 n8GFv5IE063588; Wed, 16 Sep 2009 09:58: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 <0KQ200407N0UII00@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Sep 2009 08:58:06 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ2001RLN0UZ240@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Sep 2009 08:58:06 -0700 (PDT) Received: from siddheshwar-maheshs-computer-2.local (punchin-client-10-7-250-182.SFBay.Sun.COM [10.7.250.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8GFw5dl207792; Wed, 16 Sep 2009 08:58:06 -0700 (PDT) Date: Wed, 16 Sep 2009 08:57:28 -0700 From: Mahesh Siddheshwar Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <19120.60684.154168.483311@gargle.gargle.HOWL> To: Roch Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, Chunli.Zhang@sun.com, Blaise.Sanouillet@sun.com Message-id: <4AB10AE8.5040808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <19120.60684.154168.483311@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 16566 Roch wrote: > Filesystems might have some blocksize and alignment constraints > conditioning their ability to loan up buffers (for writes). > If that is so, we could use an API to query the FS about > those values. For a copy on write & variable block size > filesystem, that natural blocksize might also depend on the > vnode being targetted. Yes. The provider can fail the VOP_REQZCBUF() call if it determines that it is inefficient to take the zero-copy path. Depending on the provider implementation, this could be blocksize aligned. In such cases, the consumer could use VFSNAME_STATVFS() call to determine 'f_bsize' value. But as you note, certain implementations may have different values for individual files. In such cases if the VOP_REQZCBUF() fails, the consumer then uses the traditional non zero-copy path. An additional API to find the such constraints/requirements may be useful in future, but is out-of-scope for this project. However, the project team will open an RFE for this issue and put you on the interest list. > Do we know if ZFS will ever be able to > loan up buffers for writes that are not aligned full records ? > No, not planned currently. It has to be block size aligned. Also note that currently, from an implementation perspective, zero-copy WRITEs are efficient only in case network-based filesystems like NFS over RDMA transports. Mahesh > -r > > Rich.Brown@Sun.COM writes: > > I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang. > > This case proposes new interfaces to support copy reduction in the I/O path > > especially for file sharing services. > > > > Minor binding is requested. > > > > This times out on Wednesday, 16 September, 2009. > > > > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > > This information is Copyright 2009 Sun Microsystems > > 1. Introduction > > 1.1. Project/Component Working Name: > > Copy Reduction Interfaces > > 1.2. Name of Document Author/Supplier: > > Author: Mahesh Siddheshwar, Chunli Zhang > > 1.3 Date of This Document: > > 09 September, 2009 > > 4. Technical Description > > > > == Introduction/Background == > > > > Zero-copy (copy avoidance) is essentially buffer sharing > > among multiple modules that pass data between the modules. > > This proposal avoids the data copy in the READ/WRITE path > > of filesystems, by providing a mechanism to share data buffers > > between the modules. It is intended to be used by network file > > sharing services like NFS, CIFS or others. > > > > Although the buffer sharing can be achieved through a few different > > solutions, any such solution must work with File Event Monitors > > (FEM monitors)[1] installed on the files. The solution must > > allow the underlying filesystem to maintain any existing file > > range locking in the filesystem. > > > > The proposed solution provides extensions to the existing VOP > > interface to request and return buffers from a filesystem. The > > buffers are then used with existing VOP_READ/VOP_WRITE calls with > > minimal changes. > > > > > > == Proposed Changes == > > > > VOP Extensions for Zero-Copy Support > > ======================================== > > > > a. Extended struct uio, xuio_t > > > > The following proposes an extensible uio structure that can be extended for > > multiple purposes. For example, an immediate extension, xu_zc, is to be > > used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned > > zero-copy buffers, as well as to be passed to the existing VOP_READ/VOP_WRITE > > calls for normal read/write operations. Another example of extension, > > xu_aio, is intended to replace uioa_t for async I/O. > > > > This new structure, xuio_t, contains the following: > > > > - the existing uio structure (embedded) as the first member > > - additional fields to support extensibility > > - a union of all the defined extensions > > > > The following uio_extflag is added to indicate that an uio structure is > > indeed an xuio_t: > > > > #define UIO_XUIO 0x004 /* Structure is xuio_t */ > > > > The following uio_extflag will be removed after uioa_t has been converted > > to xuio_t: > > > > #define UIO_ASYNC 0x002 /* Structure is xuio_t */ > > > > The project team has commitment from the networking team to remove > > the current use of uioa_t and use the proposed extensions (CR 6880095). > > > > The definition of xuio_t is: > > > > typedef struct xuio { > > uio_t xu_uio; /* Embedded UIO structure */ > > > > /* Extended uio fields */ > > enum xuio_type xu_type; /* What kind of uio structure? */ > > > > union { > > > > /* Async I/O Support */ > > struct { > > uint32_t xu_a_state; /* state of async i/o */ > > uint32_t xu_a_state; /* state of async i/o */ > > ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ > > uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ > > void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ > > void *xu_a_hwst[4]; /* opaque hardware state */ > > uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ > > } xu_aio; > > > > /* Zero Copy Support */ > > struct { > > enum uio_rw xu_zc_rw; /* the use of the buffer */ > > void *xu_zc_priv; /* fs specific */ > > } xu_zc; > > > > } xu_ext; > > } xuio_t; > > > > where xu_type is currently defined as: > > > > typedef enum xuio_type { > > UIOTYPE_ASYNCIO, > > UIOTYPE_ZEROCOPY > > } xuio_type_t; > > > > New uio extensions can be added by defining a new xuio_type_t, and adding a > > new member to the xu_ext union. > > > > b. Requesting zero-copy buffers > > > > #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ > > fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) > > > > int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, > > caller_context_t *); > > > > This function requests buffers associated with file vp in preparation for a > > subsequent zero copy read or write. The extended uio_t -- xuio_t is used > > to pass the parameters and results. Only the following fields of xuio_t are > > relevant to this call. > > > > uiozcp->xu_uio.uio_resid: used by the caller to specify the total length > > of the buffer. > > > > uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the file offset > > it would like the buffers to be associated with. A value of -1 > > indicates that the provider returns buffers that are not associated > > with a particular offset. These are defined to be anonymous buffers. > > Anonymous buffers may be used for requesting a write buffer to receive > > data over the wire, where file offset might not be handily available. > > > > uiozcp->xu_uio.uio_iov: used by the provider to return an array of buffers > > (in case multiple filesystem buffers have to be reserved for the > > requested length). > > > > uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the number of > > returned buffers (length of array uiop->uio_iov). > > > > Other arguments to the call include: > > > > vp: vnode pointer of the associated file. > > > > rwflag: Indicates what the buffers are to be subsequently used for. > > Expected values are UIO_READ for VOP_READ() and UIO_WRITE for > > VOP_WRITE(). > > > > Upon successful completion, the function returns 0. One or more > > buffers may be returned as referenced by uio_iov[] and uio_iovcnt members. > > uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio is set > > to UIOTYPE_ZEROCOPY. > > > > The caller can use this returned xuio_t in a subsequent call to VOP_READ > > or VOP_WRITE. In the case of UIO_READ buffers, the caller should > > reference the uio_iov[] buffers only after a successful VOP_READ(). > > In the case of UIO_WRITE buffers, the caller should not reference > > the uio_iov[] buffers after a successful VOP_WRITE. > > > > In the case of anonymous buffers, the caller should set the value of > > uio_loffset before such a read/write call. This should be done only in > > the case of anonymous buffers. > > > > The member xu_zc_priv of the extended uio structure for zero-copy is > > a private handle that may be used by the provider to track its buffer > > headers or any other private information that is useful to map the > > loaned iovec entries to its internal buffers. The xu_zc_priv member > > is private to the provider and should not be changed or interpreted > > in anyway by the callers. > > > > Upon failure, the function returns EINVAL error and the content > > of uiozcp should be ignored by the callers. The provider must fail the > > request if it is unable to satisfy the complete request (ie. it must > > not return buffers that cover only a part of the length that was > > asked for). > > > > Probable causes for failure include: > > > > - the filesystem is short on buffers to loan out at the time > > - the filesystem determines that it's not efficient to take the > > zero-copy path based on the input parameters > > > > c. Returning zero-copy buffers > > > > #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ > > fop_retzcbuf(vp, uiozcp, cr, ct) > > > > int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); > > > > This function returns the buffers previously obtained via a call > > to VOP_REQZCBUF(). In case multiple buffers are associated with the > > uio_iov[], all the buffers associated with the uiozcp are returned. > > In other words, VOP_RETZCBUF() should only be called once per xuio_t. > > The caller should not reference any of the uio_iov[] members after > > a return. > > > > d. New VFS feature attributes > > > > A new VFS feature attribute is introduced for the support of > > zero-copy interface. > > > > #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 > > > > Zero-copy is an optional feature. A filesystem supporting the > > zero-copy interface (ie. the Interface Provider) must set this > > VFS feature attribute through the VFS Feature Registration > > interface[2]. Callers of the interface (ie. Interface Consumer) > > must check the presence of support through vfs_has_feature() interface. > > The intermediate fop routines (called via the VOP_* macros) will detect > > if the interfaces are being called for a filesystem that does not support > > zero-copy and will return ENOTSUP. > > > > INTERFACE TABLE > > +==========================================================================================+ > > |Proposed |Specified | > > |Stability |in what | > > Interface Name |Classification |Document? | Comments > > +==========================================================================================+ > > VOP_REQZCBUF() |Consolidation |This | New VOP calls > > fop_reqzcbuf() |Private |Document | > > VOP_RETZCBUF() | | | > > fop_retzcbuf() | | | > > | | | > > VFSFT_ZEROCOPY_SUPPORTED | | | New VFS feature definition > > | | | > > xuio_t | | | Extended uio_t definition > > | | | > > | | | > > uioa_t | | | Deprecated > > UIO_ASYNC | | | Deprecated > > +==========================================================================================+ > > > > * The project's deliverables will all go into the OS/NET > > Consolidation, so no contracts are required. > > > > > > == Using the New VOP Interfaces for Zero-copy == > > > > VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with > > VOP_READ() or VOP_WRITE() to implement zero-copy read or write. > > > > a. Read > > > > In a normal read, the consumer allocates the data buffer and passes it to > > VOP_READ(). The provider initiates the I/O, and copies the data from its > > own cache buffer to the consumer supplied buffer. > > > > To avoid the copy (initiating a zero-copy read), the consumer first calls > > VOP_REQZCBUF() to inform the provider to prepare to loan out its cache > > buffer. It then calls VOP_READ(). After the call returns, the consumer > > has direct access to the cache buffer loaned out by the provider. After > > processing the data, the consumer calls VOP_RETZCBUF() to return the loaned > > cache buffer to the provider. > > > > Here is an illustration using NFSv4 read over TCP: > > > > rfs4_op_read(nfs_argop4 *argop, ...) > > { > > int zerocopy; > > xuio_t *xuio; > > ... > > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > > setup length, offset, etc; > > if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { > > zerocopy = 0; > > allocate the data buffer the normal way; > > initialize (uio_t *)xuio; > > } else { > > /* xuio has been setup by the provider */ > > zerocopy = 1; > > } > > do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); > > ... > > if (zerocopy) { > > setup callback mechanism that makes the network layer call > > VOP_RETZCBUF() and free xuio after the data is sent out; > > } else { > > kmem_free(xuio, sizeof(xuio_t)); > > } > > } > > > > b. Write > > > > In a normal write, the consumer allocates the data buffer, loads the data, > > and passes the buffer to VOP_WRITE(). The provider copies the data from > > the consumer supplied buffer to its own cache buffer, and starts the I/O. > > > > To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to > > grab a cache buffer from the provider. It loads the data directly to > > the loaned cache buffer, and calls VOP_WRITE(). After the call returns, > > the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to > > the provider. > > > > Here is an illustration using NFSv4 write via RDMA: > > > > rfs4_op_write(nfs_argop4 *argop, ...) > > { > > int zerocopy; > > xuio_t *xuio; > > ... > > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > > setup length, offset, etc; > > if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { > > zerocopy = 0; > > allocate the data buffer the normal way; > > initialize (uio_t *)xuio; > > xdrrdma_read_from_client(...); > > } else { > > /* xuio has been setup by the provider */ > > zerocopy = 1; > > xdrrdma_zcopy_read_from_client(..., xuio); > > } > > do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); > > ... > > if (zerocopy) { > > VOP_RETZCBUF(vp, xuio, cr, &ct); > > } > > kmem_free(xuio, sizeof(xuio_t)); > > } > > > > > > References: > > [1] PSARC/2003/172 File Event Monitoring > > [2] PSARC/2007/227 VFS Features > > > > > > 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 Richard.Matthews@sun.com Wed Sep 16 09:51:46 2009 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 n8GGpjYB003598 for ; Wed, 16 Sep 2009 09:51:45 -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 n8GGpd31019556 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Sep 2009 00:51:44 +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 <0KQ20082LPI74900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 16 Sep 2009 09:51:43 -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 <0KQ2001ZKPI6YVA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 16 Sep 2009 09:51:42 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8GGpg3G020552 for ; Wed, 16 Sep 2009 16:51:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ200L00OFJGG00@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 16 Sep 2009 10:51:42 -0600 (MDT) Received: from [129.152.9.14] ([unknown] [129.152.9.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ200419PHY7080@mail-amer.sun.com>; Wed, 16 Sep 2009 10:51:35 -0600 (MDT) Date: Wed, 16 Sep 2009 11:51:34 -0500 From: Rick Matthews Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Sender: Richard.Matthews@sun.com To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Chunli.Zhang@sun.com, Siddheshwar.Mahesh@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <4AB11796.6070908@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 14837 Are there instances where an assigned zero-copy buffer could be orphaned? If so, should there be a recovery list associated with this addition? Perhaps off the designated vnode. This comment shouldn't block fast-track approval. Just a question. -- Rick On 09/ 9/09 04:02 PM, Rich.Brown@Sun.COM wrote: > I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang. > This case proposes new interfaces to support copy reduction in the I/O path > especially for file sharing services. > > Minor binding is requested. > > This times out on Wednesday, 16 September, 2009. > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Copy Reduction Interfaces > 1.2. Name of Document Author/Supplier: > Author: Mahesh Siddheshwar, Chunli Zhang > 1.3 Date of This Document: > 09 September, 2009 > 4. Technical Description > > == Introduction/Background == > > Zero-copy (copy avoidance) is essentially buffer sharing > among multiple modules that pass data between the modules. > This proposal avoids the data copy in the READ/WRITE path > of filesystems, by providing a mechanism to share data buffers > between the modules. It is intended to be used by network file > sharing services like NFS, CIFS or others. > > Although the buffer sharing can be achieved through a few different > solutions, any such solution must work with File Event Monitors > (FEM monitors)[1] installed on the files. The solution must > allow the underlying filesystem to maintain any existing file > range locking in the filesystem. > > The proposed solution provides extensions to the existing VOP > interface to request and return buffers from a filesystem. The > buffers are then used with existing VOP_READ/VOP_WRITE calls with > minimal changes. > > > == Proposed Changes == > > VOP Extensions for Zero-Copy Support > ======================================== > > a. Extended struct uio, xuio_t > > The following proposes an extensible uio structure that can be extended for > multiple purposes. For example, an immediate extension, xu_zc, is to be > used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned > zero-copy buffers, as well as to be passed to the existing VOP_READ/VOP_WRITE > calls for normal read/write operations. Another example of extension, > xu_aio, is intended to replace uioa_t for async I/O. > > This new structure, xuio_t, contains the following: > > - the existing uio structure (embedded) as the first member > - additional fields to support extensibility > - a union of all the defined extensions > > The following uio_extflag is added to indicate that an uio structure is > indeed an xuio_t: > > #define UIO_XUIO 0x004 /* Structure is xuio_t */ > > The following uio_extflag will be removed after uioa_t has been converted > to xuio_t: > > #define UIO_ASYNC 0x002 /* Structure is xuio_t */ > > The project team has commitment from the networking team to remove > the current use of uioa_t and use the proposed extensions (CR 6880095). > > The definition of xuio_t is: > > typedef struct xuio { > uio_t xu_uio; /* Embedded UIO structure */ > > /* Extended uio fields */ > enum xuio_type xu_type; /* What kind of uio structure? */ > > union { > > /* Async I/O Support */ > struct { > uint32_t xu_a_state; /* state of async i/o */ > uint32_t xu_a_state; /* state of async i/o */ > ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ > uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ > void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ > void *xu_a_hwst[4]; /* opaque hardware state */ > uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ > } xu_aio; > > /* Zero Copy Support */ > struct { > enum uio_rw xu_zc_rw; /* the use of the buffer */ > void *xu_zc_priv; /* fs specific */ > } xu_zc; > > } xu_ext; > } xuio_t; > > where xu_type is currently defined as: > > typedef enum xuio_type { > UIOTYPE_ASYNCIO, > UIOTYPE_ZEROCOPY > } xuio_type_t; > > New uio extensions can be added by defining a new xuio_type_t, and adding a > new member to the xu_ext union. > > b. Requesting zero-copy buffers > > #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ > fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) > > int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, > caller_context_t *); > > This function requests buffers associated with file vp in preparation for a > subsequent zero copy read or write. The extended uio_t -- xuio_t is used > to pass the parameters and results. Only the following fields of xuio_t are > relevant to this call. > > uiozcp->xu_uio.uio_resid: used by the caller to specify the total length > of the buffer. > > uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the file offset > it would like the buffers to be associated with. A value of -1 > indicates that the provider returns buffers that are not associated > with a particular offset. These are defined to be anonymous buffers. > Anonymous buffers may be used for requesting a write buffer to receive > data over the wire, where file offset might not be handily available. > > uiozcp->xu_uio.uio_iov: used by the provider to return an array of buffers > (in case multiple filesystem buffers have to be reserved for the > requested length). > > uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the number of > returned buffers (length of array uiop->uio_iov). > > Other arguments to the call include: > > vp: vnode pointer of the associated file. > > rwflag: Indicates what the buffers are to be subsequently used for. > Expected values are UIO_READ for VOP_READ() and UIO_WRITE for > VOP_WRITE(). > > Upon successful completion, the function returns 0. One or more > buffers may be returned as referenced by uio_iov[] and uio_iovcnt members. > uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio is set > to UIOTYPE_ZEROCOPY. > > The caller can use this returned xuio_t in a subsequent call to VOP_READ > or VOP_WRITE. In the case of UIO_READ buffers, the caller should > reference the uio_iov[] buffers only after a successful VOP_READ(). > In the case of UIO_WRITE buffers, the caller should not reference > the uio_iov[] buffers after a successful VOP_WRITE. > > In the case of anonymous buffers, the caller should set the value of > uio_loffset before such a read/write call. This should be done only in > the case of anonymous buffers. > > The member xu_zc_priv of the extended uio structure for zero-copy is > a private handle that may be used by the provider to track its buffer > headers or any other private information that is useful to map the > loaned iovec entries to its internal buffers. The xu_zc_priv member > is private to the provider and should not be changed or interpreted > in anyway by the callers. > > Upon failure, the function returns EINVAL error and the content > of uiozcp should be ignored by the callers. The provider must fail the > request if it is unable to satisfy the complete request (ie. it must > not return buffers that cover only a part of the length that was > asked for). > > Probable causes for failure include: > > - the filesystem is short on buffers to loan out at the time > - the filesystem determines that it's not efficient to take the > zero-copy path based on the input parameters > > c. Returning zero-copy buffers > > #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ > fop_retzcbuf(vp, uiozcp, cr, ct) > > int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); > > This function returns the buffers previously obtained via a call > to VOP_REQZCBUF(). In case multiple buffers are associated with the > uio_iov[], all the buffers associated with the uiozcp are returned. > In other words, VOP_RETZCBUF() should only be called once per xuio_t. > The caller should not reference any of the uio_iov[] members after > a return. > > d. New VFS feature attributes > > A new VFS feature attribute is introduced for the support of > zero-copy interface. > > #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 > > Zero-copy is an optional feature. A filesystem supporting the > zero-copy interface (ie. the Interface Provider) must set this > VFS feature attribute through the VFS Feature Registration > interface[2]. Callers of the interface (ie. Interface Consumer) > must check the presence of support through vfs_has_feature() interface. > The intermediate fop routines (called via the VOP_* macros) will detect > if the interfaces are being called for a filesystem that does not support > zero-copy and will return ENOTSUP. > > INTERFACE TABLE > +==========================================================================================+ > |Proposed |Specified | > |Stability |in what | > Interface Name |Classification |Document? | Comments > +==========================================================================================+ > VOP_REQZCBUF() |Consolidation |This | New VOP calls > fop_reqzcbuf() |Private |Document | > VOP_RETZCBUF() | | | > fop_retzcbuf() | | | > | | | > VFSFT_ZEROCOPY_SUPPORTED | | | New VFS feature definition > | | | > xuio_t | | | Extended uio_t definition > | | | > | | | > uioa_t | | | Deprecated > UIO_ASYNC | | | Deprecated > +==========================================================================================+ > > * The project's deliverables will all go into the OS/NET > Consolidation, so no contracts are required. > > > == Using the New VOP Interfaces for Zero-copy == > > VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with > VOP_READ() or VOP_WRITE() to implement zero-copy read or write. > > a. Read > > In a normal read, the consumer allocates the data buffer and passes it to > VOP_READ(). The provider initiates the I/O, and copies the data from its > own cache buffer to the consumer supplied buffer. > > To avoid the copy (initiating a zero-copy read), the consumer first calls > VOP_REQZCBUF() to inform the provider to prepare to loan out its cache > buffer. It then calls VOP_READ(). After the call returns, the consumer > has direct access to the cache buffer loaned out by the provider. After > processing the data, the consumer calls VOP_RETZCBUF() to return the loaned > cache buffer to the provider. > > Here is an illustration using NFSv4 read over TCP: > > rfs4_op_read(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > } > do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > setup callback mechanism that makes the network layer call > VOP_RETZCBUF() and free xuio after the data is sent out; > } else { > kmem_free(xuio, sizeof(xuio_t)); > } > } > > b. Write > > In a normal write, the consumer allocates the data buffer, loads the data, > and passes the buffer to VOP_WRITE(). The provider copies the data from > the consumer supplied buffer to its own cache buffer, and starts the I/O. > > To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to > grab a cache buffer from the provider. It loads the data directly to > the loaned cache buffer, and calls VOP_WRITE(). After the call returns, > the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to > the provider. > > Here is an illustration using NFSv4 write via RDMA: > > rfs4_op_write(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > xdrrdma_read_from_client(...); > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > xdrrdma_zcopy_read_from_client(..., xuio); > } > do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > VOP_RETZCBUF(vp, xuio, cr, &ct); > } > kmem_free(xuio, sizeof(xuio_t)); > } > > > References: > [1] PSARC/2003/172 File Event Monitoring > [2] PSARC/2007/227 VFS Features > > > 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 > > -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From Siddheshwar.Mahesh@sun.com Wed Sep 16 09:55:43 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8GGtha7004182 for ; Wed, 16 Sep 2009 09:55:43 -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 n8GGtgcq043899; Wed, 16 Sep 2009 10:55:42 -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 <0KQ20080TPOTD700@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Sep 2009 09:55:41 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ2001BUPOSYVB0@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Sep 2009 09:55:40 -0700 (PDT) Received: from dhcp-usca15-191-158.sfbay.sun.com (dhcp-usca15-191-158.SFBay.Sun.COM [129.145.191.158]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8GGte2g221090; Wed, 16 Sep 2009 09:55:40 -0700 (PDT) Date: Wed, 16 Sep 2009 09:55:02 -0700 From: Mahesh Siddheshwar Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <4AB11796.6070908@Sun.COM> To: Richard.Matthews@sun.com Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, Chunli.Zhang@sun.com Message-id: <4AB11866.50900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> <4AB11796.6070908@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 15124 Rick Matthews wrote: > Are there instances where an assigned zero-copy buffer could be orphaned? No. The consumer Must release the buffers through VOP_RETZCBUF(). Mahesh > If so, should there be a recovery list associated with this addition? > Perhaps off > the designated vnode. > > This comment shouldn't block fast-track approval. Just a question. > -- > Rick > > On 09/ 9/09 04:02 PM, Rich.Brown@Sun.COM wrote: >> I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli >> Zhang. >> This case proposes new interfaces to support copy reduction in the >> I/O path >> especially for file sharing services. >> >> Minor binding is requested. >> >> This times out on Wednesday, 16 September, 2009. >> >> >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Copy Reduction Interfaces >> 1.2. Name of Document Author/Supplier: >> Author: Mahesh Siddheshwar, Chunli Zhang >> 1.3 Date of This Document: >> 09 September, 2009 >> 4. Technical Description >> >> == Introduction/Background == >> >> Zero-copy (copy avoidance) is essentially buffer sharing >> among multiple modules that pass data between the modules. This >> proposal avoids the data copy in the READ/WRITE path of filesystems, >> by providing a mechanism to share data buffers >> between the modules. It is intended to be used by network file >> sharing services like NFS, CIFS or others. >> >> Although the buffer sharing can be achieved through a few different >> solutions, any such solution must work with File Event Monitors >> (FEM monitors)[1] installed on the files. The solution must >> allow the underlying filesystem to maintain any existing file range >> locking in the filesystem. >> >> The proposed solution provides extensions to the existing VOP >> interface to request and return buffers from a filesystem. The >> buffers are then used with existing VOP_READ/VOP_WRITE calls with >> minimal changes. >> >> >> == Proposed Changes == >> >> VOP Extensions for Zero-Copy Support >> ======================================== >> >> a. Extended struct uio, xuio_t >> >> The following proposes an extensible uio structure that can be >> extended for >> multiple purposes. For example, an immediate extension, xu_zc, is >> to be used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to >> pass loaned >> zero-copy buffers, as well as to be passed to the existing >> VOP_READ/VOP_WRITE >> calls for normal read/write operations. Another example of extension, >> xu_aio, is intended to replace uioa_t for async I/O. >> >> This new structure, xuio_t, contains the following: >> >> - the existing uio structure (embedded) as the first member >> - additional fields to support extensibility >> - a union of all the defined extensions >> >> The following uio_extflag is added to indicate that an uio >> structure is >> indeed an xuio_t: >> >> #define UIO_XUIO 0x004 /* Structure is xuio_t */ >> >> The following uio_extflag will be removed after uioa_t has been >> converted to xuio_t: >> >> #define UIO_ASYNC 0x002 /* Structure is xuio_t */ >> >> The project team has commitment from the networking team to remove >> the current use of uioa_t and use the proposed extensions (CR >> 6880095). >> >> The definition of xuio_t is: >> >> typedef struct xuio { >> uio_t xu_uio; /* Embedded UIO structure */ >> >> /* Extended uio fields */ >> enum xuio_type xu_type; /* What kind of uio structure? */ >> >> union { >> >> /* Async I/O Support */ >> struct { >> uint32_t xu_a_state; /* state of async i/o */ >> uint32_t xu_a_state; /* state of async i/o */ >> ssize_t xu_a_mbytes; /* bytes that have been >> uioamove()ed */ >> uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ >> void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ >> void *xu_a_hwst[4]; /* opaque hardware state */ >> uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov >> locked pages */ >> } xu_aio; >> >> /* Zero Copy Support */ >> struct { >> enum uio_rw xu_zc_rw; /* the use of the buffer */ >> void *xu_zc_priv; /* fs specific */ >> } xu_zc; >> >> } xu_ext; >> } xuio_t; >> >> where xu_type is currently defined as: >> >> typedef enum xuio_type { >> UIOTYPE_ASYNCIO, >> UIOTYPE_ZEROCOPY >> } xuio_type_t; >> >> New uio extensions can be added by defining a new xuio_type_t, and >> adding a >> new member to the xu_ext union. >> >> b. Requesting zero-copy buffers >> >> #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ >> fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) >> >> int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, >> caller_context_t *); >> >> This function requests buffers associated with file vp in >> preparation for a >> subsequent zero copy read or write. The extended uio_t -- xuio_t >> is used >> to pass the parameters and results. Only the following fields of >> xuio_t are >> relevant to this call. >> >> uiozcp->xu_uio.uio_resid: used by the caller to specify the total >> length >> of the buffer. >> >> uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the >> file offset >> it would like the buffers to be associated with. A value of >> -1 indicates that the provider returns buffers that are not >> associated >> with a particular offset. These are defined to be anonymous >> buffers. >> Anonymous buffers may be used for requesting a write buffer >> to receive >> data over the wire, where file offset might not be handily >> available. >> >> uiozcp->xu_uio.uio_iov: used by the provider to return an array >> of buffers >> (in case multiple filesystem buffers have to be reserved for >> the >> requested length). >> >> uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the >> number of >> returned buffers (length of array uiop->uio_iov). >> >> Other arguments to the call include: >> >> vp: vnode pointer of the associated file. >> >> rwflag: Indicates what the buffers are to be subsequently used for. >> Expected values are UIO_READ for VOP_READ() and UIO_WRITE >> for >> VOP_WRITE(). >> >> Upon successful completion, the function returns 0. One or more >> buffers may be returned as referenced by uio_iov[] and uio_iovcnt >> members. >> uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio >> is set >> to UIOTYPE_ZEROCOPY. >> >> The caller can use this returned xuio_t in a subsequent call to >> VOP_READ >> or VOP_WRITE. In the case of UIO_READ buffers, the caller should >> reference the uio_iov[] buffers only after a successful VOP_READ(). >> In the case of UIO_WRITE buffers, the caller should not reference >> the uio_iov[] buffers after a successful VOP_WRITE. >> >> In the case of anonymous buffers, the caller should set the value >> of uio_loffset before such a read/write call. This should be done >> only in the case of anonymous buffers. >> The member xu_zc_priv of the extended uio structure for zero-copy >> is a private handle that may be used by the provider to track its >> buffer >> headers or any other private information that is useful to map >> the loaned iovec entries to its internal buffers. The xu_zc_priv >> member >> is private to the provider and should not be changed or >> interpreted in anyway by the callers. >> >> Upon failure, the function returns EINVAL error and the content >> of uiozcp should be ignored by the callers. The provider must >> fail the >> request if it is unable to satisfy the complete request (ie. it must >> not return buffers that cover only a part of the length that was >> asked for). >> >> Probable causes for failure include: >> >> - the filesystem is short on buffers to loan out at the time >> - the filesystem determines that it's not efficient to take the >> zero-copy path based on the input parameters >> c. Returning zero-copy buffers >> >> #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ >> fop_retzcbuf(vp, uiozcp, cr, ct) >> >> int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); >> >> This function returns the buffers previously obtained via a call >> to VOP_REQZCBUF(). In case multiple buffers are associated with the >> uio_iov[], all the buffers associated with the uiozcp are returned. >> In other words, VOP_RETZCBUF() should only be called once per >> xuio_t. >> The caller should not reference any of the uio_iov[] members after >> a return. >> >> d. New VFS feature attributes >> >> A new VFS feature attribute is introduced for the support of >> zero-copy interface. >> >> #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 >> >> Zero-copy is an optional feature. A filesystem supporting the >> zero-copy interface (ie. the Interface Provider) must set this >> VFS feature attribute through the VFS Feature Registration >> interface[2]. Callers of the interface (ie. Interface Consumer) >> must check the presence of support through vfs_has_feature() >> interface. >> The intermediate fop routines (called via the VOP_* macros) will >> detect >> if the interfaces are being called for a filesystem that does not >> support >> zero-copy and will return ENOTSUP. >> >> INTERFACE TABLE >> +==========================================================================================+ >> >> |Proposed |Specified | >> |Stability |in what | >> Interface Name |Classification |Document? | Comments >> +==========================================================================================+ >> >> VOP_REQZCBUF() |Consolidation |This | New VOP calls >> fop_reqzcbuf() |Private |Document | >> VOP_RETZCBUF() | | | >> fop_retzcbuf() | | | >> | | | >> VFSFT_ZEROCOPY_SUPPORTED | | | New VFS >> feature definition >> | | | >> xuio_t | | | Extended >> uio_t definition >> | | | >> | | | >> uioa_t | | | Deprecated >> UIO_ASYNC | | | Deprecated >> +==========================================================================================+ >> >> >> * The project's deliverables will all go into the OS/NET >> Consolidation, so no contracts are required. >> >> >> == Using the New VOP Interfaces for Zero-copy == >> >> VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction >> with >> VOP_READ() or VOP_WRITE() to implement zero-copy read or write. >> a. Read >> >> In a normal read, the consumer allocates the data buffer and >> passes it to >> VOP_READ(). The provider initiates the I/O, and copies the data >> from its >> own cache buffer to the consumer supplied buffer. >> >> To avoid the copy (initiating a zero-copy read), the consumer >> first calls >> VOP_REQZCBUF() to inform the provider to prepare to loan out its >> cache >> buffer. It then calls VOP_READ(). After the call returns, the >> consumer >> has direct access to the cache buffer loaned out by the >> provider. After >> processing the data, the consumer calls VOP_RETZCBUF() to return >> the loaned >> cache buffer to the provider. >> >> Here is an illustration using NFSv4 read over TCP: >> >> rfs4_op_read(nfs_argop4 *argop, ...) >> { >> int zerocopy; >> xuio_t *xuio; >> ... >> xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); >> setup length, offset, etc; >> if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { >> zerocopy = 0; >> allocate the data buffer the normal way; >> initialize (uio_t *)xuio; >> } else { >> /* xuio has been setup by the provider */ >> zerocopy = 1; >> } >> do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); >> ... >> if (zerocopy) { >> setup callback mechanism that makes the network layer >> call >> VOP_RETZCBUF() and free xuio after the data is sent out; >> } else { >> kmem_free(xuio, sizeof(xuio_t)); >> } >> } >> >> b. Write >> >> In a normal write, the consumer allocates the data buffer, loads >> the data, >> and passes the buffer to VOP_WRITE(). The provider copies the >> data from >> the consumer supplied buffer to its own cache buffer, and starts >> the I/O. >> >> To initiate a zero-copy write, the consumer first calls >> VOP_REQZCBUF() to >> grab a cache buffer from the provider. It loads the data >> directly to >> the loaned cache buffer, and calls VOP_WRITE(). After the call >> returns, >> the consumer calls VOP_RETZCBUF() to return the loaned cache >> buffer to >> the provider. >> >> Here is an illustration using NFSv4 write via RDMA: >> >> rfs4_op_write(nfs_argop4 *argop, ...) >> { >> int zerocopy; >> xuio_t *xuio; >> ... >> xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); >> setup length, offset, etc; >> if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { >> zerocopy = 0; >> allocate the data buffer the normal way; >> initialize (uio_t *)xuio; >> xdrrdma_read_from_client(...); >> } else { >> /* xuio has been setup by the provider */ >> zerocopy = 1; >> xdrrdma_zcopy_read_from_client(..., xuio); >> } >> do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); >> ... >> if (zerocopy) { >> VOP_RETZCBUF(vp, xuio, cr, &ct); >> } >> kmem_free(xuio, sizeof(xuio_t)); >> } >> >> >> References: >> [1] PSARC/2003/172 File Event Monitoring [2] PSARC/2007/227 VFS >> Features >> >> 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 Roch.Bourbonnais@sun.com Wed Sep 16 10:20:02 2009 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 n8GHK2ES007623 for ; Wed, 16 Sep 2009 10:20:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8GHK0hS022113 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Sep 2009 10:20:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ20091XQTDTB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 10:20:01 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ2001DLQTAYRA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 10:19:58 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8GHJv1L001478 for ; Wed, 16 Sep 2009 17:19:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ200G00QNSVV00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 18:19:55 +0100 (BST) Received: from bode ([unknown] [129.157.192.177]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ2001BFQT6E980@fe-emea-10.sun.com>; Wed, 16 Sep 2009 18:19:55 +0100 (BST) Date: Wed, 16 Sep 2009 10:19:56 -0700 From: Roch Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Sender: Roch.Bourbonnais@sun.com To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Chunli.Zhang@sun.com, Siddheshwar.Mahesh@sun.com Message-id: <19121.7740.208744.689795@gargle.gargle.HOWL> Organization: SUN Microsystems MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Phone: (+33).4.76.18.83.20 (x[70]38320) Status: RO Content-Length: 14546 My issues have been resolved. Thanks Mahesh. -r Rich.Brown@Sun.COM writes: > I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang. > This case proposes new interfaces to support copy reduction in the I/O path > especially for file sharing services. > > Minor binding is requested. > > This times out on Wednesday, 16 September, 2009. > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Copy Reduction Interfaces > 1.2. Name of Document Author/Supplier: > Author: Mahesh Siddheshwar, Chunli Zhang > 1.3 Date of This Document: > 09 September, 2009 > 4. Technical Description > > == Introduction/Background == > > Zero-copy (copy avoidance) is essentially buffer sharing > among multiple modules that pass data between the modules. > This proposal avoids the data copy in the READ/WRITE path > of filesystems, by providing a mechanism to share data buffers > between the modules. It is intended to be used by network file > sharing services like NFS, CIFS or others. > > Although the buffer sharing can be achieved through a few different > solutions, any such solution must work with File Event Monitors > (FEM monitors)[1] installed on the files. The solution must > allow the underlying filesystem to maintain any existing file > range locking in the filesystem. > > The proposed solution provides extensions to the existing VOP > interface to request and return buffers from a filesystem. The > buffers are then used with existing VOP_READ/VOP_WRITE calls with > minimal changes. > > > == Proposed Changes == > > VOP Extensions for Zero-Copy Support > ======================================== > > a. Extended struct uio, xuio_t > > The following proposes an extensible uio structure that can be extended for > multiple purposes. For example, an immediate extension, xu_zc, is to be > used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned > zero-copy buffers, as well as to be passed to the existing VOP_READ/VOP_WRITE > calls for normal read/write operations. Another example of extension, > xu_aio, is intended to replace uioa_t for async I/O. > > This new structure, xuio_t, contains the following: > > - the existing uio structure (embedded) as the first member > - additional fields to support extensibility > - a union of all the defined extensions > > The following uio_extflag is added to indicate that an uio structure is > indeed an xuio_t: > > #define UIO_XUIO 0x004 /* Structure is xuio_t */ > > The following uio_extflag will be removed after uioa_t has been converted > to xuio_t: > > #define UIO_ASYNC 0x002 /* Structure is xuio_t */ > > The project team has commitment from the networking team to remove > the current use of uioa_t and use the proposed extensions (CR 6880095). > > The definition of xuio_t is: > > typedef struct xuio { > uio_t xu_uio; /* Embedded UIO structure */ > > /* Extended uio fields */ > enum xuio_type xu_type; /* What kind of uio structure? */ > > union { > > /* Async I/O Support */ > struct { > uint32_t xu_a_state; /* state of async i/o */ > uint32_t xu_a_state; /* state of async i/o */ > ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */ > uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */ > void **xu_a_lppp; /* pointer into lcur->uioa_ppp[] */ > void *xu_a_hwst[4]; /* opaque hardware state */ > uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */ > } xu_aio; > > /* Zero Copy Support */ > struct { > enum uio_rw xu_zc_rw; /* the use of the buffer */ > void *xu_zc_priv; /* fs specific */ > } xu_zc; > > } xu_ext; > } xuio_t; > > where xu_type is currently defined as: > > typedef enum xuio_type { > UIOTYPE_ASYNCIO, > UIOTYPE_ZEROCOPY > } xuio_type_t; > > New uio extensions can be added by defining a new xuio_type_t, and adding a > new member to the xu_ext union. > > b. Requesting zero-copy buffers > > #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \ > fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct) > > int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *, > caller_context_t *); > > This function requests buffers associated with file vp in preparation for a > subsequent zero copy read or write. The extended uio_t -- xuio_t is used > to pass the parameters and results. Only the following fields of xuio_t are > relevant to this call. > > uiozcp->xu_uio.uio_resid: used by the caller to specify the total length > of the buffer. > > uiozcp->xu_uio.uio_loffset: Used by the caller to indicate the file offset > it would like the buffers to be associated with. A value of -1 > indicates that the provider returns buffers that are not associated > with a particular offset. These are defined to be anonymous buffers. > Anonymous buffers may be used for requesting a write buffer to receive > data over the wire, where file offset might not be handily available. > > uiozcp->xu_uio.uio_iov: used by the provider to return an array of buffers > (in case multiple filesystem buffers have to be reserved for the > requested length). > > uiozcp->xu_uio.uio_iovcnt: used by the provider to indicate the number of > returned buffers (length of array uiop->uio_iov). > > Other arguments to the call include: > > vp: vnode pointer of the associated file. > > rwflag: Indicates what the buffers are to be subsequently used for. > Expected values are UIO_READ for VOP_READ() and UIO_WRITE for > VOP_WRITE(). > > Upon successful completion, the function returns 0. One or more > buffers may be returned as referenced by uio_iov[] and uio_iovcnt members. > uiozcp->xu_uio.uio_extflag is set to UIO_XUIO, and uiozcp->xu_uio is set > to UIOTYPE_ZEROCOPY. > > The caller can use this returned xuio_t in a subsequent call to VOP_READ > or VOP_WRITE. In the case of UIO_READ buffers, the caller should > reference the uio_iov[] buffers only after a successful VOP_READ(). > In the case of UIO_WRITE buffers, the caller should not reference > the uio_iov[] buffers after a successful VOP_WRITE. > > In the case of anonymous buffers, the caller should set the value of > uio_loffset before such a read/write call. This should be done only in > the case of anonymous buffers. > > The member xu_zc_priv of the extended uio structure for zero-copy is > a private handle that may be used by the provider to track its buffer > headers or any other private information that is useful to map the > loaned iovec entries to its internal buffers. The xu_zc_priv member > is private to the provider and should not be changed or interpreted > in anyway by the callers. > > Upon failure, the function returns EINVAL error and the content > of uiozcp should be ignored by the callers. The provider must fail the > request if it is unable to satisfy the complete request (ie. it must > not return buffers that cover only a part of the length that was > asked for). > > Probable causes for failure include: > > - the filesystem is short on buffers to loan out at the time > - the filesystem determines that it's not efficient to take the > zero-copy path based on the input parameters > > c. Returning zero-copy buffers > > #define VOP_RETZCBUF(vp, uiozcp, cr, ct) \ > fop_retzcbuf(vp, uiozcp, cr, ct) > > int fop_retzcbuf(vnode_t *, xuio_t *, cred_t *, caller_context_t *); > > This function returns the buffers previously obtained via a call > to VOP_REQZCBUF(). In case multiple buffers are associated with the > uio_iov[], all the buffers associated with the uiozcp are returned. > In other words, VOP_RETZCBUF() should only be called once per xuio_t. > The caller should not reference any of the uio_iov[] members after > a return. > > d. New VFS feature attributes > > A new VFS feature attribute is introduced for the support of > zero-copy interface. > > #define VFSFT_ZEROCOPY_SUPPORTED 0x100000100 > > Zero-copy is an optional feature. A filesystem supporting the > zero-copy interface (ie. the Interface Provider) must set this > VFS feature attribute through the VFS Feature Registration > interface[2]. Callers of the interface (ie. Interface Consumer) > must check the presence of support through vfs_has_feature() interface. > The intermediate fop routines (called via the VOP_* macros) will detect > if the interfaces are being called for a filesystem that does not support > zero-copy and will return ENOTSUP. > > INTERFACE TABLE > +==========================================================================================+ > |Proposed |Specified | > |Stability |in what | > Interface Name |Classification |Document? | Comments > +==========================================================================================+ > VOP_REQZCBUF() |Consolidation |This | New VOP calls > fop_reqzcbuf() |Private |Document | > VOP_RETZCBUF() | | | > fop_retzcbuf() | | | > | | | > VFSFT_ZEROCOPY_SUPPORTED | | | New VFS feature definition > | | | > xuio_t | | | Extended uio_t definition > | | | > | | | > uioa_t | | | Deprecated > UIO_ASYNC | | | Deprecated > +==========================================================================================+ > > * The project's deliverables will all go into the OS/NET > Consolidation, so no contracts are required. > > > == Using the New VOP Interfaces for Zero-copy == > > VOP_REQZCBUF()/VOP_RETZCBUF() are expected to be used in conjunction with > VOP_READ() or VOP_WRITE() to implement zero-copy read or write. > > a. Read > > In a normal read, the consumer allocates the data buffer and passes it to > VOP_READ(). The provider initiates the I/O, and copies the data from its > own cache buffer to the consumer supplied buffer. > > To avoid the copy (initiating a zero-copy read), the consumer first calls > VOP_REQZCBUF() to inform the provider to prepare to loan out its cache > buffer. It then calls VOP_READ(). After the call returns, the consumer > has direct access to the cache buffer loaned out by the provider. After > processing the data, the consumer calls VOP_RETZCBUF() to return the loaned > cache buffer to the provider. > > Here is an illustration using NFSv4 read over TCP: > > rfs4_op_read(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_READ, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > } > do_io(FREAD, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > setup callback mechanism that makes the network layer call > VOP_RETZCBUF() and free xuio after the data is sent out; > } else { > kmem_free(xuio, sizeof(xuio_t)); > } > } > > b. Write > > In a normal write, the consumer allocates the data buffer, loads the data, > and passes the buffer to VOP_WRITE(). The provider copies the data from > the consumer supplied buffer to its own cache buffer, and starts the I/O. > > To initiate a zero-copy write, the consumer first calls VOP_REQZCBUF() to > grab a cache buffer from the provider. It loads the data directly to > the loaned cache buffer, and calls VOP_WRITE(). After the call returns, > the consumer calls VOP_RETZCBUF() to return the loaned cache buffer to > the provider. > > Here is an illustration using NFSv4 write via RDMA: > > rfs4_op_write(nfs_argop4 *argop, ...) > { > int zerocopy; > xuio_t *xuio; > ... > xuio = kmem_alloc(sizeof(xuio_t), KM_SLEEP); > setup length, offset, etc; > if (VOP_REQZCBUF(vp, UIO_WRITE, xuio, cr, ct)) { > zerocopy = 0; > allocate the data buffer the normal way; > initialize (uio_t *)xuio; > xdrrdma_read_from_client(...); > } else { > /* xuio has been setup by the provider */ > zerocopy = 1; > xdrrdma_zcopy_read_from_client(..., xuio); > } > do_io(FWRITE, vp, (uio_t *)xuio, 0, cr, &ct); > ... > if (zerocopy) { > VOP_RETZCBUF(vp, xuio, cr, &ct); > } > kmem_free(xuio, sizeof(xuio_t)); > } > > > References: > [1] PSARC/2003/172 File Event Monitoring > [2] PSARC/2007/227 VFS Features > > > 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 Rich.Brown@sun.com Wed Sep 16 11:45:51 2009 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 n8GIjohu011437 for ; Wed, 16 Sep 2009 11:45:51 -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 n8GIjmDh022348 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Sep 2009 02:45:49 +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 <0KQ200E0BUSDW100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 16 Sep 2009 11:45:49 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ200BVDUSCPH30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 16 Sep 2009 11:45:48 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8GIjmDi012277 for ; Wed, 16 Sep 2009 18:45:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ200500UFRHN00@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 16 Sep 2009 12:45:47 -0600 (MDT) Received: from [129.147.9.28] ([unknown] [129.147.9.28]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ200E5MUSAE800@mail-amer.sun.com>; Wed, 16 Sep 2009 12:45:46 -0600 (MDT) Date: Wed, 16 Sep 2009 13:45:46 -0500 From: Rich Brown Subject: Re: Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009] In-reply-to: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> Sender: Rich.Brown@sun.com To: PSARC-ext@sun.com Cc: Chunli.Zhang@sun.com, Siddheshwar.Mahesh@sun.com, Rich.Brown@sun.com Message-id: <4AB1325A.3000802@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909092102.n89L2FFU013552@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 231 This case was approved at today's PSARC meeting. I put an updated "final_spec.txt" in the case directory which corrects a typo that Mahesh found. On behalf of the team, thank you for your time and assistance on this case. Rich