Optimized build for the D-Link DIR-860L

Bartvz · April 10, 2017, 7:32am

@Gix: Very interesting. I have used sfstudio's Ralink SDK builds on the D-Link Dir-615 before and performance on those was great. Only downside is the 3.10 kernel. We still use 4.4 but some people are working on 4.9. When I have the time, I will give it a shot (or two).

@Mushoz: the Edgerouter X, indeed, uses the same chipset, MT7621AT. However browsing through the MT7621 datasheet doesn't reveal anything regarding jumbo frames. BUT, if the ER-X supports jumbo frames, so the Dir-860L should to.

Mushoz · April 10, 2017, 9:01am

But the problem is that it currently doesn't. Does the change mentioned above look good to you? If so, I will try compiling a build with that patch and see if I can get it to work.

Bartvz · April 10, 2017, 9:20am

I, also, am not a C programmer but you can always try. Reminds me of hacking the rtl8814AU to enable certain VHT flags. Is there source available for the ER-X? Otherwise that might be a good place to start looking how to implement jumbo frames.

@Mushoz, Ubiquiti uses a modified version of OpenWRT as their firmware. That is why I said that. You can download the latest version of their firmware here: https://dl.ubnt.com/firmwares/edgemax/v1.9.1/GPL.ER-e50.v1.9.1.4939092.tar.bz2
Time to poke around!

Mushoz · April 10, 2017, 7:49pm

Thank you very much for the link. Time to poke around indeed. Will let you know if I run into anything interesting. But don't hold your breath, I am no C programmer. My C skills are very rusty ^^

craz · April 11, 2017, 7:55am

Hi, the right url is without double //
https://dl.ubnt.com//firmwares/edgemax/v1.9.1/GPL.ER-e50.v1.9.1.4939092.tar.bz2

Mushoz · April 11, 2017, 5:09pm

I did not manage to find the MTU implementation in that source code. However, I did find the changelog of the 1.8.0 release, which states:

[Interface] Allow setting MTU up to 2018 bytes on the ER-X and ER-X-SFP.

source: https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-release-v1-8-0/ba-p/1490756

So my next attempt is going to be to download the 1.8.0 source and the 1.7.0 source and see if I can find anything by diffing them. Hopefully I will be able to find the code where the larger MTU is implemented.

Bartvz · April 12, 2017, 1:13pm

Thanks, I've edited it!

Bartvz · April 12, 2017, 1:26pm

I also couldn't find it.
However, it is probably located at "/kernel/drivers/net/raeth/" or at "/kernel/net/at/hw_nat/" with the first one being more likely.

Mushoz · April 12, 2017, 4:01pm

@Bartvz The file /kernel/drivers/net/raeth/raether.c contains the following interesting part:

/*

Set new MTU size

Change the mtu of Raeth Ethernet Device
*/
static int ei_change_mtu(struct net_device *dev, int new_mtu)
{
END_DEVICE *ei_local = netdev_priv(dev); // get priv ei_local pointer from net_dev structure

if ( ei_local == NULL ) {
printk(KERN_EMERG "%s: ei_change_mtu passed a non-existent private pointer from net_dev!\n", dev->name);
return -ENXIO;
}

if ( (new_mtu > 4096) || (new_mtu < 64)) {
return -EINVAL;
}

#if 1
if ( new_mtu > 2018 ) {
return -EINVAL;
}
#else
#ifndef CONFIG_RAETH_JUMBOFRAME
if ( new_mtu > 1500 ) {
return -EINVAL;
}
#endif
#endif
dev->mtu = new_mtu;
return 0;
}

Notice the very interesting #if 1 part, which makes sure that this function always compares the mtu that is being set to 2018, the exact value that the firmware changelog mentions. Now let's see if I can find out how this all is working and then see if this can be ported to LEDE.

Edit: The 1.7.0 firmware has the following code in the exact same location. Please note that the previous MTU limit was 1510 for this device:

Bartvz · April 12, 2017, 5:41pm

To my n00b eyes, this looks to simple. However, sometimes things can be simple.
Now we know it is part of their raeth driver but how to implement this in LEDE's mt76 driver?
After some digging, I found the following ftp server with a boatload of technical docs for our chipset which might help: http://ftp.mqmaker.com/WiTi/Docs/Software/

