Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp8342015ybi; Thu, 6 Jun 2019 10:35:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqwy4gZokJZp3NbrwcKervVBbGtaX/7LLkXWEFJVJxc4pdmwYxTafOpU7jwHOrk9ZzIfPHDy X-Received: by 2002:a17:90a:1902:: with SMTP id 2mr965026pjg.113.1559842509681; Thu, 06 Jun 2019 10:35:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559842509; cv=none; d=google.com; s=arc-20160816; b=p3hz1XVNYVOqEgm2rcq/Jis69tNrF/B/rucZhO+tTEAFJG/Ntu9n7eNPgUe+eisz2b nX9orE2V64y+FsT8A5nLWLvSKfjChQEb4PX86cDs279X48TtG4MGYjhD3xAJlZc+r8SH H7Ejk+naJqFg7eQkrDSMTpsU32s4LW+5rVjLSmvJiS1xbRmkvUq2C6G42w8KN3FaTC87 KsSw4nKt+mce9Au+UUS9ARRgLl0AYbUKqlkKGjfrdF2+5M5MwuGLI2WnZ7WCWC9DOpdO ia2CHpmF6i/7oKwC3+g9rUzjH4aJ+kjJaFnRGKzBHEpm6e/NhGbFPxVYciYcpbgUZ/Is yUlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=71R1aFiK2A/Th+jdMI51PnzsNWjtUpEw+jQGO6EL1No=; b=zjLuXrV5VD7aFoOQpvF+j398A+QLtE8Sgl6vqWzh4grQeRNUroSaIdfPAZceSEc7zu 2drIBBezaOeZY4/29fL1q6cdxQfVQsNbKwy4yW+2Iee5pu/ywGMITW8LWEamgNkPKAaz mHfuWGz7MxvPBLQbecw8H7UDAnKsCrvMeAA6iiiPOk5DD6qIQqTRCCxqKaYIPa5WRND8 abpOkaWHGSWogb6M3cUKXWPB3d8xqiZCVUvG2/9dfCFyQrL/2BIl+vdrxzV65JCnnM0p 4Ni/9+G73fNN6HZ+0Lv5l8cBKXMJ0Xl1NCl5W9nRnqGYRkacOzPO1DtmexnIpBIYaPMC 9PQQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d12si2411211pgd.580.2019.06.06.10.34.52; Thu, 06 Jun 2019 10:35:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728823AbfFFOUT (ORCPT + 99 others); Thu, 6 Jun 2019 10:20:19 -0400 Received: from verein.lst.de ([213.95.11.211]:49883 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727961AbfFFOUS (ORCPT ); Thu, 6 Jun 2019 10:20:18 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id BE3A968B20; Thu, 6 Jun 2019 16:19:50 +0200 (CEST) Date: Thu, 6 Jun 2019 16:19:50 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Christoph Hellwig , Jens Axboe , Sebastian Ott , Sagi Grimberg , Max Gurtovoy , Bart Van Assche , Ulf Hansson , Alan Stern , Oliver Neukum , linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, linux-mmc@vger.kernel.org, linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org, megaraidlinux.pdl@broadcom.com, MPT-FusionLinux.pdl@broadcom.com, linux-hyperv@vger.kernel.org, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH 08/13] IB/iser: set virt_boundary_mask in the scsi host Message-ID: <20190606141950.GB15112@lst.de> References: <20190605190836.32354-1-hch@lst.de> <20190605190836.32354-9-hch@lst.de> <20190605202235.GC3273@ziepe.ca> <20190606062441.GB26745@lst.de> <20190606125935.GA17373@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190606125935.GA17373@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 06, 2019 at 09:59:35AM -0300, Jason Gunthorpe wrote: > > Until we've sorted that out the device paramter needs to be set to > > the smallest value supported. > > smallest? largest? We've been setting it to the largest value the > device can handle (ie 2G) Well, in general we need the smallest value supported by any ULP, because if any ULP can't support a larger segment size, we must not allow the IOMMU to merge it to that size. That being said I can't really see why any RDMA ULP should limit the size given how the MRs work.