From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
ocfs2-devel@oss.oracle.com, Ariel Elior <aelior@marvell.com>,
Sudarsana Kalluru <skalluru@marvell.com>,
GR-everest-linux-l2@marvell.com,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, Colin Ian King <colin.king@canonical.com>
Subject: Re: [PATCH v2] ocfs2/dlm: Move BITS_TO_BYTES() to bitops.h for wider use
Date: Mon, 9 Dec 2019 18:43:38 +0200 [thread overview]
Message-ID: <20191209164338.GO32742@smile.fi.intel.com> (raw)
In-Reply-To: <20190827163717.44101-1-andriy.shevchenko@linux.intel.com>
On Tue, Aug 27, 2019 at 07:37:17PM +0300, Andy Shevchenko wrote:
> There are users already and will be more of BITS_TO_BYTES() macro.
> Move it to bitops.h for wider use.
>
> In the case of ocfs2 the replacement is identical.
>
> As for bnx2x, there are two places where floor version is used.
> In the first case to calculate the amount of structures that can fit
> one memory page. In this case obviously the ceiling variant is correct and
> original code might have a potential bug, if amount of bits % 8 is not 0.
> In the second case the macro is used to calculate bytes transmitted in one
> microsecond. This will work for all speeds which is multiply of 1Gbps without
> any change, for the rest new code will give ceiling value, for instance 100Mbps
> will give 13 bytes, while old code gives 12 bytes and the arithmetically
> correct one is 12.5 bytes. Further the value is used to setup timer threshold
> which in any case has its own margins due to certain resolution. I don't see
> here an issue with slightly shifting thresholds for low speed connections, the
> card is supposed to utilize highest available rate, which is usually 10Gbps.
Anybody to comment on bnx2 change?
Can we survive with this applied?
>
> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> - described bnx2x cases in the commit message
> - appended Rb (for ocfs2)
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h | 1 -
> fs/ocfs2/dlm/dlmcommon.h | 4 ----
> include/linux/bitops.h | 1 +
> 3 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h
> index 066765fbef06..0a59a09ef82f 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h
> @@ -296,7 +296,6 @@ static inline void bnx2x_dcb_config_qm(struct bnx2x *bp, enum cos_mode mode,
> * possible, the driver should only write the valid vnics into the internal
> * ram according to the appropriate port mode.
> */
> -#define BITS_TO_BYTES(x) ((x)/8)
>
> /* CMNG constants, as derived from system spec calculations */
>
> diff --git a/fs/ocfs2/dlm/dlmcommon.h b/fs/ocfs2/dlm/dlmcommon.h
> index aaf24548b02a..0463dce65bb2 100644
> --- a/fs/ocfs2/dlm/dlmcommon.h
> +++ b/fs/ocfs2/dlm/dlmcommon.h
> @@ -688,10 +688,6 @@ struct dlm_begin_reco
> __be32 pad2;
> };
>
> -
> -#define BITS_PER_BYTE 8
> -#define BITS_TO_BYTES(bits) (((bits)+BITS_PER_BYTE-1)/BITS_PER_BYTE)
> -
> struct dlm_query_join_request
> {
> u8 node_idx;
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index cf074bce3eb3..79d80f5ddf7b 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -5,6 +5,7 @@
> #include <linux/bits.h>
>
> #define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE)
> +#define BITS_TO_BYTES(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE)
> #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_TYPE(long))
>
> extern unsigned int __sw_hweight8(unsigned int w);
> --
> 2.23.0.rc1
>
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2019-12-09 16:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 16:37 [PATCH v2] ocfs2/dlm: Move BITS_TO_BYTES() to bitops.h for wider use Andy Shevchenko
2019-12-09 16:43 ` Andy Shevchenko [this message]
2019-12-11 3:32 ` Sudarsana Reddy Kalluru
2019-12-11 6:59 ` Joseph Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191209164338.GO32742@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=GR-everest-linux-l2@marvell.com \
--cc=aelior@marvell.com \
--cc=colin.king@canonical.com \
--cc=davem@davemloft.net \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=mark@fasheh.com \
--cc=netdev@vger.kernel.org \
--cc=ocfs2-devel@oss.oracle.com \
--cc=skalluru@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox