netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Alexandre Ferrieux <alexandre.ferrieux@gmail.com>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	Pedro Tammela <pctammela@mojatatu.com>,
	edumazet@google.com, jhs@mojatatu.com, xiyou.wangcong@gmail.com,
	jiri@resnulli.us, netdev@vger.kernel.org
Subject: Re: [PATCH net] Fix u32's systematic failure to free IDR entries for hnodes.
Date: Mon, 11 Nov 2024 20:07:59 +0000	[thread overview]
Message-ID: <20241111200759.GM4507@kernel.org> (raw)
In-Reply-To: <9662e6fe-cc91-4258-aba1-ab5b016a041a@orange.com>

On Sun, Nov 10, 2024 at 04:40:26PM +0100, Alexandre Ferrieux wrote:
> On 10/11/2024 15:00, Simon Horman wrote:
> > On Mon, Nov 04, 2024 at 10:51:01PM +0100, Alexandre Ferrieux wrote:
> >> 
> >> I believe you mean "let the compiler decide whether to _inline_ it or not".
> >> Sure, with a sufficiently modern Gcc this will do. However, what about more
> >> exotic environments ? Wouldn't it risk a perf regression for style reasons ?
> >> 
> >> And speaking of style, what about the dozens of instances of "static inline" in
> >> net/sched/*.c alone ? Why is it a concern suddenly ?
> > 
> > Hi Alexandre,
> > 
> > It's not suddenly a concern. It is a long standing style guideline for
> > Networking code, even if not always followed. Possibly some of the code
> > you have found in net/sched/*.c is even longer standing than the
> > guideline.
> > 
> > Please don't add new instances of inline to .c files unless there is a
> > demonstrable - usually performance - reason to do so.
> 
> Sure, I will abide in the next version :)
> 
> That said, please note it is hard to understand why such a rule would be
> enforced both locally and tacitly. Things would be entirely different if it were
> listed in coding-style.rst, advertising both consensus and wide applicability.

Thanks,

I completely agree that it would be better if it was documented somewhere.
I will add that to my TODO list.

  reply	other threads:[~2024-11-11 20:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 10:26 [PATCH net] Fix u32's systematic failure to free IDR entries for hnodes Alexandre Ferrieux
2024-11-04 17:00 ` Pedro Tammela
2024-11-04 20:26   ` Alexandre Ferrieux
2024-11-04 21:33     ` Vadim Fedorenko
2024-11-04 21:51       ` Alexandre Ferrieux
2024-11-04 22:33         ` Florian Fainelli
2024-11-05 22:14         ` Alexandre Ferrieux
2024-11-05 23:42           ` Vadim Fedorenko
2024-11-06 10:15             ` Alexandre Ferrieux
2024-11-06 10:54               ` Vadim Fedorenko
2024-11-10 14:00         ` Simon Horman
2024-11-10 15:40           ` Alexandre Ferrieux
2024-11-11 20:07             ` Simon Horman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-11-01 18:43 Alexandre Ferrieux
2024-11-04 10:11 ` Eric Dumazet

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=20241111200759.GM4507@kernel.org \
    --to=horms@kernel.org \
    --cc=alexandre.ferrieux@gmail.com \
    --cc=edumazet@google.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=pctammela@mojatatu.com \
    --cc=vadim.fedorenko@linux.dev \
    --cc=xiyou.wangcong@gmail.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;
as well as URLs for NNTP newsgroup(s).