Mushoz · April 13, 2017, 7:10am

I think I managed to find how to implement this in LEDE. I am currently on a business trip with limited internet and time, so I won't be able to test my suspicion until Friday evening or Saturday morning. But I will keep you posted. Just don't expect too much. As I mentioned before, my C is very rusty, so me failing miserably wouldn't surprise me

Mushoz · April 14, 2017, 4:51pm

Wow, I actually managed to get it working As you can see in the screenshot below, the MTU is successfully set to the desired 1508 on the eth0 interface. This allowed me to set a MTU of 1500 on the PPPoE interface, which connects to my ISP:

To make sure it is not just a visual change, but that the actual change is working, I tried to ping Google's DNS with a packet size of 1472 with the do not fragment bit set, which should only work if my PPPoE interface is truly at 1500, and thus my eth0 interface truly at 1508:

Hooray! Succes! My current implementation is an ugly hack and proof of concept. I will now try to write a proper patch, and submit it as a PR. Will keep you guys informed

Bartvz · April 14, 2017, 5:38pm

Wow, that is awesome!
What is the maximum you can set packet size? Is it the same as the ER-X MTU?

Mushoz · April 14, 2017, 5:42pm

I accidentally miss-typed the first time I tried to set 1508, and set 5108 instead. It took it just fine, and ifconfig showed 5108. I didn't test whether it was actually working though. I will have to some ping tests on my internal LAN to verify. Not sure whether the NICs in my clients actually support jumbo frames, so that is also something I will have to test. Will keep you posted on my progress

Bartvz · April 14, 2017, 6:23pm

Up to 9000 should be fine if the hardware supports it. Please let us know

demontefacto · April 16, 2017, 10:08pm

Good job man. Please let us inform.

Mushoz · April 19, 2017, 6:56pm

Testing the jumbo-frames on my LAN showed that it is very buggy. It doesn't increase much past 1500 MTU. However, somebody on the LEDE mailing list just posted the following patch for 2k frame support:

http://lists.infradead.org/pipermail/lede-dev/2017-April/007076.html

I didn't have the time to compile and test this today, but hopefully I will be able to play around with it tomorrow or the day after tomorrow. Will keep you guys informed about that as well

Bartvz · April 20, 2017, 2:31pm

Very interesting.
Tried applying it to my current experimental 17.01 with a few of @gwlim patches but I ran into the patch failing to apply:

Checking patch package/kernel/drivers/net/ethernet/mediatek/gsw_mt7620.h...
error: package/kernel/drivers/net/ethernet/mediatek/gsw_mt7620.h: No such file or directory
Checking patch package/kernel/drivers/net/ethernet/mediatek/gsw_mt7621.c...
error: package/kernel/drivers/net/ethernet/mediatek/gsw_mt7621.c: No such file or directory
Checking patch package/kernel/drivers/net/ethernet/mediatek/mtk_eth_soc.c...
error: package/kernel/drivers/net/ethernet/mediatek/mtk_eth_soc.c: No such file or directory
Checking patch package/kernel/drivers/net/ethernet/mediatek/mtk_eth_soc.h...
error: package/kernel/drivers/net/ethernet/mediatek/mtk_eth_soc.h: No such file or directory
Checking patch package/kernel/drivers/net/ethernet/mediatek/soc_mt7621.c...
error: package/kernel/drivers/net/ethernet/mediatek/soc_mt7621.c: No such file or directory

Probably should add it into a folder so it is triggered at the right time of the compiling process but I don't have the time to find out which atm.

Mushoz · April 20, 2017, 2:47pm

@Bartvz These files are created by patches as well, so the sequence is indeed important. The patches that create those files are located here:

/target/linux/ramips/patches-4.4

Try to run the MTU patch after the patches in that folder have been applied. AFAIK, the .c and .h files that the patches generate are generated somewhere inside the build_folder. I will try my hand at it tonight or tomorrow evening, depending on when I can find the time.

Bartvz · April 24, 2017, 5:33pm

First attempt was not a success, but new build is building atm