Re: [Qemu-devel] [PATCH for-2.5 1/4] block: add BlockLimits.max_iov field

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

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 <pl@kamp.de>
> >Suggested-by: Kevin Wolf <kwolf@redhat.com>
> >Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> >---
> >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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]