Rich.Brown at 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 at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
