From: Paolo Abeni <pabeni@redhat.com>
To: Qingfang Deng <dqfext@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-ppp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] ppp: don't byte-swap at run time
Date: Wed, 11 Feb 2026 12:25:22 +0100 [thread overview]
Message-ID: <8eeb1478-4dbd-4b03-b675-91df18c8d26b@redhat.com> (raw)
In-Reply-To: <20260207064705.208612-1-dqfext@gmail.com>
On 2/7/26 7:47 AM, Qingfang Deng wrote:
> @@ -312,7 +312,26 @@ static inline struct ppp_net *ppp_pernet(struct net *net)
> }
>
> /* Translates a PPP protocol number to a NP index (NP == network protocol) */
> -static inline int proto_to_npindex(int proto)
> +static __always_inline int proto_to_npindex(__be16 proto)
This has just 2 callers; does the compiler inline it anyway?!?
> +{
> + switch (proto) {
> + case htons(PPP_IP):
> + return NP_IP;
> + case htons(PPP_IPV6):
> + return NP_IPV6;
> + case htons(PPP_IPX):
> + return NP_IPX;
> + case htons(PPP_AT):
> + return NP_AT;
> + case htons(PPP_MPLS_UC):
> + return NP_MPLS_UC;
> + case htons(PPP_MPLS_MC):
> + return NP_MPLS_MC;
> + }
> + return -EINVAL;
> +}
> +
> +static __always_inline int proto_to_npindex_user(int proto)
This is slowpath and definitely does not need the inline annotation
> {
> switch (proto) {
> case PPP_IP:
> @@ -332,44 +351,44 @@ static inline int proto_to_npindex(int proto)
> }
>
> /* Translates an NP index into a PPP protocol number */
> -static const int npindex_to_proto[NUM_NP] = {
> - PPP_IP,
> - PPP_IPV6,
> - PPP_IPX,
> - PPP_AT,
> - PPP_MPLS_UC,
> - PPP_MPLS_MC,
> +static const __be16 npindex_to_proto[NUM_NP] = {
> + htons(PPP_IP),
> + htons(PPP_IPV6),
> + htons(PPP_IPX),
> + htons(PPP_AT),
> + htons(PPP_MPLS_UC),
> + htons(PPP_MPLS_MC),
> };
>
> /* Translates an ethertype into an NP index */
> -static inline int ethertype_to_npindex(int ethertype)
> +static inline int ethertype_to_npindex(__be16 ethertype)
This has a single caller, please drop the inline annotation.
I'm not sure the code churn is justified by the gain; please include
also actual perf figures in the commit message.
If you are willing to invest a significant amount of time in this area,
I suggest to implement first some self-tests and than reconsider the
locking schema: I suspect RCU usage could avoid some lock(s) in the
datapath.
/P
prev parent reply other threads:[~2026-02-11 11:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-07 6:47 [PATCH net-next] ppp: don't byte-swap at run time Qingfang Deng
2026-02-11 11:25 ` Paolo Abeni [this message]
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=8eeb1478-4dbd-4b03-b675-91df18c8d26b@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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