Re: [RFC PATCH net-next v6 1/2] net: pppoe: implement GRO/GSO support

[Pablo Neira Ayuso]

Hi Paolo,

On Thu, Apr 30, 2026 at 11:47:57PM +0800, Qingfang Deng wrote:
> On Thu, Apr 30, 2026 at 5:34 PM Paolo Abeni <pabeni@xxxxxxxxxx> wrote:
> >
> > AFAICS, when the computed len is >= 64K, and the above min() will
> > truncate it, later pppoe_rcv() will drop the packet.
> 
> pppoe_rcv() does _not_ drop such packets.
> The drop condition is "skb->len < ntohs(ph->length)", not the other way around.
> 
> > > +     skb = segs;
> > > +     do {
> > > +             phdr = (struct pppoe_hdr *)(skb_mac_header(skb) + nhoff);
> > > +             len = skb->len - (nhoff + sizeof(*phdr));
> > > +             phdr->length = cpu_to_be16(len);
> > > +             skb->network_header = (u8 *)phdr - skb->head;
> >
> > I understand is quite late for the following question, but...
> > The network headers points to the pppoe hdr. Should it point to the
> > actual IP hdr?

This is the same with double-tagged-vlan, the network header also
points to the inner vlan in the skb payload. Changing this would
require to revisit all users in the tree that are already assuming
this.

> > Why not? A comment in the code or in the commit message would be
> > appreciated.
> 
> I'm not sure about the GSO stuff. This code is carried over from
> Felix's v3 patch unmodified and I haven't noticed any issues. Maybe he
> has the answer.
> 
> FYI, Pablo Neira Ayuso is adding the "inline PPPoE GSO" to Netfilter
> flowtable: https://lore.kernel.org/netfilter-devel/20260430055836.223494-2-pablo@xxxxxxxxxxxxx/
> to work around missing GSO support in PPPoE driver, prior to this
> patch.