Re: [PATCH net-next v5] net: pppoe: implement GRO/GSO support

Hi, Xin Long,

On Fri, Mar 27, 2026 at 9:23 PM Xin Long <[email protected]> wrote:
>
> On Thu, Mar 26, 2026 at 9:49 PM Qingfang Deng <[email protected]> wrote:
> >
> > In my v6 patch, I set phdr->length to 0xFFFF. Is that okay?
> >
> > https://lore.kernel.org/netdev/[email protected]/
>
> I think you need to check how the PPPoE stack handles this value. If
> it recalculates the actual length using skb->len when phdr->length ==
> 0xFFFF, then this approach might be fine.
>
> Also, how does the PPPoE stack distinguish between 0xFFFF being the
> actual payload length versus it being used as a marker to indicate a
> jumbo packet (similar to BIG TCP)?

In the receive function 'pppoe_rcv()': if a skb's actual payload
length is less than phdr->length, it will be dropped; if greater than
phdr->length, it will be trimmed to match phdr->length. After that,
the phdr is popped and the skb is passed to the generic PPP layer.
There is also a fastpath in Netfilter flowtable for IPv4/IPv6 that
bypasses pppoe_rcv(): it does not check phdr->length at all, and only
relies on the length field in the network header.

In the v2 version of this patch, phdr->length is not updated in
gro_complete(), so an additional check 'skb_is_gso()' is added to the
function to avoid trimming a GRO skb. Then Richard Gobert suggested
that the length field needs to be updated, and if the updated field
matches the actual length, the 'skb_is_gso()' is not necessary, but
only if the length fits in the u16 field.