Re: [PATCH v2 net-next 08/14] ipv6: Add hop-by-hop header to jumbograms in ip6_output

[David Ahern <dsahern@kernel.org>]

On 3/4/22 12:13 PM, Eric Dumazet wrote:
>> I am not saying we have to do this. I am simply stating a "what if"
>> just to gauge this approach. You could think of it as thinking out
>> loud, but in written form.

my point as well.

> 
> Understood.
> 
> BTW I spent time adding a new gso_type flag, but also gave up because we have
> no more room in features_t type.
> 
> Solving features_t exhaustion alone is a delicate topic.
> 
> 
>>
>>> For instance, input path will not like packets larger than 64KB.
>>>
>>> There is this thing trimming padding bytes, you probably do not want
>>> to mess with this.
>>
>> I had overlooked the fact that this is being used on the input path,
>> the trimming would be an issue. I suppose the fact that the LSOv2
>> didn't have an Rx counterpart would be one reason for us to not
>> consider the IPv4 approach.
>>

I'm aware of the trim on ingress; it can be properly handled. Drivers
(LRO) and the S/W GRO stack would know when it is exceeding the 64kB
length so the skb can be marked that is a large packet.

I am not trying to derail this set from getting merged. v6 has a
standard header for the large packet support, so certainly use it. That
said, it is always best in the long run for IPv4 and IPv6 to have
consistent feature support and implementation. Hence the asking about
alternative solutions that work for both.