Re: [RFC PATCH net-next v6 1/2] net: pppoe: implement GRO/GSO support
Pablo Neira Ayuso <[email protected]> Thu, 30 Apr 2026 17:57:50 +0200
| Newsgroups | org.kernel.vger.linux-ppp,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <afN7_oBICMZ_45Zh@chamomile> |
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 <[email protected]> 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/[email protected]/ > to work around missing GSO support in PPPoE driver, prior to this > patch.