From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD3c9-0005IN-JF for qemu-devel@nongnu.org; Thu, 09 Jul 2015 00:39:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZD3c4-0003O0-MM for qemu-devel@nongnu.org; Thu, 09 Jul 2015 00:39:13 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:36671 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZD3c4-0003NQ-Av for qemu-devel@nongnu.org; Thu, 09 Jul 2015 00:39:08 -0400 Message-ID: <559DFAE6.1020005@kamp.de> Date: Thu, 09 Jul 2015 06:39:02 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1436369462-24252-1-git-send-email-stefanha@redhat.com> <1436369462-24252-2-git-send-email-stefanha@redhat.com> In-Reply-To: <1436369462-24252-2-git-send-email-stefanha@redhat.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.5 1/4] block: add BlockLimits.max_iov field List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , qemu-devel@nongnu.org Cc: Kevin Wolf , qemu-block@nongnu.org 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 > Suggested-by: Kevin Wolf > Signed-off-by: Stefan Hajnoczi > --- > 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. > > 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? Peter