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

[Xin Long]

On Fri, Mar 27, 2026 at 10:43 AM Qingfang Deng <dqfext@xxxxxxxxx> wrote:
>
> Hi, Xin Long,
>
> On Fri, Mar 27, 2026 at 9:23 PM Xin Long <lucien.xin@xxxxxxxxx> wrote:
> >
> > On Thu, Mar 26, 2026 at 9:49 PM Qingfang Deng <dqfext@xxxxxxxxx> wrote:
> > >
> > > In my v6 patch, I set phdr->length to 0xFFFF. Is that okay?
> > >
> > > https://lore.kernel.org/netdev/20260326081127.61229-1-dqfext@xxxxxxxxx/
> >
> > 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.
I guess you have to look back to pppoe_rcv() for this, and double check
with Richard Gobert.

The phdr->length trick for jumbo packets might also affect how tcpdump
or tshark parses PPPoE packets.