[PATCH net-next v4 2/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

2017-03-22 Thread R. Parameswaran
Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon or operator. If an MTU is not specified, the existing kernel code chooses an MTU that does not take account of all tunnel header overheads, which can lead to

Re: [PATCH net-next v4 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

2017-03-20 Thread R. Parameswaran
Hi James, Please see inline: On Mon, 20 Mar 2017, James Chapman wrote: > I suggest change the wording of the first paragraph in the patch comment > to better represent why the changes are being made. Perhaps something > like the following? > > "Existing L2TP kernel code does not derive the

Re: [PATCH net-next v4 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

2017-03-20 Thread James Chapman
I suggest change the wording of the first paragraph in the patch comment to better represent why the changes are being made. Perhaps something like the following? "Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon

[PATCH net-next v4 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

2017-03-17 Thread R. Parameswaran
In existing kernel code, when setting up the L2TP interface, all of the tunnel encapsulation headers are not taken into account when setting up the MTU on the L2TP logical interface device. Due to this, the packets created by the applications on top of the L2TP layer are larger than they ought