[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH for-2.5 1/4] block: add BlockLimits.max_iov fiel
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] [PATCH for-2.5 1/4] block: add BlockLimits.max_iov field |
Date: |
Thu, 9 Jul 2015 10:46:42 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Thu, Jul 09, 2015 at 06:39:02AM +0200, Peter Lieven wrote:
> Am 08.07.2015 um 17:30 schrieb Stefan Hajnoczi:
> >The maximum number of struct iovec elements depends on the
> >BlockDriverState. The raw-posix protocol has a maximum of IOV_MAX but
> >others could have different values.
> >
> >Instead of assuming raw-posix and hardcoding IOV_MAX in several places,
> >put the limit into BlockLimits.
> >
> >Cc: Peter Lieven <address@hidden>
> >Suggested-by: Kevin Wolf <address@hidden>
> >Signed-off-by: Stefan Hajnoczi <address@hidden>
> >---
> >Peter Lieven: I think the SCSI LUN level does not have a maximum
> >scatter-gather segments constraint. That is probably only at the HBA
> >level. CCed you anyway in case you think block/iscsi.c should set the
> >max_iov field.
>
> libiscsi will send the iovec array straight to readv and writev to
> read/write from the TCP socket. So we need IOV_MAX here as well.
Thanks, will fix in v2!
> >
> >Kevin: The default is now INT_MAX. This means non-raw-posix users will
> >now be able to merge more requests than before. They were limited to
> >IOV_MAX previously. This could expose limits in other BlockDrivers
> >which we weren't aware of...
>
> Why rise the default to INT_MAX and not leave it at IOV_MAX?
> Is there any case where we except that much iovectors coming in?
Both block/mirror.c and request merge have resulted in >1024 iovecs in
the past. That means they can take advantage of a higher limit.
On the other hand, I think you are right that the default should be
IOV_MAX and only drivers with higher/lower limits should set max_iov
themselves. It's safer.
Stefan
pgpp91SkUF9Yu.pgp
Description: PGP signature