Re: [PATCH net-next v5] net: pppoe: implement GRO/GSO support
Xin Long <[email protected]> Fri, 27 Mar 2026 09:23:00 -0400
| Newsgroups | gmane.linux.network,gmane.linux.ppp,gmane.linux.kernel |
|---|---|
| Message-ID | <CADvbK_fug3vckLkfufLTtqTEKzywRUw8C_dzfW032_cb6vLpZg@mail.gmail.com> |
On Thu, Mar 26, 2026 at 9:49 PM Qingfang Deng <[email protected]> wrote: > > Hi, > > On Thu, Mar 26, 2026 at 10:44 PM Xin Long <[email protected]> wrote: > > > > On Thu, Mar 26, 2026 at 10:43 AM Xin Long <[email protected]> wrote: > > > > > > On Wed, Mar 25, 2026 at 10:43 PM Qingfang Deng <[email protected]> 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/[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)? Thanks.