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

[Xin Long]

On Thu, Mar 26, 2026 at 9:49 PM Qingfang Deng <dqfext@xxxxxxxxx> wrote:
>
> Hi,
>
> On Thu, Mar 26, 2026 at 10:44 PM Xin Long <lucien.xin@xxxxxxxxx> wrote:
> >
> > On Thu, Mar 26, 2026 at 10:43 AM Xin Long <lucien.xin@xxxxxxxxx> wrote:
> > >
> > > On Wed, Mar 25, 2026 at 10:43 PM Qingfang Deng <dqfext@xxxxxxxxx> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > In some cases (such as BIG TCP) a GRO skb length can overflow a u16,
> > > > then what should I do with the u16 length field here?
> > >
> > > I think you can either add a check in pppoe_gro_complete() to ensure
> > sorry, I meant add a check in pppoe_gro_receive().
> > > the aggregated size does not exceed U16_MAX, avoiding BIG TCP
> > > behavior; Or, set phdr->length to 0 and rely on skb->len to determine
> > > the actual length, as done in BIG TCP itself.
>
> 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)?

Thanks.