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
>
>
