[linux-sunxi] dwmac-sun8i mtu problems

[Sebastian Schildt]

Hello sunxi-community

I have a problem with Allwinner Ethernet, but I am not sure if this is the right community.

I try to keep it short, I can provide more infos, if somebody suggests, what may be useful

Hardware: FriendlyArm nanoPi Neo 2 Allwinner H5
OS: "Armbian" , Linux nanopineo2 4.14.15-sunxi64 #95 SMP Wed Jan 24 10:55:45 CET 2018 aarch64 aarch64 aarch64 GNU/Linux

Problem: MTU setting on the Ethernet mac does not allow to receive large frames

The device comes up with MTU 1500, and when revceiving larger packets, I get an error in dmesg. Fine, and as expected.

When I increase the MTU I see I can not go to 9000, but the maximum is 3582

eth0 Link encap:Ethernet HWaddr 02:01:3b:9f:c7:2d
inet addr:192.168.17.77 Bcast:192.168.17.255 Mask:255.255.255.0
inet6 addr: fe80::1:3bff:fe9f:c72d/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:3582 Metric:1
RX packets:107156 errors:11 dropped:64955 overruns:0 frame:11
TX packets:5254 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:181690239 (181.6 MB) TX bytes:2129670 (2.1 MB)
Interrupt:22

Ok, I am not a hardware/kernel guy, but from glancing at the H5 datasheet it seems the Mac has separated RX and TX Fifos and the TX is limited to 4k, so I guess it makes sense. Although RX buffer is larger. I think somewhere I read the maximum is configured in the Device tree somewhere? Could Linux/an Ethernet driver theoretically deal with the situation, where it can receive large frames, but only send smaller ones? (would solve my usecase)

However, the main problem is, even with the 3582 setting, the maximum length frames that actually can be received is much smaller

Works:

$ ping -s 1996 192.168.17.77
PING 192.168.17.77 (192.168.17.77) 1996(2024) bytes of data.
2004 bytes from 192.168.17.77: icmp_seq=1 ttl=64 time=0.663 ms
2004 bytes from 192.168.17.77: icmp_seq=2 ttl=64 time=0.388 ms

Doesn't work
$ ping -s 1997 192.168.17.77

(from a machine with mtu 9k, that definitely works with frames around 4k, so the sender is not the problem)

When this happens I do NOT get any length warning in dmesg or anything. The frames just never appears at the interface (checked with tcpdump)

This seems wrong. Can it be explained, or preferably :) fixed? Where would I need to dig deeper?

Thanks

Sebastian