Re: [RFC bpf-next v3 2/3] bpf: Add PPPoE encap/decap kfuncs

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue, Nov 10, 2026 at 07:21 PM ThisSeanZhang <thisseanzhang@gmail.com> wrote:
> Previously, a TC program could add or remove the header bytes
> manually, but the skb would keep a stale skb->protocol: forwarded GSO
> packets larger than the PPPoE MTU could not reach the PPPoE
> segmentation path registered for ETH_P_PPP_SES and could be dropped.
> bpf_skb_adjust_room() cannot be used for the decapsulation direction
> either, because it only accepts ETH_P_IP or ETH_P_IPV6 in
> skb->protocol.

Sorry, it is still a no go.
It works today without new kfuncs.

Encap: bpf_redirect() to the ppp device. It has no TSO, so
validate_xmit_skb() segments the GSO skb as plain IP.
pppoe_xmit() adds the header to every segment.

Decap: XDP removes the 8 bytes with bpf_xdp_adjust_head() before the skb
exists. The skb is plain IP and GRO handles it like any IP packet.

A prog that adds the header itself can update skb->protocol too.
__skb_vlan_pop() takes it from the packet. Not tested:

	bpf_skb_adjust_room(skb, 8, BPF_ADJ_ROOM_MAC, 0);
	/* write the PPPoE header and h_proto = ETH_P_PPP_SES */
	bpf_skb_vlan_push(skb, bpf_htons(ETH_P_8021Q), 0);
	bpf_skb_vlan_push(skb, bpf_htons(ETH_P_8021Q), 0);
	bpf_skb_vlan_pop(skb);
	bpf_skb_vlan_pop(skb);
	/* skb->protocol == ETH_P_PPP_SES */

I think you said earlier that it cannot. Prove me wrong.

pw-bot: cr