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.
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.