On Tue, Jan 16, 2018 at 06:27:23AM +0000, James Page wrote: > On Mon, 15 Jan 2018 at 18:55 Christian Ehrhardt < > christian.ehrha...@canonical.com> wrote: > > > On Mon, Jan 15, 2018 at 5:43 PM, Eric Garver <e...@erig.me> wrote: > > > On Mon, Jan 15, 2018 at 11:32:32AM -0500, Eric Garver wrote: > > >> On Mon, Jan 15, 2018 at 03:17:28PM +0000, James Page wrote: > > >> > Hi Eric > > >> > > > >> > On Mon, 15 Jan 2018 at 16:54 Eric Garver <e...@erig.me> wrote: > > >> > > > >> > > On Sat, Jan 13, 2018 at 03:57:08PM +0000, James Page wrote: > > >> > > > Hi Ben s > > >> > > > > > >> > > > On Sat, 13 Jan 2018 at 14:55 James Page <james.p...@ubuntu.com> > > wrote: > > >> > > > > > >> > > > > OK, I sent a patch: > > >> > > > >> https://patchwork.ozlabs.org/patch/860192/ > > >> > > > > > > >> > > > > > > >> > > > > Thanks Ben - I'll pull this patch into the Ubuntu packages and > > test > > >> > > this > > >> > > > > weekend. > > >> > > > > > > >> > > > > > >> > > > I pulled your patch in ontop of our current 2.8.1 packages and > > >> > > re-tested; > > >> > > > I'm not seeing a difference in behaviour with the patch in place. > > I > > >> > > removed > > >> > > > the vport_gre and ip_gre kernel modules to force a re-creation of > > the > > >> > > > device on restart of OVS as well as trying a reboot of the test > > machine: > > >> > > > > > >> > > > 7: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode > > DEFAULT group > > >> > > > default qlen 1 > > >> > > > link/gre 0.0.0.0 brd 0.0.0.0 > > >> > > > 8: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state > > DOWN > > >> > > mode > > >> > > > DEFAULT group default qlen 1000 > > >> > > > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff > > >> > > > 9: gre_sys@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc > > >> > > > pfifo_fast master ovs-system state UNKNOWN mode DEFAULT group > > default > > >> > > qlen > > >> > > > 1000 > > >> > > > link/ether 52:ad:6d:89:bb:54 brd ff:ff:ff:ff:ff:ff > > >> > > > > >> > > Are there any errors is dmesg? It's possible setlink won't accept > > >> > > UINT16_MAX. grep for "Invalid MTU". > > >> > > > > >> > > > >> > Not under 4.4 but I do under 4.13: > > >> > > > >> > [ 6.794079] gre: GRE over IPv4 demultiplexor driver > > >> > [ 6.797621] ip_gre: GRE over IPv4 tunneling driver > > >> > [ 6.798326] gre_sys: Invalid MTU 65535 requested, hw max 1500 > > >> > > > >> > Looks like the kernel is limiting to 1500. > > >> > > >> I would expect setting with ip-link to fail as well. > > >> What does the below show?: > > >> > > >> $ ip link set dev gre_sys mtu 65535 > > > > > > Ugh. This is a separate kernel bug fixed by this commit: > > > > > > commit cfddd4c33c254954927942599d299b3865743146 <(386)%20574-3146> > > > Author: Xin Long <lucien....@gmail.com> > > > Date: Mon Dec 18 14:24:35 2017 +0800 > > > > > > ip_gre: remove the incorrect mtu limit for ipgre tap > > > > Thanks Eric, that matches my findings, glad that there seems to be an > > accepted fix already. > > But it is fairly recent and only in since 4.15-rc8 levels afaik. > > > > But OTOH its description at [1] reads pretty much like my notes so far. > > > > @James - do you think you could test a super-recent mainline kernel > > build from [2] in regard to this issue? > > > > Thanks all > > Re-tested with the mainline kernel; gre_sys device is still configured with > a 1472 MTU, however I was then able to increase it using ip link set > gre_sys mtu XXXX, confirming that the kernel applied hardware limit was not > longer being enforced - however looks like the IFLA_MTU settings provided > from OVS are still being ignored by the kernel.
What was the value of XXXX? Did you try 66535 (what OVS uses)? Any dmesg for the OVS case? _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
