Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4226759ybi; Mon, 27 May 2019 13:50:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqy+f2jbsChIToAdL+lI8iAkeOtmYHhPrABbxRDOArTyi+ezWpF6c0BlEU7koGLXplSO391e X-Received: by 2002:a17:902:b495:: with SMTP id y21mr64755261plr.243.1558990209752; Mon, 27 May 2019 13:50:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558990209; cv=none; d=google.com; s=arc-20160816; b=wCpneve5bJO4J9zP/qYGt6Wq2hgfXc4mz0FohYf55Tk/CU1HitpIp1hXEhieVr3FeV fjTpkX993Z0P6sgzTpbOdl+LAbhx32KlmjTkKt6SZvMu23acT/Yqq1JxQ+ekmTdX0R5u 2vZ9eSDUnhYvQpZ4PUSEnfSUh/OVH5Mvz+vi40k13fD1e5AFmTIUsXN+MyJXKct8kgmW hy9AawjxyGCJSPUcE7TkRDcBWRcvjLP73UUR0+/NnJrV27W5vbleSvzIfrpcQZihjxRY GeS0ogKWrnnV6NY5/gUusawmbTlEnLMgTnJIrRDpEAvToAWKfz/9NTglFy76JX5hp+hn uRFg== 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=JHQAct1AwQ+0o41NmBXevSxxhcFMKYLzia7iTgAALaQ=; b=MTRQd/75AngyWdls+japMcfrss7NcQUCl2ugIMOKYlybNNPAOuYHey+PkJE2i0kYBB CZCOJxlITmlX/dKON+riMqSjxdpRFmeMqLNhajPvcWOlQi4w5A9A9QCMwv5LYjWMbK6V xzoboN7Lg69mGvo2kVbjSIQzOKYLn/57Hpw2F+jvlXKx5dKfd4oL5XymOivUFbcek9Xh yEdN7ai6FwQRNbHA4JtpRIF/Fcd/OcYXXk4sbQ4Nz6rIcYVZBWViVIG6Io2QceHwOxZG jFoChd0PAHE8OD8YHckPjCkEduMN3MXEuJCjm8+60DGutW9SqhUs5thK2wmiiA3VgME+ sjAg== 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 u9si20954816pfn.253.2019.05.27.13.49.54; Mon, 27 May 2019 13:50: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 S1727196AbfE0Ur3 (ORCPT + 99 others); Mon, 27 May 2019 16:47:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:39354 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727132AbfE0Ur3 (ORCPT ); Mon, 27 May 2019 16:47:29 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id F30BEAF49; Mon, 27 May 2019 20:47:27 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 7CC76E00A9; Mon, 27 May 2019 22:47:27 +0200 (CEST) Date: Mon, 27 May 2019 22:47:27 +0200 From: Michal Kubecek To: Jason Gunthorpe Cc: Leon Romanovsky , Doug Ledford , Ariel Levkovich , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mlx5: avoid 64-bit division Message-ID: <20190527204727.GH30439@unicorn.suse.cz> References: <20190520111902.7104DE0184@unicorn.suse.cz> <20190527181534.GA10029@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190527181534.GA10029@ziepe.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 27, 2019 at 03:15:34PM -0300, Jason Gunthorpe wrote: > On Mon, May 20, 2019 at 01:19:02PM +0200, Michal Kubecek wrote: > > diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c > > index abac70ad5c7c..340290b883fe 100644 > > +++ b/drivers/infiniband/hw/mlx5/main.c > > @@ -2344,7 +2344,7 @@ static int handle_alloc_dm_sw_icm(struct ib_ucontext *ctx, > > /* Allocation size must a multiple of the basic block size > > * and a power of 2. > > */ > > - act_size = roundup(attr->length, MLX5_SW_ICM_BLOCK_SIZE(dm_db->dev)); > > + act_size = round_up(attr->length, MLX5_SW_ICM_BLOCK_SIZE(dm_db->dev)); > > act_size = roundup_pow_of_two(act_size); > > It is kind of weird that we have round_up and the bitshift > version.. None of this is performance critical so why not just use > round_up everywhere? > > Ariel, it is true MLX5_SW_ICM_BLOCK_SIZE will always be a power of > two? If it weren't, the requirements from the comment above could never be satisfied as a power of two can only be a multiple of another power of two. Which also means that what the code above does is in fact equivalent to act_size = max_t(u64, roundup_pow_of_two(attr->length), MLX5_SW_ICM_BLOCK_SIZE(dm_db->dev)); or act_size = roundup_pow_of_two(max_t(u64, attr->length, MLX5_SW_ICM_BLOCK_SIZE(dm_db->dev)); Michal Kubecek