Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4108488ybi; Mon, 27 May 2019 11:16:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqyGrt60sci2jzlwDWNlu8kIU/3jOvPOKYQcaO8cAhqHDiOs/0cujqKfi2pg8P9tnfh30x6E X-Received: by 2002:a17:902:f085:: with SMTP id go5mr118326322plb.53.1558981016129; Mon, 27 May 2019 11:16:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558981016; cv=none; d=google.com; s=arc-20160816; b=WrWfiyYc02QZ3+F1tpoHs2vQiRcT6NmLHRpC9PqPDQ8xXKi9Fg+aTYX6OF142ow7z8 1CXaxuXgHYIFs19PQUB+e+CDxijlKRkIP+wmLHRSGL0NQdZJJVVVIT2I9y868clSeHvC bA0UVmA4vSxjvjP5Y3I66PIDLoN88/2qgPdSkX1WIYezhOWCIm9L/uDADO7pOD4ci8bY qI+OrrP1mW1d8zBlecGZVPKVrxGVl/Ket3YyAxoR4WEn9dQ1t88WtQRzBd94NXxH0KU2 BRxXwE9Vk+stQnU/HZ0mhWU+htRw5vz2t23sAEFBNxWjSJ2Gvo3nxW/Xg7f1PjnVpizv KNRA== 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:dkim-signature; bh=8hNxMGBAGDDkJj992yk9VOgjaUK9vfpRQoQGfXOovpE=; b=ypBM6EKj0VH2i/ezUpXdlww5Xv5FL/2rTR3dfNtBAsQzI/jIJ0/13F8QXncb1ugSPh vDQHOqZHBN1EoT1yGDO9V7VktI58/4sWZJDqSl37rcHu4/MuWQKxCi/+w6ZPA6ynWOFn b/X+qLxZfe/dxGz9J/tP8UCuoIrcE9HRk2E0bWgVRrJngItIBD4ycH3kw498SMSuRucZ Y+Nr3wFBhRL0UuhYP/wosC6On3gTD6cOHnPWyVrsKhxm/HMfC8gXiHt8kGdsClwoS38T epUIFOcXR5oZXpn1fINLf2ATpHJkE8+P1QPQXNXFPz15KfM5eVQDwH7Is2zm7baPGxt6 tw+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=R35p3owa; 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 j142si21064627pfd.262.2019.05.27.11.16.40; Mon, 27 May 2019 11:16:56 -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; dkim=pass header.i=@ziepe.ca header.s=google header.b=R35p3owa; 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 S1727128AbfE0SPg (ORCPT + 99 others); Mon, 27 May 2019 14:15:36 -0400 Received: from mail-ua1-f66.google.com ([209.85.222.66]:34622 "EHLO mail-ua1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726839AbfE0SPg (ORCPT ); Mon, 27 May 2019 14:15:36 -0400 Received: by mail-ua1-f66.google.com with SMTP id 7so6804913uah.1 for ; Mon, 27 May 2019 11:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8hNxMGBAGDDkJj992yk9VOgjaUK9vfpRQoQGfXOovpE=; b=R35p3owaTNtpz8MKhE3eb7p90Rmi3WA5z/IJLfYWxVZBpq3sSmZbyPaLZ+g95OFPLj 9nln1OdB5Rvf8gwb4rQbRYIsNLusvEJXx7zGVj5EYwA83fEJtc5HaF1UNeCxOy5omeDa GAyE56QpwHgC0CT68m18jw6FEeT/1n2spYPfWdSBhQgdW6IKW3e90iju4iJHMzcjoEr8 zyTxg1uWCQHDh7WZaUCrOJIKk18+S8uCyT77OMo4QJ0+v9wCEPzhPZEmgYXkMXXMm8VG MtX0tokKVf2ITpLZZPa0p/ErpJtrljHSYPhMSlFxTmruq7ArzrEqc5QUvzfeuyQkWFG2 epXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8hNxMGBAGDDkJj992yk9VOgjaUK9vfpRQoQGfXOovpE=; b=Ii20353rWwc/Cy5FwPR6hbXUo772gxePoVQFOLH0ZE+qVFB01pEXuQbkH0waDcWeqa 6JgLTVg1qcMTyciaEr+Uc0zcDe6TSNVJlgHBfOPsIsVxEGmt5ofoz5fxeCllkZkeW6zb AShfy8klRLl8mLVsSc8e/ge/Jl2yMwWfQ/hQvPA2knBbBk4A2x/T61EDJ90GWNdjyTfF EPxG4NRLa6ktLFKIxykiRPisvMYWjJoDb0NzMr1G97HDHqY6+iQBv2kGApFixeiuITEX GY46XuIKV8u4+Liz8csdGWsI4Mj3X+6lcz3vD6YXdIVEBNe8PlOCtP1SXUbEjDtHQ4UV LT3Q== X-Gm-Message-State: APjAAAX86rOdjxL7U62aw6LYLlTtrkNjgqWTiw4NZ4q8hyU8sFpuIsXO POTT097CV7hYryqotaZw0/Aydg== X-Received: by 2002:ab0:4a97:: with SMTP id s23mr22342607uae.19.1558980935337; Mon, 27 May 2019 11:15:35 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-55-100.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.55.100]) by smtp.gmail.com with ESMTPSA id b78sm4160999vkb.10.2019.05.27.11.15.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 May 2019 11:15:34 -0700 (PDT) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1hVK9m-0002cU-92; Mon, 27 May 2019 15:15:34 -0300 Date: Mon, 27 May 2019 15:15:34 -0300 From: Jason Gunthorpe To: Michal Kubecek 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: <20190527181534.GA10029@ziepe.ca> References: <20190520111902.7104DE0184@unicorn.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190520111902.7104DE0184@unicorn.suse.cz> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 20, 2019 at 01:19:02PM +0200, Michal Kubecek wrote: > Commit 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type") > breaks i386 build by introducing three 64-bit divisions. As the divisor > is MLX5_SW_ICM_BLOCK_SIZE() which is always a power of 2, we can replace > the division with bit operations. > > Fixes: 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type") > Signed-off-by: Michal Kubecek > drivers/infiniband/hw/mlx5/cmd.c | 9 +++++++-- > drivers/infiniband/hw/mlx5/main.c | 2 +- > 2 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/infiniband/hw/mlx5/cmd.c b/drivers/infiniband/hw/mlx5/cmd.c > index e3ec79b8f7f5..6c8645033102 100644 > +++ b/drivers/infiniband/hw/mlx5/cmd.c > @@ -190,12 +190,12 @@ int mlx5_cmd_alloc_sw_icm(struct mlx5_dm *dm, int type, u64 length, > u16 uid, phys_addr_t *addr, u32 *obj_id) > { > struct mlx5_core_dev *dev = dm->dev; > - u32 num_blocks = DIV_ROUND_UP(length, MLX5_SW_ICM_BLOCK_SIZE(dev)); > u32 out[MLX5_ST_SZ_DW(general_obj_out_cmd_hdr)] = {}; > u32 in[MLX5_ST_SZ_DW(create_sw_icm_in)] = {}; > unsigned long *block_map; > u64 icm_start_addr; > u32 log_icm_size; > + u32 num_blocks; > u32 max_blocks; > u64 block_idx; > void *sw_icm; > @@ -224,6 +224,8 @@ int mlx5_cmd_alloc_sw_icm(struct mlx5_dm *dm, int type, u64 length, > return -EINVAL; > } > > + num_blocks = (length + MLX5_SW_ICM_BLOCK_SIZE(dev) - 1) >> > + MLX5_LOG_SW_ICM_BLOCK_SIZE(dev); > max_blocks = BIT(log_icm_size - MLX5_LOG_SW_ICM_BLOCK_SIZE(dev)); > spin_lock(&dm->lock); > block_idx = bitmap_find_next_zero_area(block_map, > @@ -266,13 +268,16 @@ int mlx5_cmd_dealloc_sw_icm(struct mlx5_dm *dm, int type, u64 length, > u16 uid, phys_addr_t addr, u32 obj_id) > { > struct mlx5_core_dev *dev = dm->dev; > - u32 num_blocks = DIV_ROUND_UP(length, MLX5_SW_ICM_BLOCK_SIZE(dev)); > u32 out[MLX5_ST_SZ_DW(general_obj_out_cmd_hdr)] = {}; > u32 in[MLX5_ST_SZ_DW(general_obj_in_cmd_hdr)] = {}; > unsigned long *block_map; > + u32 num_blocks; > u64 start_idx; > int err; > > + num_blocks = (length + MLX5_SW_ICM_BLOCK_SIZE(dev) - 1) >> > + MLX5_LOG_SW_ICM_BLOCK_SIZE(dev); > + > switch (type) { > case MLX5_IB_UAPI_DM_TYPE_STEERING_SW_ICM: > start_idx = > 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? Jason