Re: [PATCH for-next 3/7] IB/hfi1: Validate PKEY for incoming GSI MAD packets

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

On Mon, Oct 23, 2017 at 02:55:38PM -0400, Dennis Dalessandro wrote:
> On 10/23/2017 2:38 PM, Leon Romanovsky wrote:
> > > diff --git a/drivers/infiniband/hw/hfi1/mad.c
> b/drivers/infiniband/hw/hfi1/mad.c
> > > index 07b80fa..dfe6224 100644
> > > --- a/drivers/infiniband/hw/hfi1/mad.c
> > > +++ b/drivers/infiniband/hw/hfi1/mad.c
> > > @@ -98,6 +98,16 @@ static inline void clear_opa_smp_data(struct opa_smp *smp)
> > >   	memset(data, 0, size);
> > >   }
> > >
> > > +static inline u16 hfi1_lookup_pkey_value(struct hfi1_ibport *ibp, int pkey_idx)
> >
> > Please, no "inline-function" in *.c files as it is written in CodingStyle.
>
> Sure about that?

I'm not style-nazi, so won't insist, but this is in CodingStyle.

Documentation/process/coding-style.rst
 841 15) The inline disease
 842 ----------------------
 843
 844 There appears to be a common misperception that gcc has a magic "make me
 845 faster" speedup option called ``inline``. While the use of inlines can be
 846 appropriate (for example as a means of replacing macros, see Chapter 12), it
 847 very often is not. Abundant use of the inline keyword leads to a much bigger
 848 kernel, which in turn slows the system as a whole down, due to a bigger
 849 icache footprint for the CPU and simply because there is less memory
 850 available for the pagecache. Just think about it; a pagecache miss causes a
 851 disk seek, which easily takes 5 milliseconds. There are a LOT of cpu cycles
 852 that can go into these 5 milliseconds.

>
> As a rule of thumb I agree we should not put inlines in C files though.
> However as you can see from the context, this file already has static
> inlines so I wasn't too bothered by it.
>
> -Denny
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]