From: Alex Pyrgiotis <apyrgio@arrikto.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/9] Add full scatter-gather support for SCSI generic devices
Date: Thu, 17 Dec 2015 10:47:10 +0200 [thread overview]
Message-ID: <5672768E.70101@arrikto.com> (raw)
In-Reply-To: <5671AA78.8050603@redhat.com>
Hi Paolo,
On 12/16/2015 08:16 PM, Paolo Bonzini wrote:
>
>
> On 16/12/2015 17:55, Alex Pyrgiotis wrote:
>> Hi all,
>>
>> This patch is an attempt to boost the performance of "scsi-generic" and
>> "scsi-block" device types, by removing an extra data copy and reducing
>> their memory footprint. More specifically, the problem lies in the
>> functions in the `scsi-generic_req_ops` struct of scsi-generic.c. These
>> functions rely on an intermediate buffer to do the SG_IO ioctl request,
>> without checking if the SCSI controller has provided a scatter-gather
>> list with the request.
>>
>> In a nutshell, our proposal is to map the provided scatter-gather list
>> (if any) to the address space of the QEMU process and use the resulting
>> iovec as the buffer for the ioctl request. You'll find that the logic is
>> quite similar to the one used in scsi-disk.c.
>
> Which commands have large payloads and are on the data path, for
> scsi-block? Or is the use case just scsi-generic (e.g. tape devices?)?
>
> (Just trying to understand before I dive into the patches).
Sure, no problem. The commands that have large payloads and are on the
data path are the classic SCSI READ/WRITE commands. Usually, these
commands are implemented with vectored reads/writes, which utilize the
controller's scatter-gather list.
However, when opening a "scsi-block" device with the default cache
policy (cache=writeback), QEMU fallbacks to the "scsi-generic" functions
(i.e, SG_IO ioctl requests) for reading/writing data [1]. In this case,
the data are copied in a bounce buffer, which is the issue that this
patch tackles.
Thanks,
Alex
[1]: I'll quote the comment on the code for the rationale behind this
choice:
"If we are not using O_DIRECT, we might read stale data from
the host cache if writes were made using other commands than
these ones (such as WRITE SAME or EXTENDED COPY, etc.). So,
without O_DIRECT everything must go through SG_IO."
next prev parent reply other threads:[~2015-12-17 8:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 16:55 [Qemu-devel] [PATCH 0/9] Add full scatter-gather support for SCSI generic devices Alex Pyrgiotis
2015-12-16 16:55 ` [Qemu-devel] [PATCH 1/9] dma-helpers: Expose the sg mapping logic Alex Pyrgiotis
2016-02-11 11:17 ` Paolo Bonzini
2016-02-19 11:50 ` Alex Pyrgiotis
2016-02-22 10:43 ` Paolo Bonzini
2016-02-25 10:10 ` Alex Pyrgiotis
2016-02-25 10:22 ` Paolo Bonzini
2016-02-25 11:19 ` Alex Pyrgiotis
2016-02-25 13:01 ` Paolo Bonzini
2016-02-26 9:20 ` Kevin Wolf
2015-12-16 16:55 ` [Qemu-devel] [PATCH 2/9] dma-helpers: Add support for ioctl operations Alex Pyrgiotis
2015-12-16 16:55 ` [Qemu-devel] [PATCH 3/9] dma-helpers: Do not truncate small qiovs Alex Pyrgiotis
2016-02-11 11:08 ` Paolo Bonzini
2015-12-16 16:55 ` [Qemu-devel] [PATCH 4/9] scsi-generic: Add common functions Alex Pyrgiotis
2015-12-16 16:55 ` [Qemu-devel] [PATCH 5/9] scsi-generic: Separate `sg_io_hdr' initializations Alex Pyrgiotis
2015-12-16 16:55 ` [Qemu-devel] [PATCH 6/9] scsi-generic: Make request execution buf-specific Alex Pyrgiotis
2015-12-16 16:55 ` [Qemu-devel] [PATCH 7/9] scsi-generic: Make data-copying logic clearer Alex Pyrgiotis
2015-12-16 16:55 ` [Qemu-devel] [PATCH 8/9] scsi-generic: Factor out response interception Alex Pyrgiotis
2015-12-16 16:55 ` [Qemu-devel] [PATCH 9/9] scsi-generic: Allow full scatter-gather support Alex Pyrgiotis
2015-12-16 18:16 ` [Qemu-devel] [PATCH 0/9] Add full scatter-gather support for SCSI generic devices Paolo Bonzini
2015-12-17 8:47 ` Alex Pyrgiotis [this message]
2015-12-17 10:31 ` Paolo Bonzini
2015-12-17 13:10 ` Alex Pyrgiotis
2015-12-17 13:13 ` Paolo Bonzini
2015-12-21 10:58 ` Alex Pyrgiotis
2016-01-11 13:30 ` Alex Pyrgiotis
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=5672768E.70101@arrikto.com \
--to=apyrgio@arrikto.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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 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.