From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtlaS-0002YN-HP for qemu-devel@nongnu.org; Wed, 26 Nov 2014 18:01:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtlaN-0006NS-RA for qemu-devel@nongnu.org; Wed, 26 Nov 2014 18:01:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtlaN-0006N9-JZ for qemu-devel@nongnu.org; Wed, 26 Nov 2014 18:01:23 -0500 Date: Wed, 26 Nov 2014 18:00:55 -0500 From: Mike Snitzer Message-ID: <20141126230055.GA32363@redhat.com> References: <20141120190058.GA31214@redhat.com> <20141121095456.GB8866@infradead.org> <20141121154920.GA7644@redhat.com> <54762E9A.2070007@kernel.dk> <20141126205106.GA31815@redhat.com> <54763DEC.3050207@kernel.dk> <20141126215108.GA32077@redhat.com> <54764BD1.2070804@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54764BD1.2070804@kernel.dk> Subject: Re: [Qemu-devel] virtio_blk: fix defaults for max_hw_sectors and max_segment_size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jens Axboe Cc: martin.petersen@oracle.com, mst@redhat.com, rusty@rustcorp.com.au, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, Christoph Hellwig , dm-devel@redhat.com, Paolo Bonzini On Wed, Nov 26 2014 at 4:53pm -0500, Jens Axboe wrote: > On 11/26/2014 02:51 PM, Mike Snitzer wrote: > > > > But while you're here, I wouldn't mind getting your take on virtio-blk > > setting max_hw_sectors to -1U. > > > > As I said in my original reply to mst: it only makes sense to set a > > really high initial upper bound like that in a driver if that driver > > goes on to stack an underlying device's limit. > > -1U should just work, IMHO, there's no reason we should need to cap it > at some synthetic value. That said, it seems it should be one of > those parameters that should be negotiated up and set appropriately. I'm saying set it to the underlying device's value for max_hw_sectors -- not some synthetic value. So I think we're saying the same thing. But it isn't immediately clear (to me) how that benefits virtio-blk users (obviously they are getting by today). So until that is pinned down I imagine nobody will care to extend the virtio-blk protocol to allow stacking max_hw_sectors and max_sectors up.