All of lore.kernel.org
 help / color / mirror / Atom feed
From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Benoît Canet" <benoit.canet@irqsave.net>,
	"Kevin Wolf" <kwolf@redhat.com>, "Peter Lieven" <pl@kamp.de>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Max Reitz" <mreitz@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests
Date: Mon, 8 Sep 2014 08:13:14 -0700	[thread overview]
Message-ID: <CAN05THTw=kH8czp24TVBBQXXSN8v1fuTrCogapRAdK0g-KywhQ@mail.gmail.com> (raw)
In-Reply-To: <540DC059.4000907@redhat.com>

On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 08/09/2014 16:35, Peter Lieven ha scritto:
>>>>>
>>>>> messages. :)
>>>> So you would not throw an error msg here?
>>> No, though a trace could be useful.
>>
>> Is there a howto somewhere how to implement that?
>
> Try commit 4ac4458076e1aaf3b01a6361154117df20e22215.
>
>> Whats your opinion changed the max_xfer_len to 0xffff regardsless
>> of use_16_for_rw in iSCSI?
>
> If you implemented request splitting in the block layer, it would be
> okay to force max_xfer_len to 0xffff.

I think it should be OK if that is a different series. This only
affects the iSCSI transport since it is the only transport so far to
record or report a max transfer length.
If a guest generates these big requests(i.e. not multiwrite) we
already fail them due to the READ10 limitations. We would just fail
the request at a different layer in the stack with these patches.


What I would like to see would also be to report these limitations to
the guest itself to prevent it from generating too large I/Os.
I am willing to do that part once the initial max_xfer_len ones are finished.

  parent reply	other threads:[~2014-09-08 15:13 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 16:51 [Qemu-devel] [PATCH 0/4] introduce max_transfer_length Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 1/4] BlockLimits: " Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests Peter Lieven
2014-09-08 13:44   ` Benoît Canet
2014-09-08 13:49     ` Paolo Bonzini
2014-09-08 13:56       ` Peter Lieven
2014-09-08 13:58         ` Paolo Bonzini
2014-09-08 14:35           ` Peter Lieven
2014-09-08 14:42             ` Paolo Bonzini
2014-09-08 14:54               ` Peter Lieven
2014-09-23  8:47                 ` Kevin Wolf
2014-09-23  8:55                   ` Peter Lieven
2014-09-23  9:09                     ` Kevin Wolf
2014-09-08 15:13               ` ronnie sahlberg [this message]
2014-09-08 15:15                 ` Paolo Bonzini
2014-09-08 15:18                   ` Peter Lieven
2014-09-08 15:27                     ` Paolo Bonzini
2014-09-08 16:18                       ` Peter Lieven
2014-09-08 16:29                         ` Paolo Bonzini
2014-09-12 11:43                           ` Peter Lieven
2014-09-18 14:12                             ` Paolo Bonzini
2014-09-18 14:16                               ` Peter Lieven
2014-09-18 14:17                                 ` Paolo Bonzini
2014-09-18 22:57                                   ` Peter Lieven
2014-09-08 15:16                 ` Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 3/4] block/iscsi: set max_transfer_length Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 4/4] block: avoid creating oversized writes in multiwrite_merge Peter Lieven
2014-09-18 14:13   ` Paolo Bonzini
2014-09-18 22:56     ` Peter Lieven
2014-09-19 13:33       ` Paolo Bonzini
2014-09-22  9:43         ` Peter Lieven
2014-09-22 19:06           ` Paolo Bonzini
2014-09-23  6:15             ` Peter Lieven
2014-09-23  8:59               ` Kevin Wolf
2014-09-23  9:04                 ` Peter Lieven
2014-09-23  9:32                 ` Peter Lieven
2014-09-23  9:47                   ` Kevin Wolf
2014-09-23  9:52                     ` Peter Lieven
2014-09-23 10:05                       ` Kevin Wolf
2014-09-30  7:26                         ` Peter Lieven
2014-09-30  8:03                           ` Kevin Wolf
2014-09-05 17:05 ` [Qemu-devel] [PATCH 0/4] introduce max_transfer_length ronnie sahlberg
2014-09-05 19:52   ` Peter Lieven
2014-09-05 21:22     ` ronnie sahlberg

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='CAN05THTw=kH8czp24TVBBQXXSN8v1fuTrCogapRAdK0g-KywhQ@mail.gmail.com' \
    --to=ronniesahlberg@gmail.com \
    --cc=benoit.canet@irqsave.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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.