> -----Original Message----- > From: Andy Shevchenko <[email protected]> > Sent: Thursday, August 22, 2019 2:39 PM > To: Sudarsana Reddy Kalluru <[email protected]> > Cc: Joseph Qi <[email protected]>; Mark Fasheh > <[email protected]>; Joel Becker <[email protected]>; ocfs2- > [email protected]; Ariel Elior <[email protected]>; GR-everest-linux-l2 > <[email protected]>; David S. Miller > <[email protected]>; [email protected]; Colin Ian King > <[email protected]> > Subject: Re: [PATCH v1] ocfs2/dlm: Move BITS_TO_BYTES() to bitops.h for > wider use > > On Thu, Aug 22, 2019 at 05:46:07AM +0000, Sudarsana Reddy Kalluru wrote: > > > > > -----Original Message----- > > > From: [email protected] <[email protected]> > On > > > Behalf Of Andy Shevchenko > > > Sent: Wednesday, August 21, 2019 2:56 PM > > > To: Joseph Qi <[email protected]> > > > Cc: Mark Fasheh <[email protected]>; Joel Becker <[email protected]>; > > > [email protected]; Ariel Elior <[email protected]>; > > > Sudarsana Reddy Kalluru <[email protected]>; GR-everest-linux-l2 > > > <GR-everest- [email protected]>; David S. Miller > > > <[email protected]>; [email protected]; Colin Ian King > > > <[email protected]> > > > Subject: Re: [PATCH v1] ocfs2/dlm: Move BITS_TO_BYTES() to bitops.h > > > for wider use > > > > > > On Wed, Aug 21, 2019 at 09:29:04AM +0800, Joseph Qi wrote: > > > > On 19/8/21 00:31, Andy Shevchenko wrote: > > > > > There are users already and will be more of BITS_TO_BYTES() macro. > > > > > Move it to bitops.h for wider use. > > > > > > -#define BITS_TO_BYTES(x) ((x)/8)> > > > > I don't think this is a equivalent replace, or it is in fact wrong > > > > before? > > > > > > I was thinking about this one and there are two applications: > > > - calculus of the amount of structures of certain type per PAGE > > > (obviously off-by-one error in the original code IIUC purpose of > > > STRUCT_SIZE) > > > - calculus of some threshold based on line speed in bytes per second > > > (I dunno it will have any difference on the Gbs / 100 MBs speeds) > > > > > I see that both the implementations (existing vs new) yield same value for > standard speeds 10G (i.e.,10000), 1G (1000) that device supports. Hence the > change look to be ok. > > Thank you for testing, may I use your Tested-by tag? Sorry, I didn't test the actual driver flows. Was only referring to the output values for 1000/10000 speed values.
> > -- > With Best Regards, > Andy Shevchenko >
