From: Willem de Bruijn
Date: Fri, 17 Nov 2017 08:51:57 -0500
> ipv6_gro_receive already pulls common ones with ipv6_gso_pull_exthdrs.
> And to add a counterpoint: GRO has to be resilient to malformed packets,
> so there is value in keeping it simple and limited to the common case.
Agreed.
Also
On Thu, Nov 16, 2017 at 5:47 PM, Tom Herbert wrote:
> On Thu, Nov 16, 2017 at 1:40 PM, Herbert Xu
> wrote:
>> On Thu, Nov 16, 2017 at 04:12:43PM +0100, Cristian Klein wrote:
>>>
>>> Does somebody know the rationale for this? Is it because IPv4
>>> options are rarely used, hence implementing GRO
On Thu, Nov 16, 2017 at 1:40 PM, Herbert Xu wrote:
> On Thu, Nov 16, 2017 at 04:12:43PM +0100, Cristian Klein wrote:
>>
>> Does somebody know the rationale for this? Is it because IPv4
>> options are rarely used, hence implementing GRO in that case does
>> not pay off or are there some caveats? Sp
On Thu, 2017-11-16 at 16:12 +0100, Cristian Klein wrote:
> [CC-ing Herbert Xu, who is to 'git blame' for the code in question. :)]
>
> Dear all,
>
> We are working on a research prototype which, among others, adds a new
> IPv4 option. During testing we noticed that the packets captured by
> tcp
On Thu, Nov 16, 2017 at 04:12:43PM +0100, Cristian Klein wrote:
>
> Does somebody know the rationale for this? Is it because IPv4
> options are rarely used, hence implementing GRO in that case does
> not pay off or are there some caveats? Specifically would it make
Precisely. GRO is about optimis
[CC-ing Herbert Xu, who is to 'git blame' for the code in question. :)]
Dear all,
We are working on a research prototype which, among others, adds a new
IPv4 option. During testing we noticed that the packets captured by
tcpdump shrank from 10s of KBs to the MTU, which indicates that Generic
