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 > tcpdump shrank from 10s of KBs to the MTU, which indicates that Generic > Receive Offload (GRO) got disabled. > > Upon further investigation, we found the following line in > `inet_gro_receive`: > > if (*(u8 *)iph != 0x45) > goto out_unlock; > > in plain English, don't do GRO if any IPv4 options are present. > > 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 sense to do GRO when > the IPv4 options are byte-identical in consecutive packets?
I guess nobody really uses IPV4 options, and you are the first caring enough ;)
