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