[RFC net-next v2 1/2] pppoe: pass bound packets directly to generic PPP

[Qingfang Deng <qingfang.deng@linux.dev>]

Bound PPPoE sockets pass received frames to the generic PPP layer. They
currently do so through __sk_receive_skb(), which takes the socket BH
lock and serializes calls to ppp_input().

The lock originally prevented ppp_input() from racing with
ppp_unregister_channel(). Commit ec4215683e47 ("ppp: defer channel free
to an RCU grace period to fix pppol2tp RX UAF") now keeps the generic
PPP channel alive until in-flight RCU readers have completed, so bound
packets can be passed directly to ppp_input() from pppoe_rcv().

The direct bound receive path also skips the socket filter check in
__sk_receive_skb(). This does not affect normal pppd PPPoE operation:
pppd uses the kernel PPP channel and does not attach a receive filter to
a socket. Instead, it uses the generic PPP pass and active filters,
installed through PPPIOCSPASS and PPPIOCSACTIVE, unaffected by this
change.

A local receive-path benchmark sends 1492-byte IPv4 packets through
multiqueue TAP -> PPPoE -> PPP in an x86-64 eight-vCPU QEMU KVM guest.
The generic PPP receive lock (ppp->rlock) is retained in both variants.
Median throughput over 12 samples per cell across four boots, expressed
as IP-layer Gbps:

  Senders  Before Gbps  After Gbps    Change
        1        25.85       26.71     +3.33%
        2        45.19       46.93     +3.86%
        4        84.14       88.36     +5.01%
        8        60.39       68.50    +13.43%

Repeating the test with a separate benchmark-only change that removes
the generic PPP receive lock:

  Senders  Before Gbps  After Gbps    Change
        1        26.35       26.58     +0.87%
        2        46.57       47.54     +2.07%
        4        87.04       91.47     +5.09%
        8        64.01      161.85   +152.86%

In these tests, eight senders perform worse than four in every
configuration with at least one receive lock remaining. Removing both
locks restores scaling: throughput increases from 91.47 Gbps with four
senders to 161.85 Gbps with eight senders.

Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
---
v2:
 - Split out the synchronize_net() change (already in net tree e7b01bc0202a)
 - Do not change the banner comment
 - Include the benchmark results

v1: https://lore.kernel.org/netdev/20260804074452.75548-1-qingfang.deng@linux.dev/

Sent as RFC, as net-next is not yet open and commit e7b01bc0202a is not
present in this tree.
---
 drivers/net/ppp/pppoe.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index 9edf8151bd7d..fbd04e7252b2 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -415,6 +415,10 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
 	if (!po)
 		goto drop;
 
+	if (likely(po->sk.sk_state & PPPOX_BOUND)) {
+		ppp_input(&po->chan, skb);
+		return NET_RX_SUCCESS;
+	}
 	return __sk_receive_skb(&po->sk, skb, 0, 1, false);
 
 drop:
-- 
2.43.0