From: Douglas Gilbert <dougg@torque.net>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: linux-scsi@vger.kernel.org, jens.axboe@oracle.com
Subject: Re: convert sg to block layer helpers - v5
Date: Sun, 04 Mar 2007 15:17:30 -0500 [thread overview]
Message-ID: <45EB295A.30601@torque.net> (raw)
In-Reply-To: <45EB2484.6030700@cs.wisc.edu>
Mike Christie wrote:
> Douglas Gilbert wrote:
>> Mike,
>> I see you are removing the scatter_elem_sz parameter.
>> What decides the scatter gather element size? Can it
>> be greater than PAGE_SIZE?
>
> Oh yeah, sorry I should have documented that.
>
> I just made the code try to allocate as large a element as possible.
> So the code looks at q->max_segment_size and tries to allocate segments
> that large initially. If that is too large then it will drop down by
> half like what sg.c used to do when it could not allocate large segments.
>
> I will add the param back if you want. I had thought it was a workaound
> due to the segment size of a device not being exported.
>
>>
>> *** Generalizing the idea of a mmap-ed reserve buffer to
>> something the user had more control over could be very
>> powerful.
>> For example allowing two file descriptors (to different
>> devices) in the same process to share the same mmap-ed
>> area. This would allow a device to device copy to DMA into
>> and out of the same memory, potentially with large per command
>> transfers and with no per command scatter gather build and
>> tear down. Basically a zero copy copy with minimal CPU
>> overhead.
>>
>
> I was thinking of something similar but not based on mmap. I have been
> trying to figure out a way to do sg io splice. I do not care what
> interface or method is used, I think it would be useful.
>
> I know we talked about the mmap approach a little, but I do not remember
> if we talked about how to tell both fds that they are going to use the
> same buffer. Would we need a modification to the sg header or would we
> need to add in a new IOCTL which would tell sg.c to share the buffer
> between two fds?
Mike,
Currently there is a flag in sgv3:
#define SG_FLAG_MMAP_IO 4
and when it is active the dxferp field is ignored
as it is assumed the user previously did a mmap()
call to get the reserved buffer.
We could add a:
#define SG_FLAG_MMAP_IO_SHARED 8
and then the pointer in dxferp could taken as
the already mmap-ed buffer from another device.
Having more than one mmap-ed IO buffer per file
descriptor would be nice but opening multiple
file descriptors to the same device can give
the same effect (with perhaps a POSIX thread per
file descriptor).
Doug Gilbert
prev parent reply other threads:[~2007-03-04 20:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-04 18:31 convert sg to block layer helpers - v5 michaelc
2007-03-04 18:31 ` [PATCH 1/7] rm bio hacks in scsi tgt michaelc
2007-03-04 18:31 ` [PATCH 2/7] rm block device arg from bio map user michaelc
2007-03-04 18:31 ` [PATCH 3/7] Support large sg io segments michaelc
2007-03-04 18:31 ` [PATCH 4/7] Add reserve buffer for sg io michaelc
2007-03-04 18:31 ` [PATCH 5/7] Add sg io mmap helper michaelc
2007-03-04 18:31 ` [PATCH 6/7] Convert sg to block layer helpers michaelc
2007-03-04 18:31 ` [PATCH 7/7] mv user buffer copy access_ok test to block helper michaelc
2007-03-04 22:56 ` Mike Christie
2007-03-04 19:32 ` convert sg to block layer helpers - v5 Douglas Gilbert
2007-03-04 19:56 ` Mike Christie
2007-03-04 20:17 ` Douglas Gilbert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45EB295A.30601@torque.net \
--to=dougg@torque.net \
--cc=jens.axboe@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.