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=-4.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 8A928C43457 for ; Tue, 20 Oct 2020 13:09:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 254C3222C8 for ; Tue, 20 Oct 2020 13:09:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407271AbgJTNJ2 (ORCPT ); Tue, 20 Oct 2020 09:09:28 -0400 Received: from mga05.intel.com ([192.55.52.43]:38588 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407227AbgJTNJ2 (ORCPT ); Tue, 20 Oct 2020 09:09:28 -0400 IronPort-SDR: 8dTODszyb3P3mv694aCvKVm9Yinu30VYohKOJD3/+JKtmkYRlvtEW4s52noPczIpGjD3oT+2ik 2scefzWVAQQg== X-IronPort-AV: E=McAfee;i="6000,8403,9779"; a="251898864" X-IronPort-AV: E=Sophos;i="5.77,397,1596524400"; d="scan'208";a="251898864" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2020 06:09:27 -0700 IronPort-SDR: Z3KUvoIflLtbw4sf+RnLwquGDyaC9vpVDg9FZkRN/GeFn06hrM+RVTMv6bYLAKSfqgHRNdVKVN RFynPIg8OhiQ== X-IronPort-AV: E=Sophos;i="5.77,397,1596524400"; d="scan'208";a="533053932" Received: from bszymanx-mobl.ger.corp.intel.com (HELO [10.252.55.244]) ([10.252.55.244]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2020 06:09:25 -0700 Subject: Re: dynamic-sg patch has broken rdma_rxe To: Jason Gunthorpe Cc: Maor Gottlieb , Christoph Hellwig , Gal Pressman , Bob Pearson , Leon Romanovsky , linux-rdma@vger.kernel.org References: <20201016003127.GD6219@nvidia.com> <796ca31aed8f469c957cb850385b9d09@intel.com> <20201016115831.GI6219@nvidia.com> <9fa38ed1-605e-f0f6-6cb6-70b800a1831a@linux.intel.com> <20201019121211.GC6219@nvidia.com> <29ab34c2-0ca3-b3c0-6196-829e31d507c8@linux.intel.com> <20201019124822.GD6219@nvidia.com> <03541c89-92d0-2dc8-5e40-03f3fe527fef@linux.intel.com> <20201020114710.GC6219@nvidia.com> <20201020125659.GD6219@nvidia.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <3eb34c54-1d19-8a4e-f391-e422fbca587d@linux.intel.com> Date: Tue, 20 Oct 2020 14:09:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201020125659.GD6219@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On 20/10/2020 13:56, Jason Gunthorpe wrote: > On Tue, Oct 20, 2020 at 01:31:27PM +0100, Tvrtko Ursulin wrote: >> >> On 20/10/2020 12:47, Jason Gunthorpe wrote: >>> On Tue, Oct 20, 2020 at 12:37:05PM +0100, Tvrtko Ursulin wrote: >>> >>>>> Why put this confusing code in every caller? Especially for something >>>>> a driver is supposed to call. Will just make bugs >>>> >>>> For max_segment to be aligned is a requirement today so callers are >>>> ready. >>> >>> No, it turns out all the RDMA drivers were became broken when they >>> converted to use the proper U32_MAX for their DMA max_segment size, >>> then they couldn't form SGLs anymore. >>> >>> I don't want to see nonsense code like this: >>> >>> dma_set_max_seg_size(dev->dev, min_t(unsigned int, U32_MAX & PAGE_MASK, >>> SCATTERLIST_MAX_SEGMENT)); >>> >>> In drivers. >>> >>> dma_set_max_seg_size is the *hardware* capability, and mixing in >>> things like PAG_MASK here is just nonsense. >> >> Code was obviously a no-op non-sense. >> >> So the crux of the argument is that U32_MAX is conceptually the right thing >> which defines the DMA max_segment size? Not some DMA define or anything, but >> really U32_MAX? And that all/some DMA hardware does not think in pages but >> really in bytes? > > Yes. > > The HW has 32 bits for a length field, so U32_MAX accurately defines > the HW DMA capability Not just the max, but the granularity as well. If byte granularity (well less than PAGE_SIZE/4k) exists in some hw then I agree the API change makes sense. Regards, Tvrtko