public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: dougg@torque.net
Cc: linux-scsi@vger.kernel.org, jens.axboe@oracle.com
Subject: Re: convert sg to block layer helpers - v5
Date: Sun, 04 Mar 2007 13:56:52 -0600	[thread overview]
Message-ID: <45EB2484.6030700@cs.wisc.edu> (raw)
In-Reply-To: <45EB1EE9.20908@torque.net>

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?

  reply	other threads:[~2007-03-04 19:57 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 [this message]
2007-03-04 20:17     ` Douglas Gilbert

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=45EB2484.6030700@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=dougg@torque.net \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox