From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAA492F7AD2 for ; Wed, 11 Feb 2026 11:25:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770809129; cv=none; b=Mq3qqmaH4FZ6KjoRAf+6IQO+VunNavKi9WvOElKJYkCNrqZpwrDglLScxN8kanbEatkydERF+gwIB4CyzEIR14+fn1PDQS1Wh32zRZOKGlTLAHb4GvrDbs8TMNc0uroeYPVPVeZPOeLpwXF7nihZtk1yXRqDg5vAu17T3YOyd1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770809129; c=relaxed/simple; bh=7d+AXoxTsWN4BbyRET87gH+U/G1P7Vts/X3P1qNoGQk=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=NDpD9k6Eaz63P5UTApv4ZQsUuIlgVKIrX4U+FDDnds8Gc4NAuofvMRjaq3iY3HHJUkHbfg5NxIvINXmaDJz2VonVFEl6c0BRrDcbOHcjW6K4kAgedWrtxbdiv0FdbbjnNSk1/rOO4+dYLQJKI+UDyxzzCLZeMrGumEcEsHT0CO0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=G+G+MI1T; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=fSZZX6cJ; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="G+G+MI1T"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="fSZZX6cJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770809127; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8I9uY7De/Owfo1cyJYQXzE51IMCqg83AFJdtL17VQAQ=; b=G+G+MI1TolSFZ7YfYbkie0WolHRcO0Xf83+kZMLwjdyER3dgWhiddJYbtefbYrEDkUVz2L VqSsWpJUMQW2OT9VBseiGDzoxs5mziCd92yNJJzsPk+cyVa5GXKc/DCo16MytVd03aRHXT Umg+MDfuGb9gGZz6dlt6ZfIONVhiZCo= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-115-xNhgZIDxMNmssQpQn2up2w-1; Wed, 11 Feb 2026 06:25:25 -0500 X-MC-Unique: xNhgZIDxMNmssQpQn2up2w-1 X-Mimecast-MFC-AGG-ID: xNhgZIDxMNmssQpQn2up2w_1770809125 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-4362197d1easo1485681f8f.2 for ; Wed, 11 Feb 2026 03:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770809124; x=1771413924; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=8I9uY7De/Owfo1cyJYQXzE51IMCqg83AFJdtL17VQAQ=; b=fSZZX6cJ7JIzrWt6+UvNr2aeA8xSWUad/vWof4Th/4NYVHHOBSAn9THhIz9Nn4n5Yx pQF5JrCp0aIurMgx/JAWqh733u5IrDz3jMoltO8t7pOgPYLW6xS7oADvXXH515ppIWwu gjJ+DnOwGyiln9FyCLtWqgceiFGIc6Nv2c3DRaaeNG54AM1pmPfKm/zVfCB5lSebenUd pCbyIeMx/iQBg1Ogou6J5jv54t3N6dZEx7ZjOricj2u2/l/i57WSO0OWTvyR6lRwdYBt ddQyM6099bMOE2KCTk+XDQ1PMPBk8tGj3BYKP7sYFVJN4TyaGsblAEId/xWqzxPAURPR oMzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770809124; x=1771413924; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8I9uY7De/Owfo1cyJYQXzE51IMCqg83AFJdtL17VQAQ=; b=CkwRzASbNNfmAz8HqMWyB0GUCU3R1Ixo4wrFAXTpUKDvoPWrMRQKNb2fPi4pTS2MTp c4kq+hC276iUknygNiCN5shoeDvCN4RAML3jl4OUTp6ovYzNckNSJb0HGYCMWKisL/9h RLDgxxKQjCpO2iZYvYXHVsnZE2sSma/TNrKuYdO+2Dtr3GCZe35KdEd/bOBL/M64Nggv CB5fmzambOcyaOa9OQunxNVYpqh5Yg4tAYfQJb3u2w4dc7tKgN7gNhuCXaurb/c/Oi5j Hm7Wr7DTZqSdpJu0glSR30wyWcJmbRSmhSR6SOpizHKlFlPmy08yDRMSq2mDKDv7VYsE kRBg== X-Forwarded-Encrypted: i=1; AJvYcCXh2P/S3a8GMDcNgkt84nJZWZd9ZYyaQdEZzjNLTRiNLSbq2JKk6U1/HxcxFbjjoEniZhK+zchplHzUXaQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyoM6gbmlmYuv1LXXaxadoy5LwPR3BYiM72WzXCNwUq+LbDvXR5 lAHqAClrI51cAknJ7rQY4db/ukexKvl66pAuUGXxkCsfBfqhnsY9dPtTI/41UVrC5JUnpQBj9MN r4LYABP1reMTtEhF9vyYpcrI5RXjyJcnQ/GTO+aPb1hQs6JSmOlJUfoxQwMSTXjPWkg== X-Gm-Gg: AZuq6aL8ylfUi1H7t5K/gP6vX5divolquyFijr5ozxDroadONPMXwO7ob3KZ5k+SgW6 4V++KoNY0d4HF8TeUzFQRPuKr8DPeoGFKFDAqMpRuNCKpzGKHk6/3Zg5CNAig7Ectr/vl/NrELM 6XyLqYJu+vHypHXmm0vy2h1KZxqOdtGO7RCzBj6Z7jevfV9cZY7aXEEXxtWJYWllljGKqpMSoFh mam7luh+AZ2oSDZR24dPzNQ29Rs4LGZaLz87sY3tI56ZZMJGfKvDq+GxN8FhNmhSvAOmuFCngyq UxbGWgCgRnvuJwBwMIdeS2V7AwWBLwoB/oodsC8Bd61CT9VzxeJ8qz5sZU0veNbL2lOzYcNZqNc +ZqfcxvNs5AgVEH4rKbyE+ZnywQ== X-Received: by 2002:a5d:604d:0:b0:436:3563:499b with SMTP id ffacd0b85a97d-43635634b2cmr15873140f8f.2.1770809124572; Wed, 11 Feb 2026 03:25:24 -0800 (PST) X-Received: by 2002:a5d:604d:0:b0:436:3563:499b with SMTP id ffacd0b85a97d-43635634b2cmr15873097f8f.2.1770809124074; Wed, 11 Feb 2026 03:25:24 -0800 (PST) Received: from [192.168.88.32] ([212.105.155.220]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43783dfc55dsm4109270f8f.20.2026.02.11.03.25.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Feb 2026 03:25:23 -0800 (PST) Message-ID: <8eeb1478-4dbd-4b03-b675-91df18c8d26b@redhat.com> Date: Wed, 11 Feb 2026 12:25:22 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next] ppp: don't byte-swap at run time To: Qingfang Deng , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , linux-ppp@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260207064705.208612-1-dqfext@gmail.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20260207064705.208612-1-dqfext@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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