On 12 Oct 2026, at 14:36, Aaron Conole wrote:
> Eelco Chaudron <[email protected]> writes:
>
>> On 8 Oct 2026, at 15:00, Eli Britstein via dev wrote:
>>
>>> On 06/10/2026 17:30, Eelco Chaudron wrote:
>>>> The OVS coding style requires that static inline functions defined
>>>> in .c files also be decorated with ALWAYS_INLINE. Several functions
>>>> in dpif-netdev.c and dpif-netdev-dpcls.c were missing this attribute.
>>>> Add it to every occurrence for consistency and to avoid checkpatch
>>>> warnings in later patches.
>>>
>>> Instead of forcing keeping inline by this attribute, won't it just be
>>> cleaner to remove the 'inline'?
>>
>> I included this patch, as checkpatch was complaining about the
>> new (and existing) inlines. The new one I could have added
>> without the inline keyword. I'm not comfortable removing the
>> existing entries as we have no easy way to verify the impact of
>> removing this from these files.
>>
>> Aaron, any feedback about this?
>
> Modern optimizing compilers (like gcc and clang) treat the 'inline'
> keyword as a hint - from a performance perspective. The decision to
> inline or not still sits at the level of the optimizer's call-site
> context and heuristics analysis. GCC explicitly documents this:
> https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Inline-Function-Definitions.html
>
> Just because a call can be inlined does not mean it should be
> inlined. The GNU C compiler weighs costs and benefits to decide
> whether inlining a particular call is advantageous.
>
> So it may be better to say that the previous versions are merely hinting
> that the function could be inlined - the decision is (and was) part of
> the compiler. In fact, I think it's equally likely that ALWAYS_INLINE
> can cause a performance regression rather than an improvement -
> ALWAYS_INLINE tells the compiler to ignore this cost-benefit analysis
> and just throw the code inline. The only way to know for sure would be
> to try and benchmark these calls (and I'm not sure the best way to do
> that currently - anything we did would be synthetic). We should be very
> careful about changing that hint to a forced switch. I'd be more in
> favor of dropping the 'inline' keyword usage on these static functions
> in the C file, than adding 'ALWAYS_INLINE' to their attribute list.
> That has us keep to the OVS coding convention without hampering the
> compilers ability to choose to inline the functions that it deems good
> candidates for such optimization.
Thanks Aaron for the quick response. I will remove this patch from the series!
//Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
