Re: [OpenWrt-Devel] 18.06: Cherry pick mtu fix
21.06.2018 21:18, Jaap Buurman: Dear Kevin, Some very good points you are giving. Is there anyone able and willing to cherry-pick these 3 commits to the 18.06 branch before the RC1 release is tagged tomorrow? At least I'll not do so. I would like to see this change a bit more tested in master. The code is shared between all mediatek mips SoCs and might cause regressions for the other SoCs. Considering that it took near to two months for the first public report of the mtu regression after making k4.14 the default, I don't feel comfortable to assume that five days in master are enough for testing. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 18.06: Cherry pick mtu fix
Dear Kevin, Some very good points you are giving. Is there anyone able and willing to cherry-pick these 3 commits to the 18.06 branch before the RC1 release is tagged tomorrow? Yours sincerely, Jaap Buurman On Thu, Jun 21, 2018 at 10:27 AM Kevin Darbyshire-Bryant wrote: > > > > > On 21 Jun 2018, at 08:13, Jaap Buurman wrote: > > > > Dear all, > > > > The move to kernel 4.14 broke mtu settings larger than 1500 by > > default, unless the correct mtu was explicitly specified. The > > following commit fixes this for the mt7621 target: > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5da2c68d001ee44b15a58639ed03a0ebb6f68020 > > > > 1) Would it be possible for someone to cherry-pick this to the 18.06 > > branch, so that it can receive widespread testing in the upcoming > > 18.06 RC1 release? > > Personally I’d also pick the preceding mtk driver commit "ec502cd3fe ramips: > rename ethernet driver folder to the same one that upstream uses” for clarity > & easier cherry-picks going forward for 18.06. And I’d be very strongly > tempted to have 9a4253b81f ramips: improve ethernet driver performance with > GRO/TSO as well…. which gets 18.06 into the same state as master for mtk eth > drivers. > > > 2) From the commit's message I get the impression this isn't an issue > > with just mt7621, but with all targets that are able to handle a mtu > > > 1500. Is my impression correct in this regard, and is this something > > that should be fixed before a 18.06 release? Changing mtu settings > > > 1500 does sound like basic functionality for routers nowadays. > > It is dependent upon the driver setting a suitable max_mtu in the netdev > structure *IF* it supports values greater than 1500. > > + if (IS_ENABLED(CONFIG_SOC_MT7621)) > + netdev->max_mtu = 2048; > > The version of driver included with kernel 4.14 at present is too dumb to > understand >1500 mtu, which is why openwrt replaces it with a version that > (now) does. > > That’s my opinion anyway :-) > > Kevin > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 18.06: Cherry pick mtu fix
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On 21 Jun 2018, at 08:13, Jaap Buurman wrote: > > Dear all, > > The move to kernel 4.14 broke mtu settings larger than 1500 by > default, unless the correct mtu was explicitly specified. The > following commit fixes this for the mt7621 target: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5da2c68d001ee44b15a58639ed03a0ebb6f68020 > > 1) Would it be possible for someone to cherry-pick this to the 18.06 > branch, so that it can receive widespread testing in the upcoming > 18.06 RC1 release? Personally I’d also pick the preceding mtk driver commit "ec502cd3fe ramips: rename ethernet driver folder to the same one that upstream uses” for clarity & easier cherry-picks going forward for 18.06. And I’d be very strongly tempted to have 9a4253b81f ramips: improve ethernet driver performance with GRO/TSO as well…. which gets 18.06 into the same state as master for mtk eth drivers. > 2) From the commit's message I get the impression this isn't an issue > with just mt7621, but with all targets that are able to handle a mtu > > 1500. Is my impression correct in this regard, and is this something > that should be fixed before a 18.06 release? Changing mtu settings > > 1500 does sound like basic functionality for routers nowadays. It is dependent upon the driver setting a suitable max_mtu in the netdev structure *IF* it supports values greater than 1500. + if (IS_ENABLED(CONFIG_SOC_MT7621)) + netdev->max_mtu = 2048; The version of driver included with kernel 4.14 at present is too dumb to understand >1500 mtu, which is why openwrt replaces it with a version that (now) does. That’s my opinion anyway :-) Kevin signature.asc Description: Message signed with OpenPGP --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
