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 <p...@kamp.de> > >Suggested-by: Kevin Wolf <kw...@redhat.com> > >Signed-off-by: Stefan Hajnoczi <stefa...@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
pgpcRS4CXoxvM.pgp
Description: PGP signature