From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABBDCC31E49 for ; Thu, 13 Jun 2019 19:58:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 863C92133D for ; Thu, 13 Jun 2019 19:58:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="VvRUdVRn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729559AbfFMT6z (ORCPT ); Thu, 13 Jun 2019 15:58:55 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:37016 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729588AbfFMT6u (ORCPT ); Thu, 13 Jun 2019 15:58:50 -0400 Received: by mail-io1-f66.google.com with SMTP id e5so687657iok.4 for ; Thu, 13 Jun 2019 12:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=0g3LShZij9OvLky32ww/mm8nsliTsm7gD3njRd6NCQk=; b=VvRUdVRnyB4TuhZ+9+/oPM6pb8vxTclPrmvRFZ9PzavJCtkYfSYgjGNiCUQTux1nUl 9VjOQatdu+aPOowyvOuIY8hKioFj1wntgGyBXavSkEATXrC/5DcyjhYCe5Ag1uW/q8zp fQGdKjxC19RzzJyIAL/Mw4avblUSP65mKGcmY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=0g3LShZij9OvLky32ww/mm8nsliTsm7gD3njRd6NCQk=; b=PxPqlTrLJlQ5lONN1cq4VYHg6i3hWawOJ5dx6plUb/Dno9C6k8Ud7ycVczKFVIDtn7 Egtp4iRMSUmdqD05DhKzW3GI100N1lv1OFQ/o4Ut/WjvVZi/iXg0LAEP/Y0MJ5ieoAXu +4kTVX+PPSEw+7cXKFpaWeeMZPALgPwio+TPe5XZLY7sp6sNHoWkulbl93xhH7gIgEH0 +vp3z/p677ilLA+hAGCVP8aYyHNJA+YMmzNzMq3RIUCkq7tv/BDGMLr0b6GmVA5h+OOZ 0PN4TtELn+o/4CP/QKNUkMrCCIYVtmTakDUhZBDFNrxt/7bkMXihatw6QN7MFMDto8P2 flOA== X-Gm-Message-State: APjAAAWWHIEcN0Ts22PJxVjmVzDs8q6lVFyvRfTFSeEJhxf2M38+3Ts6 ++1FUMnRVy1nXJoNffJQ+147O+U0xmB+32LyersFYw== X-Google-Smtp-Source: APXvYqxdGc8NyPROiaW5qZ3CjU9Mi5BWb0Y5+Ghq0hcByTKiBd2ar5O9a3Vi002QTGCiPnE/Sx2A/4naPXD8YwkquS4= X-Received: by 2002:a6b:f910:: with SMTP id j16mr7292522iog.256.1560455929090; Thu, 13 Jun 2019 12:58:49 -0700 (PDT) From: Kashyap Desai References: <20190605190836.32354-1-hch@lst.de> <20190605190836.32354-11-hch@lst.de> <20190608081400.GA19573@lst.de> In-Reply-To: <20190608081400.GA19573@lst.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNLjZIO2zMn7N+9xPobnDbFSu4o5gI2RJdJAgF+bYgBfxw4kaN/cE8Q Date: Fri, 14 Jun 2019 01:28:47 +0530 Message-ID: <98f6557ae91a7cdfe8069fcf7d788c88@mail.gmail.com> Subject: RE: [PATCH 10/13] megaraid_sas: set virt_boundary_mask in the scsi host To: Christoph Hellwig Cc: 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, "PDL,MEGARAIDLINUX" , PDL-MPT-FUSIONLINUX , linux-hyperv@vger.kernel.org, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org > > On Thu, Jun 06, 2019 at 09:07:27PM +0530, Kashyap Desai wrote: > > Hi Christoph, Changes for and looks good. We > > want to confirm few sanity before ACK. BTW, what benefit we will see > > moving virt_boundry setting to SCSI mid layer ? Is it just modular > > approach OR any functional fix ? > > The big difference is that virt_boundary now also changes the > max_segment_size, and this ensures that this limit is also communicated to > the DMA mapping layer. Is there any changes in API blk_queue_virt_boundary? I could not find relevant code which account for this. Can you help ? Which git repo shall I use for testing ? That way I can confirm, I didn't miss relevant changes. >From your above explanation, it means (after this patch) max segment size of the MR controller will be set to 4K. Earlier it is possible to receive single SGE of 64K datalength (Since max seg size was 64K), but now the same buffer will reach the driver having 16 SGEs (Each SGE will contain 4K length). Right ? Kashyap