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

On 4/30/26 5:57 PM, Pablo Neira Ayuso wrote:
> 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.

Ah right, the relevant GRO stage is running on top of an ethernet device
and the RX path there resets the NH just after the ethernet one.

I got lost in the relevant hooking.

This patch (and v7) LGTM, thanks.

Paolo