On 09.07.2016 05:00, Florian Westphal wrote: > I am worried about this patch, skb_gso_validate_mtu is more costly than > the ->flags & FORWARD check; everyone pays this extra cost. > > What about setting IPCB FORWARD flag in iptunnel_xmit if > skb->skb_iif != 0... instead?
That came to my mind first, too. > Yet another possibility would be to reduce gso_size but that violates > gro/gso symmetry... If you see vxlan (or any other UDP encap protocol) as an in-kernel tunnel solution/program acting as an end point it is actually legal to modify gso_size in my opinion. Adding headers to an skb can also not be symmetric in this case. I would not see anything bad happening because of doing so. Do you? It is a matter of implementation. vxlan could also eat all data and splice it anew onto a socket. It already doesn't care about end-to-end pmtu consistency, so I can't see anything wrong with it. To make this all safe one needs to handle the ttl in vxlan much better. It needs to be inherited from the inner header, checked and properly decremented on the outer header, so that vxlan itself acts as a full blown router by itself. Otherwise endless loops are possible, as the packet will always fit the size. Bye, Hannes
