On Mon, May 9, 2016 at 4:10 PM, Alexander Duyck <alexander.du...@gmail.com> wrote: > On Mon, May 9, 2016 at 3:49 PM, Tom Herbert <t...@herbertland.com> wrote: >> On Mon, May 9, 2016 at 3:44 PM, Alexander Duyck >> <alexander.du...@gmail.com> wrote: >>> On Mon, May 9, 2016 at 3:28 PM, Tom Herbert <t...@herbertland.com> wrote: >>>> In ip6gre_tnl_link_config set t->tun_len and t->hlen correctly for the >>>> configuration. For hard_header_len and mtu calculation include >>>> IPv6 header and encapsulation overhead. >>>> >>>> In ip6gre_tunnel_init_common set t->tun_len and t->hlen correctly for >>>> the configuration. Revert to setting hard_header_len instead of >>>> needed_headroom. >>>> >>>> Tested: >>>> >>>> ./ip link add name tun8 type ip6gretap remote \ >>>> 2401:db00:20:911a:face:0:27:0 local \ >>>> 2401:db00:20:911a:face:0:25:0 ttl 225 >>>> >>>> Gives MTU of 1434. That is equal to 1500 - 40 - 14 - 4 - 8. >>>> >>>> ./ip link add name tun8 type ip6gretap remote \ >>>> 2401:db00:20:911a:face:0:27:0 local \ >>>> 2401:db00:20:911a:face:0:25:0 ttl 225 okey 123 >>>> >>>> Gives MTU of 1430. That is equal to 1500 - 40 - 14 - 4 - 8 - 4. >>>> >>>> Signed-off-by: Tom Herbert <t...@herbertland.com> >>> >>> So this gives me the correct result now. However we still need patch >>> 3 / 11 from the set you submitted next week in order to be able to >>> even transmit because the flags are otherwise mangled. >>> >>> Tested-by: Alexander Duyck <adu...@mirantis.com> >> >> Okay, I'll repost the flags patch as a standalone. Do you have any >> other issues then in this path? > > This piece no. > > Like I said in the other email I did find two other issues. First in > __gre6_xmit I think you want to set the inner protocol to "protocol", > not "proto". Second is the issue with ip6_tnl_xmit stomping on > skb->transport_header. The second one is the big one that is blocking > things badly right now. That is the one that keeps me from doing > anything with any sort of offload as the headers are jumping around > out of order with the outer transport header having an offset that is > further in than the inner mac header. > You mean "skb->transport_header = skb->network_header;"? It doesn't look right to me either, but that line has been around a while....
> I'd be fine with you submitting the whole set as one piece with the > other 11 patches you had just as long as we get those core pieces > fixed in the patch set. > Probably just as easy to break it up. > - Alex
